Google released A2UI 1.0 on Nov. 11 as the first stable version of its open protocol for generative user interfaces. The idea is that an agent can describe an interactive view — for example, a choice card, chart or form — while the host app renders it using components the app developer has registered. It gives teams a structured way to move beyond a text reply without asking a model to send executable interface code.
What changes in A2UI 1.0?
The stable protocol adds bidirectional function calls, accessibility support and extension points for additional metadata. A flight selector, for instance, can request availability through a function call and update the choices shown in the interface. Google describes data binding as secure because apps control the registered components and their data. That is a design claim from the project team, not an independent security assessment; developers still need to implement authorization and validate every action.
A2UI separates the model’s description from the host’s presentation. The agent returns structured messages about what to show, while the app decides which native widgets can represent those messages. This lets a team reuse its design system across screens and keep confirmation steps in the app. A protocol does not itself grant an agent permission to access another company’s systems, combine services, or complete purchases.
Which platforms have a 1.0 renderer?
Google lists React, Angular and Lit renderers for the web; Flutter for mobile, web and desktop; and SwiftUI for iOS. Jetpack Compose is listed for Android, but Google says that renderer is still at version 0.9.1, with 1.0 coming soon. That distinction matters: the protocol is stable, but not every platform renderer has reached the same version.
The web and Flutter renderers can also run inside hosts that support MCP Apps. Google names Claude and Gemini as examples, and says the two technologies can work together. That is a rendering route for an app surface; it does not mean a user can open any arbitrary web interface in an assistant or that all hosts support every renderer. Developers should confirm the host, renderer and version they plan to ship against.
The release also lists agent SDKs for Python, TypeScript and Dart. Those SDKs help an agent framework generate or translate A2UI messages, but developers still choose where the agent runs and which app surfaces it can reach. Google names Atlassian, Alation, Bloomberg and ByteDance among companies building with the project. It says ByteDance’s Lynx renderer supports A2UI 0.9 today and is adapting to 1.0.
When should a maker use it?
A2UI is most relevant when an agent needs a person to review or change structured information: comparing options, editing a plan, choosing a time or confirming a consequential action. A maker can define an approved set of components, give the agent a way to compose them and let the existing app decide what is valid. Before adopting it, check renderer maturity on each target platform and test accessibility, error handling, permission checks and the confirmation path.
A2UI is a UI protocol, not a finished agent product or an automatic cross-app permission layer. Its 1.0 release makes the message format stable while renderer versions and host integrations continue to evolve. VIBPS has not independently tested the SDKs. For developers, the practical next step is to build a small flow with the official quickstart and verify exactly which parts remain under the app’s control.
How Google’s Gemini Decisions API handles structured classification
VIBPS is the social network for software, where makers can publish the apps and interactive experiences they build.