Google's A2UI Protocol on React Native: Where Mobile Fits In

A2UI is Google's open protocol (released December 2025) that lets an AI agent describe a UI as a flat list of components with a shared data model, and have any client renderer (React, Flutter, SwiftUI, React Native) draw the result natively. For React Native specifically, the spec maps almost one-to-one onto a Hermes-safe flat component runtime. WireAI's existing 11-component registry, Zod-validated props, and one-component-per-turn rendering loop are already A2UI-shaped. Full A2UI v0.9 compatibility ships in WireAI 0.3.

A2UI is the protocol nobody asked for and everyone is going to need. The web crowd has spent two years building agent UIs with custom JSON shapes per app. Every agent server speaks a slightly different dialect. Every renderer parses it slightly differently. A2UI is Google saying "stop, here is the JSON, here is how the client maps it." React Native is one of the harder targets to do well, which is exactly why mobile has been an afterthought in early adopter posts.

What A2UI actually is, in one screen

An A2UI response is a JSON payload with three parts: a flat list of components (each with a stable id), a data model (the values those components bind to), and a small set of update operations the agent can use to mutate the model on the next turn. The client renderer reads the list, maps each component name to a native widget, and binds the data. The agent does not write code. The client does not parse arbitrary structures. The contract is the schema.

Worth noticing: A2UI is flat. Not a tree. The components reference each other by id, not by nesting. This is the same shape WireAI has been shipping since 0.1.0, for the same reason: trees are hostile to streaming LLM output, hostile to Hermes object allocation, and hostile to incremental updates. Google arrived at flat for the same physics.

Why does A2UI matter specifically on React Native?

Three reasons. First, the protocol is platform-portable. The agent server you build today can drive a web app, a Flutter app, and your React Native app from the same response. You write the rendering layer once per platform and the agent layer once total. For small founder-CTOs shipping mobile-first, that is the leverage point.

Second, A2UI assumes streaming. The spec includes operations to append, replace, and update components incrementally. That assumption breaks every cloud LLM SDK that depends on response.body.getReader() on Hermes (where ReadableStream is not implemented). A real A2UI client on React Native needs an XHR + SSE shim under it. WireAI ships that shim in packages/core/src/streaming.

Third, mobile constraints reward the flat model. A phone screen renders one decisive card. The user taps. The next card arrives. Recursive component trees fight the mental model. A2UI fits the phone form factor better than the web container it came from, which is funny because the spec was written by web engineers first.

What renderers exist today (and where they fall short)

As of May 2026, the public A2UI ecosystem for React Native is one open-source renderer (sivamrudram-eng/a2ui-react-native on GitHub) plus a few Medium walkthroughs. The renderer is a clean reference implementation. It does not ship a streaming layer, an A2A protocol adapter, or a production component registry. It is closer to a proof-of-concept than a shipping SDK.

The web side is further along: Angular and React reference renderers are documented at a2ui.org, and a Flutter implementation lives in the google/a2ui repo. None of these target the Hermes runtime. Drop them into a React Native app and you hit the same wall everyone hits with web-shaped AI infrastructure: streams that do not stream, validation that depends on the DOM, and a build pipeline that assumes a bundler other than Metro.

How WireAI maps to the A2UI spec right now

WireAI 0.1.3 is not A2UI-compliant. It is A2UI-shaped. Three pieces align cleanly, one needs work:

• The component registry. WireAI ships 11 native components (ActionCard, ChipSelectCard, ConfirmPrompt, ContentSelectCard, InfoList, MessageBubble, NumberStepperCard, SelectionCard, StatusCard, StepList, TextInputCard). Each has a name, a Zod schema for props, and a system-prompt description. That is the A2UI component definition, minus the spec-level identifiers.
• The render loop. The agent emits one component per turn with validated props. WireAI maps it to a native widget. No tree walk. No per-node parsing during streaming. This is the A2UI flat-list pattern, minus the operations payload.
• The streaming layer. The XHR + SSE shim runs at roughly 60fps on a real iPhone 13 in our own dogfood logs (not a controlled benchmark). That is the transport A2UI's streaming-update operations need on mobile.
• What is missing. The A2UI data model and operations layer. WireAI 0.1.3 passes props directly. A2UI separates the data model from the components and uses operations to mutate. That is the work for WireAI 0.3.

What an A2UI client looks like on React Native

Skim version (the kind of code you would write today against the spec, before WireAI 0.3 lands):

// pseudocode against the A2UI v0.9 shape
type A2UIResponse = {
  components: { id: string; name: string; props: Record<string, unknown> }[];
  dataModel: Record<string, unknown>;
  operations?: A2UIOperation[];
};

async function renderA2UI(serverUrl: string, userMessage: string) {
  // streamSSE bypasses Hermes' missing ReadableStream
  streamSSE(serverUrl, { method: "POST" }, JSON.stringify({ message: userMessage }), (event) => {
    const response = JSON.parse(event.data) as A2UIResponse;
    for (const component of response.components) {
      const Native = registry[component.name];
      if (!Native) continue;
      const validated = schemas[component.name].safeParse(component.props);
      if (!validated.success) continue;
      mount(component.id, <Native {...validated.data} />);
    }
  });
}

That is the whole client side at the conceptual level. The work is in the registry (component-to-native widget mapping), the validation (Zod per component), and the streaming (XHR + SSE). WireAI handles all three out of the box; the A2UI-specific work in 0.3 is the data model binding and the operations layer.

How does A2UI compare to A2A?

A2A is agent-to-agent. A2UI is agent-to-UI. They compose. A2A is how a supervisor agent talks to a specialist agent (or how your React Native app talks to a remote agent backend). A2UI is how that backend tells the client what to render. In a real stack, the mobile app speaks A2A out (to invoke the agent server) and receives A2UI in (to render the response). WireAI ships the A2A adapter today (532 lines in packages/core/src/llm/a2a.adapter.ts) and the A2UI bindings in 0.3.

For a deeper look at A2A on React Native specifically, see the LangChain agents stack post, and for the message format itself, A2A protocol payloads explained.

What still does not work

Honest section, mandatory:

• A2UI v0.9 is new. The spec changed three times between October 2025 and May 2026. Building against it today means tracking the spec, not just integrating once.
• The reference renderers do not handle deep links, modal stacks, or platform-native gestures. The protocol does not specify these. They are renderer concerns. Mobile-specific.
• Streaming updates (the operations payload) work on web because the DOM is mutable per-node. On React Native, you trigger re-renders. The semantics translate, the performance characteristics differ. Test on a real device before committing to the streaming path.
• The Flutter renderer is ahead of the React Native one in the public ecosystem. If you are platform-agnostic, that is a real consideration. If you are React Native first, WireAI 0.3 is the path with the shortest mobile-specific debt.
• A2UI does not specify auth, rate limits, or capability discovery the way A2A does. You build those at the transport layer.

Where to start if you want to ship against A2UI

Three paths depending on how production-bound you are:

• Prototype today against the open-source RN renderer. Useful for understanding the spec. Not what you ship.
• Use WireAI 0.1.3 with the existing component registry. The shape is A2UI-aligned and the streaming layer works on Hermes. When 0.3 ships the spec-level bindings, the upgrade is config, not rewrite.
• Wait for WireAI 0.3 (target: PH-1 launch, June 23 2026). The PH-1 demo is a full A2UI + LangChain stack: a supervisor agent driving a React Native app over A2A, returning A2UI components.

npm install wireai-rn@0.1.3

Quickstart at getwireai.com/docs/quick-start. Glossary entry for the protocol at getwireai.com/glossary/a2ui-protocol. The repo is github.com/chohra-med/wireai-rn (MIT). Wire RN also runs as the AI tier of the AI Mobile Launcher boilerplate at aimobilelauncher.com. One mobile-AI issue per week at codemeetai.substack.com.

Built by Malik Chohra. 7+ years React Native. Shipped DocMorris (9M users, regulated digital health, NFC for electronic health cards), Mindshine (4.3 to 4.9 App Store rating), and ScorePlay (AI spec workflows as App Lead).

FAQ

What is A2UI in plain English?

A2UI (Agent-to-UI) is an open protocol from Google, released in late 2025, that defines how an AI agent describes a user interface as JSON, and how a client (React, Flutter, React Native, SwiftUI) renders that JSON as native components. It separates the agent from the renderer, so the same agent backend can drive any client.

Does A2UI work on React Native today?

Partially. The open-source a2ui-react-native renderer covers the basic spec. It does not ship a streaming layer (you will hit Hermes' missing ReadableStream), a production component registry, or an A2A transport. WireAI 0.1.3 is A2UI-shaped (flat components, Zod schemas, Hermes-safe streaming) and ships full A2UI v0.9 bindings in 0.3.

What is the difference between A2A and A2UI?

A2A is agent-to-agent (or app-to-agent) JSON-RPC. A2UI is agent-to-UI declarative rendering. A real mobile stack uses both: the React Native app sends user input over A2A to a remote agent server, the server returns an A2UI response describing the next screen, the client renders it natively.

Why is the flat component model in A2UI a fit for React Native?

Hermes object allocation under streaming load is not free. Per-node validation of a recursive tree multiplies cost. LLMs are also worse at generating nested generative UI: tokens balloon, hallucinations climb. Flat lists keep per-turn cost low, fit the phone form factor (one decisive card at a time), and stream cleanly over SSE.

Can I use WireAI with an A2UI-compliant agent server?

Today: not natively. You can run an adapter that maps A2UI responses to WireAI component directives. From 0.3 (target: June 2026): yes, directly. The PH-1 demo is exactly this: a LangChain supervisor returning A2UI, a Wire RN client rendering it.