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

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% 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 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 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.

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; for auth, 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.