# Server-Driven UI: JSON to React Native (Examples)

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-05-30, updated 2026-06-02. 4 min read.
> Source: https://vp0.com/blogs/server-driven-ui-json-to-react-native-examples

SDUI is powerful, but its discipline is a constrained, well-defined schema.

**TL;DR.** Server-driven UI sends JSON describing the UI, which the app renders into native components, so you can change layout and content without an app update. Build a fixed component library from a free VP0 design, define a small versioned schema, handle unknown types gracefully, and keep SDUI to content and layout (not core logic, per App Review).

Server-driven UI (SDUI) flips the usual model: instead of hardcoding screens, your backend sends JSON describing what to render, and the app interprets it into native components. The payoff is changing layouts, content, and ordering without shipping an app update. The short answer is, define a small, fixed set of component types your app knows how to render, have the server send JSON that composes them, and keep it within Apple's rules (SDUI is fine for content and layout, not for changing your app's core purpose). Build the component library from a free VP0 design so the rendered UI looks right. SDUI is powerful, but its discipline is a constrained, well-defined schema.

## Why SDUI is useful (and where it bites)

The appeal is speed and flexibility: marketing can reorder a home screen, you can run a promo, or fix a layout, all from the server, with no App Store review wait (Apple reviews most apps within about 24 hours, but [90%](https://developer.apple.com/app-store/review/) within a day still means days of round-trips for small changes). The risk is over-generalizing: if your JSON can express anything, your renderer becomes a fragile mini-framework, and you can drift toward shipping features that should go through review. Apple's [App Review](https://developer.apple.com/app-store/review/guidelines/) permits remote content and configuration but not changing the app's core purpose or bypassing review for new functionality. So keep the schema small and content-focused.

## How to build server-driven UI in React Native

VP0 is a free iOS design library for AI builders. First, build a fixed library of native [React Native](https://reactnative.dev/) components from VP0 designs (a hero, a card row, a list item, a banner, a button), each with a known set of props. Then define a JSON schema where the server composes those components by type and props, and write a renderer that maps each JSON node to its component. Validate the JSON, handle unknown types gracefully (skip or fallback), and version the schema. Keep behavior and navigation native; let the server drive content and arrangement, not core logic. For dynamic data that is not layout, see [how to connect an API to an AI-built iOS app](/blogs/how-to-connect-an-api-to-an-ai-built-ios-app/).

## SDUI building blocks

Here is what each part should do.

| Part | What to get right |
|---|---|
| Component library | Fixed set, known props |
| JSON schema | Small, content-focused, versioned |
| Renderer | Maps JSON to components safely |
| Unknown types | Skip or fallback gracefully |
| Boundaries | Content/layout, not core logic |

## A worked example

Say you want a home screen marketing can rearrange. Build a set of components from VP0 designs (hero, promo banner, product row, card). Define JSON like a list of nodes, each with a `type` and `props`, and a renderer that turns each node into the matching component. Now the server can send a new arrangement, swap a banner, or reorder rows without an app update, while the renderer ignores any unknown type instead of crashing. Keep navigation and purchases native. For the data layer behind it, see [local-first database conflict resolution UI mobile](/blogs/local-first-database-conflict-resolution-ui-mobile/); for auth, [Supabase auth UI React Native template](/blogs/supabase-auth-ui-react-native-template/).

## Common mistakes

The most common mistake is an over-general schema that can express anything, turning your renderer into a brittle framework. The second is no graceful handling of unknown component types, so a new server type crashes old app versions. The third is not versioning the schema, breaking older clients. The fourth is pushing core logic or new features through SDUI, which can violate App Review rules. The fifth is rendering generic components instead of building them from a real design, so SDUI screens look off.

## Key takeaways

- SDUI sends JSON describing the UI so you can change layout and content without an app update.
- Define a small, fixed, versioned component set and schema; do not let it express anything.
- Handle unknown component types gracefully so new server types do not crash old clients.
- Keep SDUI to content and layout (not core logic), and build the components from a free VP0 design.

## Frequently asked questions

How does server-driven UI work in React Native? Your backend sends JSON composed of known component types and props; the app has a fixed library of native components (built from a VP0 design) and a renderer that maps each JSON node to its component. This lets you change layout and content without an app update.

What are the risks of SDUI? An over-general schema that becomes a fragile mini-framework, unhandled unknown types crashing old clients, and pushing core logic or new features through it, which can violate App Review. Keep the schema small and content-focused.

Is server-driven UI allowed on the App Store? Remote content and configuration are allowed, but changing the app's core purpose or shipping new functionality that bypasses review is not. Keep SDUI to content and layout, not core logic.

Why build the components from a design? So SDUI screens look intentional, not generic. Build a fixed component library from a VP0 design, then let the server arrange those well-made components.

## Frequently asked questions

### How does server-driven UI work in React Native?

Your backend sends JSON composed of known component types and props; the app has a fixed library of native components (built from a VP0 design) and a renderer that maps each JSON node to its component. This lets you change layout and content without an app update.

### What are the risks of SDUI?

An over-general schema that becomes a fragile mini-framework, unhandled unknown types crashing old clients, and pushing core logic or new features through it, which can violate App Review. Keep the schema small and content-focused.

### Is server-driven UI allowed on the App Store?

Remote content and configuration are allowed, but changing the app's core purpose or shipping new functionality that bypasses review is not. Keep SDUI to content and layout, not core logic.

### Why build the components from a design?

So SDUI screens look intentional, not generic. Build a fixed component library from a VP0 design, then let the server arrange those well-made components.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*