Part 1 of a 3-part series, “GenUI for Mobile Teams.” This part demystifies generative UI and the A2UI protocol. Part 2 covers MCP and the agent stack; Part 3 is the reality check on hype, accessibility and legacy code.
Every few years a demo arrives that makes UI feel obsolete. You type a sentence, and a complete, interactive screen materializes — a form, a product carousel, a booking flow — without a designer or a developer touching it. The current name for that demo is GenUI, and in 2026 it is everywhere: the Flutter docs, Google I/O keynotes, agency landing pages. The honest question for a mobile team is not “is it magic?” It is “what is it actually, and where does it earn its place in a real app?” Let’s start with the what.
There is a recurring pattern in mobile engineering. A capability looks like a revolution in a keynote, then spends two years finding the narrow band of problems it actually solves well. Cross-platform did this. On-device ML did this. AI code generation is doing it right now. GenUI is the newest entry, and it deserves the same treatment we give any tool wrapped in the word “paradigm”: take it seriously, strip the marketing, and find the load-bearing engineering underneath.
Our short answer, which this series unpacks: GenUI is a real and useful primitive that is being oversold as a paradigm shift. It solves a specific class of problems well, it does not replace designed interfaces, and it only pays off on a clean, well-architected codebase. This first part is about understanding the primitive honestly.
What GenUI actually is (and what it is not)
Strip away the framing and GenUI is an old idea with a new engine. Instead of shipping a fixed screen, the server — driven by an LLM — describes which components to show and how they relate, and the client renders them with its own native widgets. Google’s framing is blunt about this: the Flutter GenUI SDK is an orchestration layer that composes a UI from your existing widget catalog using a JSON-based format, and it is explicitly marked alpha and likely to change.
It is not “the AI paints pixels.” It is not the model writing and running UI code. The model emits a structured description; your app decides what that description is allowed to mean. The protocol underneath makes that distinction the whole point.
That protocol is A2UI (Agent-to-UI), open-sourced by Google in December 2025 under Apache 2.0 and developed in the open on github.com/google/A2UI. Its core design decision is a security decision: A2UI is declarative data, not executable code. The agent can only request components from a catalog you have pre-approved — Card, Button, TextField, your own custom widgets — so an interface generated by a remote, untrusted agent is “safe like data, but expressive like code.” The current production release is v0.9.1, with v1.0 a release candidate (see the A2UI specifications, the introductory announcement, and the v0.9 update). The Flutter GenUI SDK uses A2UI under the covers when it talks to a server-side agent.
Why this matters for mobile specifically: A2UI is framework-agnostic. The same JSON payload can render through the Flutter renderer, the official React renderer, Angular, Lit, or a community renderer. One agent response, many native frontends. For a cross-platform shop, that is a genuinely interesting property — not a gimmick.
It is not new — it is server-driven UI reborn
Engineers who have shipped at scale will recognise the shape immediately: this is server-driven UI (SDUI) with an LLM in the loop. Airbnb, Spotify and others have run SDUI in production for years — the server sends a description of the screen, the client renders native components, and you can change layouts without an app-store release. (Airbnb’s engineering team documented their Ghost Platform approach to server-driven UI in detail.)
What is new is who composes the layout. In classic SDUI, a backend service or a human-authored rule decides the response. In GenUI, a model decides, in real time, based on the conversation. That is the upgrade and the risk in one sentence: the flexibility goes up, and the determinism goes down. Everything good and everything dangerous about GenUI flows from that single change.
The promise: where GenUI genuinely earns its place
Be fair to the technology. There is a real band of problems where GenUI is not hype at all.
Agentic and chat surfaces. The strongest case is the one Google leads with: an assistant that answers with widgets instead of a wall of text. Ask for restaurants and get a tappable carousel; ask to book and get a real form with a date picker. The Flutter team’s pitch, paraphrasing, is that the UI should map itself to what you are trying to do, instead of forcing you to map your intent onto a fixed set of taps. For conversational and agent-driven features, that is a legitimate UX win.
Adaptive forms and long, branchy flows. A multi-step task that would normally need a dozen hand-built screens can collapse into one surface that adapts to the answers so far. This is the use case agencies demonstrate most convincingly, and it holds up.
Server-driven flexibility without a release cycle. Because the layout is data, you can change an experience without shipping a new binary through store review — the long-standing SDUI benefit, now with an LLM choosing the composition.
One catalog, every platform. Via A2UI, a single agent can drive Flutter on mobile and desktop, and React or Angular on the web, each rendering with native components and your own design system. For teams maintaining parallel stacks, that is real leverage.
If you want to see the primitive working rather than read about it, the most useful starting points are the GenUI get-started guide, the components and concepts page, the flutter/genui sample repo, and Very Good Ventures’ step-by-step home-screen tutorial.
Where this leaves us
GenUI is a capable new primitive: server-driven UI with an LLM in the composition seat, running on a security-minded protocol in A2UI. That is the honest “what.” But a primitive is not a product. An agent that composes a UI needs something to compose about — data and actions — and the generated interface has to survive the realities of a phone. Those are the next two questions.
Continue the series: Part 2 — GenUI, MCP and the 2026 agent stack → explains how the agent actually gets its tools and data, and the two competing ways to give it a UI. Part 3 — the reality check → covers where the hype overshoots and why GenUI starts with clean code.
Building agentic or adaptive features in Flutter, .NET MAUI or native iOS/Android? Book a 20-minute call →
FAQ
What is GenUI (generative UI)? A pattern where an AI model composes an interface at runtime instead of returning plain text. The model describes which UI components to show; the client renders them with its own native widgets. In Flutter this is delivered by the GenUI SDK, which uses the A2UI protocol to talk to server-side agents.
Is GenUI the same as the Flutter GenUI SDK? No. GenUI is the general concept; the Flutter GenUI SDK is one implementation — an orchestration layer that composes UI from your widget catalog — and it is currently alpha. The A2UI protocol underneath it is also used by non-Flutter renderers (React, Angular, Lit).
What is the A2UI protocol? An open-source, Apache-2.0 protocol from Google that lets agents send a declarative JSON description of an interface, which clients render with pre-approved native components. Because it transmits data rather than executable code, it is designed to be safe even when the agent is remote or untrusted. Current release: v0.9.1, with v1.0 a release candidate.
Resources & further reading
Official / primary sources
- Flutter GenUI SDK — overview: https://docs.flutter.dev/ai/genui
- Flutter GenUI SDK — components & concepts: https://docs.flutter.dev/ai/genui/components
- Flutter GenUI SDK — get started: https://docs.flutter.dev/ai/genui/get-started
- Flutter blog — Rich and dynamic UIs with generative UI: https://blog.flutter.dev/rich-and-dynamic-user-interfaces-with-flutter-and-generative-ui-178405af2455
- flutter/genui — sample apps & SDK source: https://github.com/flutter/genui
- A2UI — protocol home & specs: https://a2ui.org/
- A2UI — source code (Apache 2.0): https://github.com/google/A2UI
- Google Developers Blog — Introducing A2UI: https://developers.googleblog.com/introducing-a2ui-an-open-project-for-agent-driven-interfaces/
Hands-on tutorials & deep dives
- Very Good Ventures — What is GenUI?: https://verygood.ventures/blog/what-is-genui/
- Very Good Ventures — GenUI home-screen tutorial: https://verygood.ventures/blog/flutter-genui-home-screen-tutorial/
- Cagatay Ulusoy — From structured outputs to A2UI surfaces (migration write-up): https://ulusoyca.medium.com/from-structured-outputs-to-a2ui-surfaces-migrating-to-flutter-genui-sdk-4f09aeacee80
- DEV Community — The complete guide to the A2UI protocol (2026): https://dev.to/czmilo/the-complete-guide-to-a2ui-protocol-building-agent-driven-uis-with-googles-a2ui-in-2026-146p
Background concepts
- Airbnb Engineering — a deep dive into Airbnb’s server-driven UI system: https://medium.com/airbnb-engineering/a-deep-dive-into-airbnbs-server-driven-ui-system-842244c5f5
Written by the MaboaSoft engineering team. We build and modernize mobile apps in Flutter, .NET MAUI, Xamarin, native iOS and native Android for SaaS vendors and product companies.