A2UI Renderer Roadmap: React and v1.0 Status

[!IMPORTANT] August 24, 2026 update: The official repository identifies v0.9.1 as the current production line and v1.0 as a candidate. Earlier dates in this article were projections and have been replaced with verified current status.

The practical renderer question is no longer simply “when will React arrive?” Teams now need to choose a protocol version, a renderer path, and an upgrade policy that match their product. A2UI has an active v0.9 specification, a v1.0 candidate, official renderer guidance, and Composer tooling that demonstrates multiple web implementations.

Current protocol status

The official A2UI repository distinguishes three lines:

• v0.9.1 is the current production version.
• v1.0 is a candidate specification and may still change before adoption.
• v0.8 is retained as a legacy version for existing integrations.

That distinction matters more than a calendar estimate. Message names and component shapes changed between versions, so an agent emitting one version must not feed a renderer built for another. Pin the version throughout prompts, schemas, fixtures, transports, catalogs, and clients. Treat a protocol upgrade as a compatibility project with explicit tests.

Renderer choices today

The official project documents renderer implementations and provides guidance for building a custom renderer. For web applications, the renderer development guide recommends using the project’s web core where appropriate so message processing does not have to be reimplemented from scratch. The host application still owns its component catalog, design system, action handlers, validation policy, and security boundary.

A2UI Composer and its Theater provide a practical way to inspect generated interfaces and compare supported renderer output. Composer currently exposes Angular, Lit, and React-oriented experiences. Its presence is useful evidence of the current ecosystem, but generated output still needs validation against the exact protocol and catalog used by your application.

Flutter remains relevant for cross-platform applications, while web teams can adopt an existing renderer or implement the protocol against their own component system. The correct choice depends on catalog coverage, accessibility, framework constraints, maintenance ownership, and how much control the host requires.

What React teams should do

React teams should evaluate the current implementation rather than design around an expired projected date. Start with a narrow proof of concept:

1. Pin A2UI v0.9.1 unless you are intentionally evaluating the v1.0 candidate.
2. Define a small, host-owned catalog using existing accessible components.
3. Validate every agent message before it changes application state.
4. Map declarative actions to reviewed application functions; never execute agent-supplied code.
5. Test streaming, duplicate updates, deletion, reconnection, unsupported components, and failure fallbacks.
6. Store representative message streams as fixtures for upgrades.

The value of A2UI is the separation between declarative interface data and native host components. A React renderer should preserve that boundary. It should not turn the payload into raw HTML or allow the model to import arbitrary components.

Evaluating v1.0

The v1.0 candidate is useful for design evaluation, but “candidate” is not the same as a production compatibility guarantee. Compare its schema and lifecycle with v0.9.1, list every breaking change that affects your catalog or transport, and keep candidate experiments isolated from production streams.

Before adopting v1.0, require published versioned schemas, passing contract fixtures, renderer compatibility, migration documentation, and a rollback route. Avoid encoding a release quarter into application URLs or permanent documentation slugs; status changes more often than the underlying topic.

A durable roadmap policy

Roadmap pages age quickly when they present projections as promises. A durable implementation policy is simpler:

• the official repository and versioned specification are the source of truth;
• production uses one pinned, tested protocol line;
• candidate versions are evaluated separately;
• renderer capability is verified from current documentation and code;
• dates are labeled as historical when no longer current;
• evergreen URLs are retained while page metadata records updates.

This article keeps its original route so existing links and search signals remain stable, but its title and content now describe the current topic instead of an outdated quarter. See What is A2UI?, the message reference, and the production-readiness guide for implementation details.