Part 3 of a 3-part series, “GenUI for Mobile Teams.” Part 1 explained the primitive and A2UI; Part 2 covered MCP and the agent stack. This part is the honest reckoning: where it breaks, and what it actually depends on.
The first two parts gave GenUI a fair hearing: a real primitive, a security-minded protocol, and a clean way to wire in tools and data. Now strip the marketing. The gap between the demo and a shippable product is wide, and it is widest in exactly the places mobile teams live. This is the part the landing pages skip.
The hype: where the story overshoots
The “UI will disappear” claim is overcooked. The maximalist version of GenUI — every user gets a freshly generated interface every time — was floated loudly by Jakob Nielsen in his 2024 essay Accessibility Has Failed: Try Generative UI = Individualized UX. It drew fierce, well-argued pushback from the accessibility and UX community — see Eric Bailey’s On Jakob Nielsen, AI hype, and accessibility — and the position was only partly walked back. The critique is worth internalising: an interface regenerated on every visit has no muscle memory, no predictability, and no guarantee of accessibility.
Accessibility is a lagging consideration, not a solved one. Generative tools do not reliably produce accessible output: generated layouts can miss heading hierarchy, colour contrast, keyboard navigation, and screen-reader support. “The AI will personalise accessibility” is a promise, not a property you get for free. On mobile, where assistive-tech integration is platform-specific and unforgiving, that is not a footnote.
Reliability and hallucination are unsolved. A systematic review of LLMs in UI/UX work found a recurring failure mode: models invent UI elements, produce invalid code, and degrade badly in under-specified scenarios, which forces manual verification and erodes trust. A dedicated study of generative-UI tools found output quality is not production-ready — truncated button text, misaligned elements — fine for ideation, risky in front of users. (See the GenUI study and the LLMs-in-UI/UX systematic review.)
Even the web pioneers hit the brakes. Vercel introduced generative UI to React with the AI SDK 3.0 streamUI / RSC approach in early 2024 — and has since marked that RSC API experimental and paused, steering teams to the more conventional AI SDK UI for production. When the team that popularised the pattern quietly de-risks its own implementation, that is data, not cynicism.
It is alpha. The Flutter GenUI SDK says so on the tin, and A2UI is explicit that the spec is still evolving. Building a product’s core experience on an alpha protocol is a strategic bet, not a default choice.
Why mobile raises the stakes
Most GenUI commentary assumes a web app you can redeploy in minutes. Mobile breaks that assumption, and every break raises the cost of GenUI’s non-determinism.
- Release latency. A bad web layout is reversible instantly. A bad mobile experience is gated by store review and by users who never update. Non-determinism that is a shrug on the web is a frozen liability on a phone.
- Offline and flaky networks. GenUI assumes a live round-trip to a model to compose the screen. On a dropped connection, “the UI is generated on demand” becomes “the UI does not appear.” Production mobile needs caching, fallbacks, and a sane offline state — none of which the demo shows.
- Latency and token cost. Composing UI through an LLM adds round-trip latency and per-interaction cost that an enterprise web backend can absorb with compute and a phone cannot.
- Platform edges. Permissions, background execution, lifecycle, safe-area and edge-to-edge layout — the platform-specific surface where generated output looks right in a simulator and fails on real hardware.
The lesson is the one that governs all AI-assisted mobile work: “it renders” is not “it works.” A surface that composes beautifully over Wi-Fi in a simulator is not proof of quality. (We made the broader version of this argument in AI Technical Debt in Mobile Development.)
The part nobody puts on the landing page: GenUI needs clean code first
Here is the connection that matters most if you already own an app. GenUI does not remove the need for senior engineering — it raises it, and it moves the work earlier.
A2UI only renders components from a curated, pre-approved catalog. The model gets a small vocabulary of your widgets and must speak inside that boundary. So the quality of a GenUI experience is capped by the quality of the catalog and the design system behind it. If your widgets are consistent, themeable, accessible, well-tested and decoupled from business logic, GenUI has good material to compose. If your app is a ten-year-old Xamarin monolith with logic welded into code-behind, screen-specific one-offs and no design system — there is nothing clean for an agent to assemble. You cannot bolt GenUI onto a mess.
A2UI does offer an escape hatch — a “Smart Wrapper” pattern that can wrap existing or legacy components — but wrapping debt is not removing it. The real readiness work for GenUI is the same work that makes any modern mobile app maintainable: a clean component catalog and a real design system, on a current stack.
That is precisely what a modernization gives you. Rebuilding a legacy mobile app — a Xamarin to .NET MAUI migration, or a move to Flutter — is, underneath, the act of producing exactly the governed, catalogued, decoupled component library that GenUI (and SDUI, and design-system governance, and a dozen future bets) all depend on. The teams that adopt GenUI cleanly in 2027 are the teams that modernize their foundations in 2026. The hype skips this step. The engineering does not.
Hype claim vs engineering reality
| The claim | The engineering reality |
|---|---|
| ”GenUI replaces designers and UI code.” | It composes from a human-designed catalog. Someone still designs the components, guardrails and system prompt. The skill moves, it doesn’t disappear. |
| ”Every user gets a perfect, personalised interface.” | Output is not yet production-grade or reliably accessible; over-personalisation removes predictability and muscle memory. |
| ”It works anywhere instantly.” | It assumes a live model round-trip. Offline, flaky-network, latency and cost realities hit hardest on mobile. |
| ”Just add GenUI to your app.” | It only pays off on a clean component catalog and design system. Legacy apps need modernization first. |
| ”It’s the new standard.” | The SDK is alpha and the protocol is pre-1.0. Promising primitive, not a settled foundation. |
The next 6 to 24 months
- GenUI settles into a feature, not a paradigm — a normal tool for agentic and adaptive surfaces, while the “UI disappears” framing fades into a post-hype, realistic phase.
- A2UI stabilises and the renderer ecosystem grows — with v1.0 approaching, the protocol is the part most worth tracking; it outlives any single SDK.
- Design systems become the differentiator — because GenUI quality is capped by catalog quality, investment shifts to governed, accessible, well-tested component libraries (modernization by another name).
- Evaluation and guardrails become table stakes — generated UI needs schema validation, accessibility checks and reliability testing, the way automated testing did a decade ago.
- The senior-engineer premium rises — as composition gets cheaper, the scarce skill is judgment: which output to trust, where it fails offline, and how to keep the catalog coherent.
How MaboaSoft helps
This is squarely the work we do. MaboaSoft is a senior mobile engineering team across Flutter, .NET MAUI, Xamarin modernization and migration, native iOS in Swift, native Android, and C#/MVVM architectures — and we treat AI tooling as an amplifier of engineering discipline, not a replacement for it.
- Legacy modernization and Xamarin → .NET MAUI migration — the clean, current-stack codebase any future UI strategy depends on.
- Design-system and component-catalog work in Flutter — consistent, themeable, accessible, decoupled widgets: the exact material GenUI and SDUI compose from.
- Native iOS / Android review and architecture — keeping platform behaviour correct where generated output silently fails.
- MVP-to-production hardening — surviving real devices, offline states and store releases; see our starter plans.
- AI inside the engineering loop — including our Code-to-Spec (C2S) approach to legacy logic recovery.
Conclusion: a promising primitive, not a finished paradigm
GenUI is neither a useless toy nor the end of UI design. It is a capable new primitive — server-driven UI with an LLM in the composition seat — that genuinely improves agentic, conversational and adaptive experiences, sits on a security-minded protocol in A2UI, and pairs naturally with MCP for tools and data. It is also alpha, not reliably accessible, non-deterministic in ways mobile punishes, and entirely dependent on the quality of the component catalog it draws from.
So the future-or-hype question has a precise answer: the primitive is real and worth tracking; the paradigm framing is hype; and the prerequisite — clean, modernized mobile code — is where the actual value is created. Build that foundation, and GenUI becomes a tool you adopt on your terms. Skip it, and GenUI is one more impressive demo your codebase cannot cash.
Continue the series: Part 1 — what GenUI actually is → · Part 2 — GenUI, MCP and the agent stack →
Have a legacy Xamarin app, or a Flutter / .NET MAUI / native product you want ready for what’s next? Book a 20-minute call → We’ll review your architecture, modernize the foundations, and build the clean component system that makes adopting GenUI — or any future UI bet — a decision, not a gamble.
FAQ
Is GenUI production-ready for mobile apps? Not as a wholesale strategy. The SDK is alpha and the protocol is pre-1.0; generated output is not reliably accessible or pixel-consistent; and the live-model round-trip is a poor fit for offline and flaky-network conditions. It is suitable today for specific agentic, conversational and adaptive-form features inside an otherwise conventional app.
How does GenUI relate to legacy modernization? Directly. GenUI can only compose from a clean, curated component catalog and design system. Legacy apps — for example old Xamarin codebases — usually lack that. Modernizing the app (Xamarin → .NET MAUI or Flutter) produces exactly the governed component library GenUI depends on, which is why modernization is the real prerequisite.
Does GenUI replace mobile developers and designers? No. It moves the work earlier and up the stack: designing the component catalog, the guardrails, the system prompt, and the architecture that keeps generated output safe and consistent. The judgment becomes more valuable, not less.
Resources & further reading
The skeptical / UX case (read these before betting on it)
- Jakob Nielsen — Accessibility Has Failed: Try Generative UI = Individualized UX: https://jakobnielsenphd.substack.com/p/accessibility-generative-ui
- Eric Bailey — On Jakob Nielsen, AI hype, and accessibility (rebuttal): https://ericwbailey.design/published/on-jakob-nielsen-ai-hype-and-accessibility/
- CSS-Tricks — Generative UI notes (balanced overview + accessibility gaps): https://css-tricks.com/generative-ui-notes/
- Nielsen Norman Group — the UX reset (post-hype realism): https://www.nngroup.com/articles/ux-reset-2025/
- The GenUI Study (arXiv) — quality & fidelity gaps: https://arxiv.org/abs/2501.13145
- Systematic review — LLMs in UI/UX design (hallucination, reliability): https://arxiv.org/abs/2507.04469
The broader ecosystem
- Vercel — Introducing AI SDK 3.0 with generative UI: https://vercel.com/blog/ai-sdk-3-generative-ui
- Vercel AI SDK — current docs (RSC API now experimental/paused): https://ai-sdk.dev/docs/introduction
MaboaSoft
- AI Technical Debt in Mobile Development (“it renders ≠ it works”): https://maboasoft.com/blog/ai-technical-debt-mobile-flutter-dotnet-maui
- AI engineering & the Code-to-Spec (C2S) approach to legacy logic recovery: https://maboasoft.com/ai
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.