Skip to content
On this page

A2UI Renderer Ecosystem

Maintained and community A2UI renderers by platform, protocol compatibility, and production selection criteria.

Updated: 8/6/2026 Reviewed by: HiA2UI Editorial Team Ecosystem checked 2026-08-06

A2UI renderer ecosystem

A renderer validates A2UI messages, maintains surface state, maps approved catalog entries to native components, and routes user actions back to the agent. Transport and rendering are separate responsibilities.

Web, mobile, desktop, and terminal renderers arranged around a shared validated A2UI protocol core

Maintained renderers

RendererPlatformv0.9.1Notes
@a2ui/reactReact webStableOfficial renderer built on @a2ui/web_core
@a2ui/litWeb ComponentsStableFramework-neutral web option
@a2ui/angularAngular webStableAngular service and component host integration
Flutter GenUIMobile, desktop, webStableNative Flutter widgets with application-owned transport

Official SwiftUI and Jetpack Compose renderers remain planned. Do not describe an initial repository implementation as a stable released renderer.

Notable community renderers

ProjectPlatformCompatibilityDistinct value
AGenUIiOS, Android, HarmonyOSv0.9Shared C++ core, native engines, Studio and generation skill
Lynx GenUIMobile, web, desktopv0.9ReactLynx runtime and catalog tooling
A2UI-SwiftApple platformsv0.8–v0.9.1SwiftUI, UIKit and AppKit through a shared core
a2ui-vueVue 3v0.8/v0.9 branchesVue Composition API and TypeScript
Bote A2UIReact webv0.8/v0.9Playground, preset charts/tables and custom component kit
a2ui-inkTerminalv0.9Interactive CLI rendering through Ink
generative-muiReact + MUIv0.9Host ThemeProvider, charts and runtime custom components

Community projects are not interchangeable with maintained packages. Check the latest commit, supported protocol revision, test coverage, license, release artifacts, accessibility behavior, and security model before adoption.

Selection criteria

  1. Match the application’s native framework; do not add a webview solely to reuse a renderer.
  2. Require explicit v0.9.1 compatibility for new production work.
  3. Prefer a renderer built on @a2ui/web_core for web frameworks unless there is a documented reason to reimplement protocol state.
  4. Verify two-way binding, incremental updates, action routing, schema validation, and unsupported-component behavior.
  5. Test custom catalogs with real production components, not only the Basic Catalog demo.
  6. Measure large lists, image loading, streaming churn, and memory use on target devices.

Authoritative directories