Building a generative-UI SDK for React Native: registry, Zod, Hermes-safe streaming

TL;DR

• Generative UI lets an AI model assemble the interface at runtime instead of hard-coding every screen.
• The web already ships it (Vercel AI SDK, Tambo, Google's A2UI). Mobile has almost nothing native.
• React Native blocks it three ways: broken streaming, costly nested trees, no native agent renderers.
• So I'm building Wire RN, an open-source generative UI SDK for iOS and Android.

Short version up front: the web already has good tools for generative UI, mobile has almost none, and I got tired of waiting. So I'm building one. The longer version is the more interesting part, and it starts with how interfaces have always changed.

Every era of the interface moved in the same direction. You just have to squint to see it.

Command lines made you learn the machine. Exact syntax, no forgiveness. The graphical UI flipped some of that: windows, a mouse, things you could see instead of memorize. Touch went further, the screen became the thing you manipulated directly. Then chat arrived and you could just type what you wanted in plain language. Each step moved a little more of the burden off the user and onto the software.

Generative UI is the next step on that same line. And it's the biggest one yet.

I'm a React Native engineer, nine years in. I've spent the last six months building with this pattern daily. I want to show you the SDK I'm building and why. A sneak peek.

A flow in my own app, built on the pattern this whole piece is about. The screen changes shape between turns because the model is choosing what to render next.

What generative UI actually is

Generative UI is when a model decides the interface at runtime, instead of a developer hard-coding every screen in advance. The model reads context (your last answer, your history, the task) and emits structured data that says "render this component, with these props." Your app maps that to a real component. The user never sees the structured data. They see a screen that happens to be different from the one their neighbor got.

The distinction that matters: this is not a chatbot. A chatbot returns text and you read it. Generative UI returns interface. Things you tap and type into. The model is behind the screen.

Google now defines it in almost exactly these terms: a front-end architecture where the interface is built by AI in real time rather than hard-coded by developers. They frame the old way as the "wall of text" problem. Models could reason and plan, then collapsed it all into a paragraph of markdown, which is what generative UI fixes. Let the natural output of a capable model be an actual interface.

Why big tech suddenly cares

Because the data backs it up. Google's own evaluations show people strongly prefer generated interactive experiences over plain text answers. And Google is openly calling this work the first step toward fully AI-generated user experiences, where interfaces get tailored to the user instead of pulled from a fixed catalog of apps.

Read that last part again. The endgame they're describing isn't "nicer chat answers." It's interfaces assembling themselves per user, per moment, personalized by user need, the fixed app catalog dissolving into something generated on demand. When the company that owns Android and Chrome writes that down as a direction, mobile teams should pay attention.

Tambo, one of the web libraries leading here, puts the same idea in plainer language: we used to adapt to software, now software adapts to us.

What web companies already ship

This is the uncomfortable part for mobile people. On the web, generative UI is past theory. It's npm-installable. The players worth knowing:

• Vercel's AI SDK wires a model's tool calls straight to React components. The model calls a tool, the tool returns data, and that result connects to a component instead of a string of text.
• Tambo is the clearest template for the pattern. You register your React components with Zod schemas, and the agent picks which one to render from natural language. Zod validates the props at runtime, so a malformed output gets caught before it ever reaches render. No "undefined is not a function" in production. The catch: it's React-only, and "other frameworks" includes the one your phone runs.
• CopilotKit's AG-UI pushes toward a declarative middle ground, where agents emit a structured spec of cards, lists, forms, and widgets rather than free-form code, so one spec can render across React, mobile, and desktop.
• Google's A2UI (a2ui.org) is the open protocol version of that idea: agents send declarative component descriptions, the client renders them with its own native widgets. The reference renderers shipped so far are Angular, Flutter, Lit, and web components. React Native is not on the list.

The registry-plus-schema pattern is the through-line in all of them, and it's the thing that makes this safe to ship. The model isn't writing UI code at runtime. It's filling out forms your components already defined. Creative freedom over the flow, zero freedom over what a component is.

The Gemini moment

Then there's the example everyone's actually seen now.

Gemini shipped generative UI into its own app as two experiments. Dynamic View uses agentic coding to design and code a fully custom interactive response per prompt. Visual Layout generates magazine-style multimodal responses with photos and interactive modules. Ask it to plan a three-day trip to Rome and you get a visual itinerary you can actually explore and adjust across multiple turns. Not a wall of text. A built thing.

Gemini generating an interface, not an answer. The image and the interactive steps get built into the chat itself. This is the version most people will meet first, and it's worth knowing exactly how it works.

Here's the part that matters for us. Even Gemini's mobile experience is the model writing HTML, CSS, and JavaScript and rendering it in an app shell. It generates web code in real time and shows it inside the app. Impressive. But it's generated web, displayed in an app. It is not native components, your design system, or your offline behavior. Which is exactly where mobile's real problem lives.

So why is mobile still behind?

Because every generative UI library that works is web-shaped, and mobile punishes web-shaped assumptions. Three walls, in the order you hit them:

• Streaming doesn't work. React Native's Hermes engine doesn't implement ReadableStream on fetch. Every LLM SDK that streams tokens through response.body.getReader() breaks on a real device. OpenAI's, Anthropic's, Google's, all of them. The first thing every mobile AI developer learns is that the model provider's own quickstart doesn't run on their phone.
• Recursive component trees are a tax. Web generative UI emits nested trees: a Card holding a Row holding Buttons. On mobile, that recursion multiplies validation work, hammers the JS thread mid-stream, and hands the model more places to invent a prop. Models are measurably worse at deep nested structures than flat ones. Token cost climbs, malformed output climbs with it.
• No agent rails. The agent protocols (A2A, AG-UI, Google's A2UI) were spec'd web-first. A2UI ships native renderers for Angular, Flutter, Lit, and web. If you want an agent to drive native React Native screens today, you're writing the adapter yourself.

And look at what mobile actually has in 2026. The "best React Native UI libraries" lists are all static kits: Tamagui, NativeWind, gluestack, Restyle. Excellent component libraries. Not one of them is generative. The category just doesn't exist on mobile yet the way it does on web.

So mobile teams do what teams always do. They patch a polyfill, give up on streaming, hand-roll a JSON-to-component mapper, and accidentally write 1,200 lines of glue code. I know the number because I wrote that glue for a client in 2024, and it broke every time the model invented a prop name.

How far does this go?

Worth zooming out before I get to the building part. The designer Andy Budd recently sketched a ladder of "adaptive software," borrowing the metaphor from the autonomy levels we use for self-driving cars. At the bottom, humans author every screen. Near the top, a product stops shipping one best version and starts assembling a different experience per cluster of users, then eventually per individual, per session, per task. The reframe that stuck with me is his: the question stops being "what's the best version of this flow?" and becomes best for whom? At the far end, each interaction becomes a design problem of its own.

He names the catch too, and it's a real one. A product that can adapt to your needs can adapt to your weaknesses just as easily. Personalization and manipulation run on the same engine. Anything that assembles interfaces per user needs rules about what it's allowed to optimize for, and in whose interest. That isn't a mobile problem or a web problem. It's a "we can suddenly do this" problem, and it shows up whether or not anyone writes the rules first.

Here's the bridge back to my corner of it. You don't reach the top of that ladder with hard-coded screens. Per-user, per-session interfaces need a system that builds UI at runtime from validated components, and that mechanism is what generative UI actually is. The web has it. Mobile, as we've covered, mostly doesn't. Which is the gap I'm building into.

So I'm building it

I'm building the thing I kept needing: an open-source generative UI SDK for iOS and Android, built on React Native. Wire RN.

Same core pattern the web libraries proved. A fixed registry of components, strict schema validation between the model and the screen, the model choosing the flow and never inventing a component. But built for the walls above instead of around them:

• Streaming that survives Hermes, so token streaming actually works on a real device.
• Flat components instead of recursive trees, because mobile screens are sequential anyway, and flat is where models make fewer mistakes.
• The registry stays yours, so your brand, design system, and accessibility never leave your control.

I rebuilt my own app's onboarding on it first.

Three turns of the same onboarding flow, left to right: the model rendered a text field, then a "reading your answer" beat, then a different choice-chips component. Same code, a different screen per user, no release cycle to change it.

The first version confidently rendered a date picker when it should have asked about sleep habits. So no, the robots are not running the show yet. Validation matters. And a rule of thumb on where to even use this:

• Good fits: onboarding, check-ins, recommendations, anything high-variance where the right next screen depends on the last answer.
• Bad fits: settings, billing, anything you want stable and predictable. Please do not make your settings screen generative.

So that's the why. The interface has always drifted toward adapting to the user instead of the other way around. The web got the generative version first. Mobile is late, but it's the surface where most people actually live, and being late means whoever picks it up now gets a personalization lever their competitors can only iterate on through App Store review cycles. I'd rather build the tool than keep writing the glue.

I'm shipping Wire RN open-source this month.

FAQ

Is generative UI the same as a chatbot?

No. A chatbot returns text that you read. Generative UI returns interface: real native components you tap, type into, and swipe. The model decides which component renders next from your context, and your code decides what components are allowed to exist. The conversation happens through the UI, not in a chat bubble.

Does the AI write code at runtime?

No, and this is the part most people get wrong. The model emits structured data that maps to pre-built, schema-validated components from a registry you control. It never writes React Native at runtime. If it emits something malformed, your validation layer rejects it before render and the user sees a fallback, not a crash.

Why can't I just use Tambo or the Vercel AI SDK in React Native?

They're built on web assumptions. They expect browser streaming APIs that React Native's Hermes engine doesn't implement, and they emit recursive component trees that perform badly on mobile and give the model more room to hallucinate props. They're excellent on the web. Mobile needs a runtime shaped for mobile.

Is generative UI safe for production apps?

Yes, if it's validated. The registry-plus-schema pattern means the model can only ever pick from components you shipped, with props checked against a schema before anything renders. The risk profile is closer to "remote config with opinions" than to "AI writes my app." The model owns the flow, never the component definitions.

Where does generative UI make sense first?

Onboarding, check-ins, recommendation flows, coaching: anywhere the ideal next screen depends on what the user just did. These are high-variance and conversational, so personalization pays off. Static utility screens like settings and billing should stay hard-coded. Please do not make your settings screen generative.

---

I write Code Meet AI, a weekly newsletter on AI-native mobile engineering. Wire RN goes open-source this month — the build, the bugs, and the repo are the next issue.