AGenUI: a native A2UI renderer for iOS, Android and HarmonyOS

The problem AGenUI addresses: streaming component trees, not HTML

An LLM that produces user interface has two obvious delivery options. It can emit markup, which the client drops into a webview, or it can emit structured component descriptions that the client draws with its own widgets. AGenUI takes the second route. The README describes it as an A2UI SDK that renders "the streaming data of LLM-generated interactive UI in real time on mobile devices", and the components arrive incrementally rather than as one finished document. That distinction matters for perceived latency. A form can appear field by field while the model is still generating, instead of the user watching a spinner until the last token lands.

The intended audience is mobile teams that already have, or plan to have, a server side emitting A2UI v0.9. AGenUI is the client half of that arrangement. It does not generate UI, does not call a model, and does not decide what the interface should contain. It parses, diffs, lays out and draws. If your product has no component protocol on the wire, this SDK has nothing to consume.

Shared C++ core, three native renderers, and where the boundary sits

The architecture is a shared C++ engine plus per-platform rendering engines. According to the README, the C++ layer handles streaming data parsing, virtual component tree management, render data caching, theme and style resolution, and component change diffing. It then synchronizes the parsed component protocol to the platform renderers, which trigger drawing with native system capabilities.

That split is visible in the repository layout. The core engine lives in core/, with the public C++ API consumed by the bridging layers under core/include/. Each platform gets its own directory: platforms/ios/ holds the Objective-C bridge, platforms/android/ the JNI bridge, platforms/harmony/ the NAPI bridge. The playground/ directory contains three-platform demo apps, and scripts/ holds per-platform build scripts.

The practical consequence is that protocol parsing and diffing behave identically everywhere, while drawing does not. Text measurement, line height and pixel snapping are implemented per platform, and the release notes reflect that: the 1.5.0 notes include a HarmonyOS rework of line-height measurement, an iOS change to physical pixel alignment, and an Android fix for text disappearing on unbreakable digit and CJK strings at specific screen densities. Those are rendering-layer bugs, not core bugs. Expect cross-platform visual differences to surface at this boundary rather than in the parser.

What you get out of the box: 22 components and a custom component API

The README counts 22 built-in components: 18 that implement the A2UI protocol specification and 4 SDK extensions. The protocol set covers Text with h1 to h5 and body variants, Image, Icon, Divider, Video with seek and auto-hiding controls, AudioPlayer, Button, Row, Column, Card, List, Tabs, Modal, TextField, CheckBox, Slider, ChoicePicker and DateTimeInput. The extensions are bundled but outside the specification; the README lists Table as one of them, described as a data table with Yoga sub-layout, and the remaining three are not named in the material available here.

For anything outside that set, there is a custom component API. The README says you register and extend native components through it "so the LLM can emit component descriptions by component name". That is the escape hatch that decides whether the SDK fits a real product. If your interface needs a map, a chart or a payment sheet, the model refers to it by name and your platform code supplies the drawing. The cost is that you write that component three times, once per platform, unless the shared core can carry the logic.

There is also Function Call integration: client-side tools and functions can be registered so the model can invoke them on demand. The core/ directory description lists the Function Call framework alongside the parser, differ and layout.

Platform floors and getting a build running

The badges in the README set the minimums: Android API 21+, iOS 13+, HarmonyOS NEXT API 17+. Those are floors, not recommendations, and they are stated as badges rather than in prose, so treat them as the declared support envelope.

The README points to docs/QuickStart.md for setup and docs/API.md for the reference, and the repository ships build scripts per platform under scripts/. Because the quick start document is not included in the material available here, the exact build commands cannot be quoted. What can be stated is the shape of the integration: the core is C++, so each platform links a native library and talks to it through a bridge, which means your build system has to compile or link that core rather than pulling a pure Swift or Kotlin artifact.

The one concrete API call in the release notes is iOS runtime configuration. AGenUI.setRuntimeConfig(_:) accepts a JSON string of runtime switches from the host so behavior can be toggled remotely, and the notes say to call it once during SDK initialization, before any surface renders. The same notes name borderPixelAlignment as a switch, default on, which promotes hairline borders to an integer physical pixel width and snaps component frames to the physical pixel grid so adjacent siblings stay gap-free. That is the kind of option you would want to set deliberately rather than leave at the default, since it changes frame geometry.

The 1.5.0 beta is not a drop-in upgrade on iOS

The most recent release in the list is AGenUI-1.5.0.beta1, published 2026-09-04, a beta. The stable line behind it is AGenUI-1.4.0 from 2026-08-28, with a 1.4.0.beta2 before that. Anyone pinning a version should notice that the head of the release list is a beta and the previous stable is roughly two weeks older.

The 1.5.0 notes contain a breaking change on iOS. The blank-check callback gains a parameter: onBlankCheckResult now reports the component-tree size at detection time, and the signature becomes onBlankCheckResult(_ surface:isBlank:componentCount:). Code that implements the old two-argument form will not compile against the new header. This is a small surface, but it is a source-level break, and it lands in a beta release. If you ship on iOS and use the blank-check callback, budget for that edit and test it rather than assuming the upgrade is mechanical.

The same release also lists fixes that suggest where the SDK has been fragile. On Android, text disappearing for unbreakable digit and CJK strings at specific screen densities was fixed by aligning measurement metrics with the rendering path. On iOS, properties applied during component initialization, most visibly a constant trackInfo, never reached listeners. On HarmonyOS, DateTimeInput measurement carried a stale line-height override. Three platforms, three measurement or property-propagation defects in one cycle. That is normal for a young cross-platform renderer, but it tells you the testing surface is wide and the release cadence is fast.

Where AGenUI is the wrong choice

The clearest boundary is the target list. AGenUI renders on iOS, Android and HarmonyOS. There is no web target in the README, no desktop target, and no server-side rendering path. If your product ships a browser client, this SDK does not cover it, and the streaming component tree you send to mobile will need a separate renderer for the web.

A second boundary is the dependency on A2UI v0.9. AGenUI is described as built on and fully implementing the protocol open-sourced by Google. That is a commitment to someone else's specification. If the protocol version moves, your server and this client have to move together, and the SDK's own release notes already show a fast cadence: 1.4.0.beta2, 1.4.0, then 1.5.0.beta1 inside about three weeks. A team that upgrades native dependencies on a quarterly cycle will be several protocol revisions behind by the time it ships.

A third boundary is the C++ core itself. It is the reason parsing and diffing are consistent across three platforms, and it is also the reason your build gets more complicated. Projects that deliberately keep their mobile builds free of a shared native library, or that rely on managed toolchains end to end, will find the bridge layer an unwelcome addition. The README also carries an explicit warning that the project is under active development and evolving rapidly, which is a statement about stability, not marketing copy.

How this differs from a webview-based generative UI stack

The obvious alternative for LLM-generated interfaces is to have the model emit HTML or a similar markup dialect and render it in a webview, which is how a large share of generative UI demos work today. The difference is not cosmetic. A webview gives you the full CSS and DOM surface, so the model can produce layouts nobody anticipated, and you get one renderer for every platform including the browser. The price is a second runtime inside your app, a bridge between native and JavaScript for every interaction, and scroll and gesture behavior that is not the platform's own. Text selection, accessibility and input methods all come from the web engine rather than the system.

AGenUI inverts those trade-offs. The model can only emit the components the SDK knows about, which is 22 built-ins plus whatever you register through the custom component API. That is a hard ceiling on expressiveness, and it means the model cannot invent a layout the client has never seen. In exchange, drawing goes through native system capabilities, and the README claims a 120 fps refresh rate in core scenarios such as page scrolling. That figure comes from the project's own documentation, not from independent measurement, and it should be read as a target the SDK is built around rather than a guarantee for your component mix.

The two approaches also differ in where the work happens. With a webview, the diffing and layout are the browser's problem. With AGenUI, the C++ core owns the virtual component tree, the render data cache and the change diffing, and it pushes updates to three platform renderers. That is more code you depend on, and it is why the release notes keep returning to measurement and property propagation.

Licence, maintenance and what to check before committing

The licence is Apache-2.0, stated in the README badge and in the repository metadata, with a LICENSE file at the root. Apache-2.0 permits commercial use and modification and includes an explicit patent grant, which matters for a component that may end up in a shipped mobile binary. It also requires that you preserve notices and state significant changes. This is a description of the licence text, not legal advice; have your own counsel review it if the SDK is going into a product.

Maintenance cost is the harder question, and the material supports a few concrete observations. The project ships beta releases alongside stable ones, so you can pin to a stable tag and skip the betas, at the cost of waiting for fixes that first appear in beta. The 1.5.0 notes show three platform-specific rendering fixes in a single cycle, which means upgrading is not purely a matter of bumping a version number: each platform's rendering layer has its own defect history, and a fix on one platform does not imply the others are clean.

Before adopting, check three things against your own requirements. First, confirm that the A2UI components you depend on are inside the 18 protocol components plus 4 extensions the README lists, and read docs/API.md for the ones you will actually use. Second, read the font-weight caveats: all three platforms accept normal, medium and bold plus numeric 100 to 900 weights as a JSON number or an integer string, but the README says platform caveats are documented in the catalog, which implies the weights do not behave identically everywhere. Third, decide whether you can live with the iOS blank-check signature change in 1.5.0 and whether you will pin to 1.4.0 instead. Those three checks are answerable from the repository today; the 120 fps claim is not, and you will have to measure it against your own component tree.

Editorial conclusion

Adopt AGenUI if you already emit A2UI v0.9 and need the same component tree drawn natively on iOS 13+, Android API 21+ and HarmonyOS NEXT API 17+, and if you can absorb the iOS 1.5.0 beta breaking change to the onBlankCheckResult signature. Do not adopt it if you need a browser target, or if you cannot commit to tracking an SDK that the README describes as evolving rapidly. Verify first that the A2UI components you depend on are among the 18 protocol components plus 4 extensions listed in the README, and check the font-weight platform caveats in the catalog before you rely on numeric weights.

Official sources

1. AGenUI/AGenUI on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases