.png)
Flutter's official SDK for AI-generated interfaces launched in alpha in November 2025. Teams are already experimenting with it. Before you jump in, it's worth understanding what it promises, what it delivers, and where it still falls short.
GenUI launched in alpha in November 2025, an official Flutter SDK that lets a language model compose real widgets at runtime. No Dart code generation. No embedded HTML. A native, live Flutter interface from a prompt. At Google I/O 2026, it was featured in demos that made it look almost magical.
The community received it with enthusiasm, and understandably so. But the story is quite a bit more nuanced than the conference demos suggest.
Here's our hands-on take.
What GenUI is and how it works
First thing to get straight: GenUI is Flutter's official SDK (built on top of A2UI (Agent-to-UI), an open protocol from Google)Â that defines how an AI agent and a Flutter app talk to each other to build interfaces in real time. GenUI doesn't generate Dart code.
The flow, step by step:
Three pieces are worth understanding before looking at code.
The Catalog. You define which components the model can use: a RecipeCard, a ProductGrid, a ConversationBubble. Each one has a JSON schema and a Flutter widget. The model can only use what's in the catalog, it can't invent UI on its own.
The Surface widget. This is the container where everything appears. You pass it a SurfaceController, and it receives the model's JSON, validates it, and builds the widget tree.
The event loop. When the user taps something, that event goes back to the model as part of the conversation. The model responds by updating the UI or advancing the flow. It's not a static render, it's a continuous cycle.
What it looks like in code
The SDK is available as the official GenUI package on pub.dev (current stable: 0.10.3). Here's what registering a component looks like:
And in the widget tree, Surface takes the controller and renders whatever comes in:
đź’ˇ Key detail
The model never sees Dart code. It only receives the JSON schemas of the available components ( validated client-side by the Surface widget, not by the model. That means the model can't generate arbitrary UI)Â it can only combine what you've offered it, and any response that doesn't conform to a schema is rejected before it reaches the widget tree.
When GenUI actually wins
There are cases where GenUI doesn't just work, it genuinely wins. They become pretty obvious pretty fast.
Interfaces that change per user
If each user should see something different based on their context (history, preferences, state) GenUI handles it without you writing custom presentation logic. The model adapts the screen to the conversation.
Chatbots with rich UI
A chatbot that only responds with text leaves enormous potential on the table. With GenUI, the response can be a RecipeCard, a CalendarPicker, a ProductSelector. The conversation and the UI become the same thing.
Product changes without a deploy
Changing how the model composes a screen doesn't require touching code, just the system prompt. For certain product adjustments, that's a real time saver. This holds when your system prompt lives server-side or in a remote config, not when it's hardcoded in the app.
The concrete limitations
GenUI has intentional design constraints, but they tend to show up only once you start building.
The catalog is the ceiling
The model can't do anything that isn't in the catalog. That's a safety feature, sure, but it also means you still design all possible components upfront. The design burden doesn't disappear. It shifts to the moment you assemble the catalog.
‍Latency on discrete actions
Not every interaction goes to the model. Typing and slider movement resolve locally, the model is only called on discrete actions: a tap, a submit, a selection. On real-world connections, these round-trips often exceed a second. For flows where users expect instant feedback on every keystroke, that's a problem worth designing around early.
⚠️ Real limitation
GenUI doesn't replace static UI for performance-critical flows. Payment screens, form-heavy flows, and real-time data dashboards are still better as traditional Flutter. The model round-trip is the wrong tradeoff when speed or precision is non-negotiable.
Debugging has more layers
When something breaks, the stack runs through the model, the transport, the parser, and the widget. Figuring out whether the problem is the prompt, the generated JSON, or the widget itself takes longer than you'd expect at first.
Token cost scales
Every interaction sends the full history plus the catalog schemas. In a long session, the context grows. Modeling token cost in production is something you need to do before committing to the architecture.
Additional risks worth flagging early
For teams evaluating GenUI at a technical leadership level: automated testing is harder when behavior is prompt-driven rather than deterministic; accessibility depends entirely on what your catalog widgets implement; observability requires logging at the model layer, not just the widget layer; any UI that processes user data through a third-party LLM needs privacy review; and because the SDK is still in alpha, the API can change between minor versions — migrations will be part of the deal until 1.0.
GenUI: yes or no?
The question isn't "should I use GenUI?" but "which part of my app makes sense for it?"
Use case guide:
- Conversational app where UI is part of the response → Ideal
- Per-user dashboard personalized from their history → Ideal
- Adaptive onboarding with conversational questions → Consider
- Payment form or business-critical flow → Not recommended
- Existing app with no conversational component → Not recommended
Is GenUI worth it?
Yes, for the right use case. If you're building an app where UI is part of a conversation, GenUI is the cleanest solution available right now. It's official, it's well-designed, and it solves a problem that used to require a lot of custom plumbing.
At Somnio, we ran an internal spike on a conversational onboarding flow. The catalog-based model clicked quickly, the Surface widget handled validation cleanly, and the event loop made multi-step conversations surprisingly straightforward. We came away confident it's production-viable for the right type of feature, not a rewrite of existing UI, but a first-class home for anything genuinely conversational.
The caveats are real: alpha means API changes, latency means thoughtful UX, and token cost means architecture decisions you shouldn't defer. None of those are reasons to avoid it — they're reasons to go in informed.
If your next feature has a conversational component, GenUI should be the first thing you evaluate.
‍
If you’re searching for a trusted software development partner, look no further. Contact us today to learn how we can help you turn your vision into reality with our tailored, high-quality solutions.
