A2UI on iOS: reading the spec, and what the Swift renderers actually do

You searched for this and found two GitHub repos, a discussion thread and a launch post. That is the whole written record, and it is not enough to decide with.

A2UI is Google's declarative protocol for agent-generated interfaces, open-sourced on 15 December 2025 under Apache 2.0. It has working renderers for React, Angular, Lit, Flutter and Lynx. There is no first-party A2UI SwiftUI renderer: the project roadmap still lists SwiftUI as "Planned" against a Q2 2026 target, checked 6 August 2026, a quarter after that target closed.

So everything you can install today is community code. This piece reads the spec first, then the repos: what A2UI puts on the wire, what each Swift implementation covers, and the part no README says out loud. If you are still working out what generative UI on iOS means, start there instead.

The short answer

A2UI is a JSON protocol in which an agent describes a screen from a fixed component catalog and a native client renders it. On Apple platforms there is no official renderer. Four community Swift projects exist at four levels of completeness, they target different spec versions, and picking one is closer to choosing a fork than choosing a dependency.

What A2UI actually puts on the wire

The protocol is a message stream, not a document. The v1.0 candidate spec defines six messages from the agent to the renderer, createSurface, updateComponents, updateDataModel, deleteSurface, callFunction and actionResponse, and three going back, action, functionResponse and error.

Three design choices matter more than the message list.

Components are a flat list with id references, not a nested tree. A model can emit them incrementally, and a renderer can draw as soon as root exists and fill the rest in as it arrives.

Structure and data are separate. Components carry JSON Pointer bindings such as {"path": "/booking/summary"}, and updateDataModel writes to those paths. The same surface can be repainted by changing data alone.

The agent picks from a catalog it did not write. The v0.9.1 basic catalog defines 17 component types and 14 functions. The spec is explicit that "the agent must generate messages that conform to the catalog understood by the renderer", and a renderer meeting an unknown component is expected to emit an error back up the stream.

Trimmed to two components, a surface looks like this:

{"createSurface": {"surfaceId": "s1", "catalogUri": "https://a2ui.org/specification/v1_0/catalogs/basic/catalog.json"}}
{"updateComponents": {"surfaceId": "s1", "components": [
  {"id": "root", "componentType": "Column", "children": ["summary", "confirm"]},
  {"id": "summary", "componentType": "Text", "text": {"path": "/booking/summary"}},
  {"id": "confirm", "componentType": "Button", "label": "Confirm",
   "action": {"event": {"name": "confirm_booking"}}}
]}}
{"updateDataModel": {"surfaceId": "s1", "path": "/booking/summary", "value": "Two nights, sea view"}}

Note what the button does not carry: no URL, no handler, no payload. It carries an event name, and your app decides what that name means. Styling is withheld too. The v1.0 candidate "removes rigid theme properties" and defers appearance "entirely to the target framework's native theme".

What A2UI is not

Three neighbours get confused with it, and each confusion costs a different amount.

It is not a model writing SwiftUI source. Generated code has to be compiled or interpreted to run, which is why the alternative exists at all. A2UI output is data your app decodes and maps to views you already shipped.

It is not server-driven UI. SDUI ships a tree a human authored at deploy time; A2UI ships a tree composed per request. The transport looks identical, which is why teams with an SDUI backend assume they have already solved this. Our writing on this cluster takes that distinction apart.

It is not AG-UI. AG-UI is the Agent-User Interaction Protocol, a separate project with its own repository, and it standardises the event stream between an agent and a frontend: lifecycle, token deltas, tool calls, state patches. A2UI describes the screen; AG-UI describes the conversation carrying it. They were announced as collaborators, not competitors. If you want an AG-UI protocol Swift client, the community one is paduh/ag-ui-swift, 20 stars and last pushed 4 May 2026; CopilotKit's own native answer is a Kotlin Multiplatform SDK rather than a Swift one.

What the two A2UI SwiftUI renderers actually implement

Both are MIT licensed, both target v0.9, and they are built for different jobs. Figures checked 6 August 2026.

BBC6BAE9/a2ui-swift is the conformance-first one. 52 stars, created 12 March 2026, last pushed 3 July 2026. It implements all 17 basic-catalog components plus expressions, checks, templates and custom catalogs, and it is the only Apple-native renderer listed on the A2UI ecosystem page. It renders through three front ends over one A2UISwiftCore: SwiftUI via A2UISurfaceView, UIKit and AppKit via A2UISurfaceHostView. It ships no transport and no agent; you hand it decoded messages. Its roadmap is to track v1.0 as that stabilises.

vpm238/a2ui-swiftui is the streaming-first one. 2 stars, created and last pushed 21 April 2026. It implements six components, and two of them are not in the catalog at all: OptionsGrid and RichMessageCard, invented for the shapes an assistant actually emits. In exchange it does the thing the other does not, implementing all three proposals of its author's progressive-rendering RFC ahead of the spec: shimmer placeholders for unresolved bindings, a streaming flag that draws a typewriter caret, and append/prepend patch operations on the data model. It also ships an A2UIClient over a URLSession WebSocket, so it is closer to a working app.

The axis that decides it is coverage versus behaviour. If your agent already emits the basic catalog and you need the whole surface to render correctly, take the first. If what you cannot live without is what the screen looks like 300 milliseconds into a response, take the second and write the components you are missing. Neither choice is reversible cheaply, because the component set is where your design system attaches.

Two more Swift implementations, one of them gone

The count of two is already wrong in both directions.

no-problem-dev/swift-a2ui targets the v1.0 candidate rather than v0.9. It is the most ambitious of the four: 15 modules, 18 typed components, a generic A2UISurfaceView<Catalog> with no AnyView erasure, a streaming parser and a surface-ownership ledger for multi-agent routing. Its best idea is generating the LLM-facing JSON Schema from the Swift types, so catalog drift fails at compile time. It had 0 stars and a commit from that morning when checked on 6 August 2026.

The fourth is instructive in a different way. On 12 March 2026, a developer announced a full v0.9 basic-catalog SwiftUI parser in discussion #834 on Google's own A2UI repository, and vpm238's README still links to it. That URL returns a 404.

A community renderer is a fork decision, not a dependency decision. Budget for owning the code, because on this protocol one in four has already gone away.

Where a client-only renderer stops

Every one of these projects is a client. It decodes messages, resolves bindings and draws views. All four do that honestly. It is also not the part that decides whether you can ship to customers.

A renderer does not run the model. It does not call your API, does not choose which endpoints the model may reach, and does not decide what happens when the output is wrong. Its only enforcement is that malformed input fails to decode, and the spec's own remedy is a "prompt-generate-validate loop", which puts the correction after the agent has already spoken. Three things stay yours: the agent, the boundary around your API, and the failure policy.

That gap is the shape of the product we build. Uzori is an in-app AI assistant for native iOS apps that answers in real screens instead of text, and the difference from a renderer is where validation lives. Every model-emitted line passes a server-side gate, JSON Schema, screen identity, navigation match, stream grammar state, grounding and cardinality, before it reaches the device, and the gate forwards the original bytes rather than a repaired copy.

Invalid lines are rejected, not patched. The server never repairs model output, and one bounded re-ask is permitted only when the first record fails and nothing has been forwarded. The iOS reducer re-implements the same grammar and its own limits, so it does not trust the server either. Mutating verbs are disabled by default: an operation reaches the model only if a human both allowlists it and classifies it read. Style is absent from the wire schema, so it cannot be authored.

That is not a drop-in for a renderer. If you have an agent you trust and a design system you control, a renderer may be all you need.

What is still missing for iOS

There is no conformance suite you can run against your own catalog, so "spec-faithful" is a README claim rather than a test result. The four projects straddle v0.9, v0.9.1 and the v1.0 candidate, and the catalog changed between them. None of the READMEs mentions Dynamic Type, VoiceOver or right-to-left layout, which is the first question anyone shipping to real users will ask.

What would change the calculus is Google shipping the renderer it has listed as Planned since launch. Until then, treat all four as reference implementations and read the spec yourself.

Frequently asked questions

Is there an official A2UI SwiftUI renderer from Google?

No. As of 6 August 2026 the A2UI roadmap lists SwiftUI for iOS and macOS as "Planned" with a Q2 2026 target, alongside Jetpack Compose. The only renderer the A2UI team describes as its own is the React package. Every Swift implementation available today is community-maintained, MIT licensed and independent of Google.

What is the difference between A2UI and AG-UI?

They solve adjacent problems. A2UI describes what a screen contains: a flat component list, a data model and named actions drawn from a fixed catalog. AG-UI standardises the event stream between an agent and a frontend, covering run lifecycle, streamed text, tool calls and state updates. You can carry A2UI messages over AG-UI, and the two projects were announced together as collaborators.

Can an A2UI agent send its own colors and fonts?

Barely, and less in each version. The v0.9.1 basic catalog carries a small theme object with a primary color, an icon URL and an agent display name, and no font family or spacing controls. The v1.0 candidate removes those rigid theme properties and defers appearance to the client framework's native theme, so styling stays in your app.

Do I need a server to render A2UI on iOS?

You need an agent somewhere producing the messages. Of the Swift projects, only vpm238's ships a client transport, a WebSocket connection to an A2UI server. The others take already-decoded messages, so you supply the connection yourself. None of them includes the agent, the model or the tool execution that generates the surface in the first place.

Where to start

1. Read the v1.0 candidate specification end to end. It is short, and every renderer decision is downstream of it.
2. Run one sample app against a static fixture before you connect anything. Both live repos ship one, and the same payload rendering differently in each tells you more than either README.
3. Decide the fork question honestly. If this ships to customers, you own the renderer.
4. Then decide the validation question, which the renderer will not decide for you: what reaches your API, what happens to output that fails, and who says no.

If that last question is the one you are stuck on, see how we answer it.