A2UI 1.0 Migration: Check Renderer Support Before Upgrading

Google released A2UI 1.0 on November 11, giving agent-generated interfaces a stable protocol with bidirectional function calls. For an existing integration, the immediate question is whether the application receiving those messages supports them. Upgrading the agent alone can leave the screen behind.

A2UI separates an agent's description of an interface from the application that renders it. That separation is useful, but it also creates a compatibility boundary. A stable protocol release is not a simultaneous upgrade of every renderer and host.

Which A2UI integrations support 1.0?

Google's release announcement describes these transition states:

Integration	Published status at the November 11 launch	Deployment decision
Android Jetpack Compose	A2UI 0.9.1; 1.0 coming soon	Keep its agent output on the supported version
Lynx	A2UI 0.9; adapting to 1.0	Do not send 1.0-only messages to the existing integration
Gemini-hosted registered agents	A2UI 0.9.1; Enterprise upgrade planned	Verify the host contract before changing output
Web, Flutter and SwiftUI renderers	Listed in the release's renderer ecosystem	Check the specific package and release you deploy

There is a documentation mismatch worth knowing about. The Gemini Enterprise registration guide, updated November 10, lists v0.9 and v0.8, while the newer announcement says 0.9.1. Neither source promises 1.0 support for that host. Treat the difference as something to resolve against your deployment, not permission to assume the newest version works.

Gemini Enterprise also uses its built-in styling. A successful screenshot from your own application therefore does not prove the same interface will look or behave identically inside that host.

Separate the protocol upgrade from Express

A2UI Express changes the compact format a model generates before the SDK produces protocol messages. The 1.0 migration changes the messages and contracts consumed downstream. These are different decisions.

If your immediate problem is slow generation, upgrading the protocol without measuring the generation path may solve nothing. If your problem is a rejected message or a non-working input, changing the model's inference format may only make the same invalid interface arrive faster.

Record four things before touching dependencies: the agent SDK version, the emitted protocol version, the catalog version and the deployed renderer or host. A package version alone is not a complete compatibility record.

The migration changes that deserve targeted tests

The official 0.9-to-1.0 evolution guide identifies several changes that affect working interfaces:

• Declare protocolVersion in 1.0 catalogs. Omitting it defaults to 0.9.
• Use @path for data-binding directives, but do not globally rename every path key. Message paths and ordinary application data have different meanings.
• Supply a value binding for each TextField so typed content reaches the data model.
• Remove theme from createSurface; strict validation rejects it.
• Set value explicitly to null when deleting a data-model key. An omitted value is invalid.
• Keep catalogs mixed within one surface on the same specification version.

These are reasons to migrate fixtures and validate them, rather than ask an agent to perform a repository-wide text replacement.

A small acceptance test before rollout

Start with one representative form, such as a delivery-address editor. Save a known input message and the expected application data after editing it. This is a proposed test workflow, not a reported result from a tested integration.

First, render the fixture without a live model. Type a new address, clear an optional field and submit. Check the resulting data, not just whether the controls appeared. A beautiful form that loses edits is a failed migration.

Next, introduce an unsupported component or catalog deliberately in the test environment. Confirm that the application produces a recoverable error instead of silently presenting an incomplete confirmation. Keep the previously working rendering path available while you investigate.

Finally, replay the same user journey in every actual destination. A web renderer passing locally does not clear the Android build or a third-party host. If one destination cannot accept the new contract, retain its older path rather than treating a global upgrade as mandatory.

The useful milestone is a complete interaction that survives the version change. “The agent emitted valid JSON” is a much weaker release criterion.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn developer tools and engineering decisions into clear technical stories people can understand and share.

Book a 30-minute call