Wire RN: An Open-Source Generative UI SDK for React Native

Generative UI on React Native means an LLM or a remote agent decides what UI to show next and returns it as JSON, and the app renders that JSON as real native components at runtime. Wire RN is the open-source (MIT) generative UI SDK that does this on mobile. The model returns one validated component per turn, the SDK renders it natively, and the next turn comes from the user's answer. It is the Tambo / Vercel AI SDK pattern, but for React Native. The npm package is wireai-rn (0.2.0).

I built Wire RN because I needed generative UI in a React Native app and there was no library for it. The web had several. Mobile had none. The web tools assume a DOM, a bundler that is not Metro, and a streaming model that depends on browser APIs Hermes does not implement. None of that ports. So the question was not "which library do I pick," it was "why does this category not exist on mobile yet."

What is generative UI for mobile?

Generative UI is the idea that the interface is data, not code, and the data can come from a model. Instead of hard-coding every screen and branching with if statements, you let an LLM (or an agent behind it) emit a structured description of the next component, and you render that description. The user answers. The model reads the answer and emits the next component. The flow builds itself as the conversation goes.

On the web this shipped in 2024 with the Vercel AI SDK and tools like Tambo. The mechanic is the same everywhere: a model returns structured output, a renderer maps it to components. What changes on mobile is the runtime. React Native runs on Hermes, renders native views (not the DOM), and bundles through Metro. The web generative-UI stack assumes none of those. That gap is the whole reason for a mobile-specific SDK.

What is Wire RN?

Wire RN is a generative UI SDK for React Native, MIT-licensed, published to npm as wireai-rn at version 0.2.0. It is a Turbo monorepo targeting Expo ~55 and React Native 0.83.6. The core idea is narrow on purpose: an LLM or remote agent returns JSON describing one UI component, and the SDK renders that component natively. One component per turn. A flat model, no recursion.

It ships 11 built-in components, each backed by a Zod schema so the model's output is validated before anything renders. If the model emits props that do not match the schema, the component is skipped rather than crashing the screen. There are 5 LLM adapters: OpenAI, Anthropic, Gemini, Ollama (for on-device or self-hosted models), and A2A, which is Google's Agent-to-Agent protocol and the part that separates Wire RN from a thin OpenAI wrapper. As of 0.2.0 the SDK streams by default and supports nested composition.

How does Wire RN render UI from an LLM?

Two steps. The model returns a JSON object naming a component and its props. The SDK looks the name up in its registry, validates the props with Zod, and mounts the matching native component. That is the entire loop.

// Step 1: the LLM (or remote agent) returns one component as JSON
{
  "component": "ChipSelectCard",
  "props": {
    "title": "What brings you here?",
    "options": ["Focus", "Sleep", "Stress", "Energy"]
  }
}

// Step 2: the SDK validates the props and renders it natively
import { WireAIProvider, WireAIMessageRenderer } from 'wireai-rn';

<WireAIProvider adapter={anthropicAdapter}>
  <WireAIMessageRenderer />
</WireAIProvider>

The flat model matters more than it looks. LLMs are bad at generating deep recursive UI trees: token counts balloon and hallucinations climb the deeper the nesting goes. A flat list of one component per turn keeps the model's job small, keeps Hermes object allocation low under streaming load, and fits the phone form factor, where the natural unit is one decisive card the user taps through. The streaming layer underneath uses an XHR plus SSE transport, because Hermes does not implement ReadableStream the way the browser does.

What about agents and A2A?

The JSON does not have to come from a chat completion call. It can come from a remote agent. The A2A adapter lets a React Native app talk to an agent server over Google's Agent-to-Agent protocol, and that server can be anything: a LangChain graph, a multi-step supervisor, a tool-using agent. The agent does the reasoning, decides what to show, and returns a component. Wire RN renders it. The one in the langchain-multistep example drives a multi-step flow from a remote LangChain agent.

This is why Wire RN is more than a generative UI renderer. The same component model that a single LLM call drives can be driven by an agent network. The app becomes a thin native client over an agent backend, which is where mobile AI is heading. If you want the wire format, what an agent message carries and how the client parses it, see A2A protocol payloads explained.

The concrete use case: AI dynamic onboarding

The clearest place generative UI earns its keep on mobile is onboarding. Static onboarding asks everyone the same 12 questions and converts badly. With Wire RN, the model builds the onboarding screens live from the user's answers: it asks a fixed base of questions, reads the responses, then generates 2 to 4 personalized cards instead of a fixed wizard. The model picks the components, the SDK renders them, the user is through in about a minute.

The pattern that holds up in production is two-phase: a fixed Phase 1 of base questions, then one bounded LLM call that generates the personalized cards. I wrote that up in full with code in Dynamic Onboarding in React Native: The Two-Phase LLM Pattern. The onboarding flow has its own page at getwireai.com/onboarding.

How is this different from the web generative UI tools?

Tambo and the Vercel AI SDK are built for React on the web. The rendering layer assumes the DOM. The streaming layer assumes browser ReadableStream. The build assumes a web bundler. You can wrap a web library in a WebView, or rebuild its render layer against RN primitives, or write a Hermes streaming polyfill. Do all three and you have rebuilt most of Wire RN. I went through the specific gap in Why Tambo Doesn't Work on Mobile (and What Does).

Wire RN is native-first instead. Native views, Metro, Hermes-safe streaming, Zod validation that does not depend on the DOM. It is the same category as the web tools, built for the runtime they were never meant to run on.

npm install wireai-rn zod

Docs and quickstart are at getwireai.com/docs. The plain-language definition of the category lives at getwireai.com/glossary/generative-ui-for-mobile. The package is on npm at npmjs.com/package/wireai-rn and the source is on GitHub at github.com/chohra-med/wireai-rn (MIT). There are three examples in the repo: quickstart, mental-coach, and langchain-multistep.

FAQ

What is generative UI in React Native?

Generative UI in React Native is a pattern where an LLM or remote agent returns a structured description of the next UI component, and the app renders that description as native views at runtime. The interface is data the model produces, not screens you hard-code. Wire RN is the open-source SDK that implements this on mobile.

Is Wire RN free and open source?

Yes. Wire RN is MIT-licensed and published to npm as wireai-rn (version 0.2.0). The source is on GitHub. You install it with npm install wireai-rn zod.

Which LLMs does Wire RN support?

Five adapters ship in the box: OpenAI, Anthropic, Gemini, Ollama (for on-device or self-hosted models), and A2A (Google's Agent-to-Agent protocol) for driving the UI from a remote agent rather than a single model call.

Why does Wire RN use a flat component model instead of nested trees?

LLMs degrade at generating deep recursive UI: token counts grow and hallucinations climb with nesting depth. A flat model of one validated component per turn keeps the model's output small, keeps Hermes allocation low under streaming, and matches the phone form factor where one card at a time is the natural unit. Nested composition is supported as of 0.2.0 where you need it.

What is the main use case for Wire RN?

AI dynamic onboarding. The model builds onboarding screens live from the user's answers instead of running a fixed wizard, which lifts activation. The full two-phase pattern with code is in the dynamic onboarding post.