A2UI 1.0 goes stable, but renderer versions still matter

Google released A2UI 1.0 on November 11, giving developers a stable protocol for turning agent responses into interactive interfaces. The important qualifier is compatibility: a stable specification does not mean every renderer or host has already moved to it. Google’s announcement still lists Gemini support at 0.9.1 and Lynx at 0.9, with upgrades in progress.

A2UI is not a new model or a ready-made assistant. An agent describes an interface using components the developer permits, and the application renders it. That makes it relevant to teams building review forms, comparison cards and other tasks where the next step is easier to choose on screen than explain in another message.

Check the renderer before choosing the protocol version

Google lists React, Angular, Lit, Flutter and SwiftUI options. Jetpack Compose remains on 0.9.1, with 1.0 support forthcoming. Teams targeting Gemini Enterprise also need to account for its planned upgrade rather than assume the launch changes their deployed agent automatically.

The practical starting point is the destination: your own web app, a native mobile application or an assistant that hosts interactive content. Write down the version supported at each end before selecting SDKs. Otherwise, a working agent can produce a screen the receiving application cannot interpret.

What changes for existing integrations

The project’s migration guide describes explicit function calls in both directions between agent and renderer. Catalogs specify which side may invoke a function, while responses carry results or errors. A single surface can also mix components from multiple catalogs, provided those catalogs share a specification version.

Migration is not a global rename. Dynamic bindings use @path and function directives use @call, but ordinary data fields and some message parameters retain their unprefixed names. The guide explicitly warns against a blanket search-and-replace. Catalogs targeting 1.0 must declare their protocol version. Omission defaults to 0.9.

That creates a concrete review checklist: validate representative payloads, inspect mixed-catalog resolution and test calls from both permitted and disallowed roles. A screen rendering successfully is only one part of an upgrade. The action attached to its controls must also behave as intended.

Server-side macros reduce repeated UI generation

The macro documentation describes a way to keep repeated layouts in server code. Instead of generating an entire product card on every turn, a model can request a macro that expands into supported components before reaching the renderer. The server can populate those components from its own data sources.

Macros currently belong to the Python agent SDK. Their value is not simply shorter output: a team can keep a repeated layout consistent and update it without shipping new client code, as long as the client already supports the resulting components. The documentation describes possible token and latency savings, not a measured speedup for every application.

MCP Apps do not remove version checks

The official MCP Apps integration guide shows how an MCP server can bundle an A2UI web renderer inside an HTML resource. A compatible host displays it in an isolated iframe, while user actions return through the MCP Apps tool channel. This is different from requiring the host to implement A2UI natively.

There is another version trap in the examples: the community sample still emits 0.8 messages, while the guide’s implementation walkthrough covers 1.0 and 0.9.1. Copying a sample and following the current protocol documentation are therefore not necessarily the same upgrade path.

Start with a small review workflow

The official quickstart uses a Python agent server with React and Flutter clients. It is a learning sample, not a production application. The surrounding app, domain tools and model runtime remain the developer’s responsibility.

A useful pilot would let a person inspect and revise a proposed plan before anything is submitted. Test empty states, unavailable data and a rejected action as carefully as the successful path. As with Cursor’s distinction between shared canvases and running apps, an attractive view and a reliable workflow are different deliverables. ByteForward has not benchmarked A2UI or tested these integrations.