Choosing a Cross-Platform Framework When the Demo Is an Agent

At Google I/O 2026, Google showcased a chatbot that stopped replying in prose and started assembling its own interface at runtime. That demo is now the loudest input into a decision it has no business touching: which cross-platform framework your app gets built on.

Choosing a cross-platform framework is a maintenance and hiring decision. Generative UI is a decision about whether your screens exist before a user asks for them. Both arrived in the same keynote, so they get argued as one question, and picking the framework off the demo bills you later: a rewrite nobody budgeted, or a hiring search for a language your engineers cannot read.

What choosing a cross-platform framework actually commits you to

A framework choice is four commitments: how your controls get drawn, whether you can ship a fix without waiting on app review, who you can hire to maintain the code, and whose upgrade calendar you now follow.

The first two are fixed at the framework level and cannot be worked around later. Flutter paints every control with its own engine, so a text field is a Flutter text field and behaves like one. React Native maps to real platform views, so the same field gets the OS text-selection menu without anyone building it. On delivery, React Native can push a new JavaScript bundle over the air and repair a broken checkout without waiting on review, while Flutter compiles Dart ahead of time and every change goes through the store.

Those are different failure modes rather than different quality levels. If you ship a fix the day you find it, the over-the-air path is worth the rendering compromise. If you ship monthly, that trade costs you rendering control for nothing.

The hiring pool settles most of these decisions. Dart is written almost exclusively for Flutter, and the plugin you need for a card reader or a BLE lock is maintained by whoever in that community cared enough. TypeScript is a language the web developers you already interview can read on their first day. Our React Native and Flutter comparison has the full side by side, and native versus cross-platform covers the case for skipping both. Whichever way you go, check the last commit date on every dependency you need before you build on it.

What agent-composed UI does to your QA and app review

A screen a model assembles at runtime has no golden image, so screenshot-diff regression testing has nothing left to compare against. That is the cheapest test suite a mobile team owns.

Accessibility is the same problem in a worse form. An audit walks a finite set of states and checks labels and focus order on each one. A composed layout has no finite set of states until a user produces one, so the audit stops being a document you can hand to a procurement team.

App review is where this turns commercial. Apple and Google review how a build behaves, and a build whose layout arrives from a model can render something no reviewer ever saw. If that something takes a payment outside store rules or surfaces content a guideline forbids, the app comes down, and the model’s output is yours to answer for.

A launch build across both stores sits in the ₹10L – ₹14L band in our guide to mobile app costs, and that figure covers screens somebody specified and tested. Generated composition adds test surface that sits outside that scope, which is the argument for bounding it: give the agent a closed set of primitives, declare which layouts it may produce, and log the composition decision next to the session so a support ticket can be reproduced.

Does one language for the app and the backend save you money?

The other half of the pitch is Dart on the server, with cloud functions and model orchestration in the same language as the client. That saving is real and narrower than it sounds. It removes context switching and a duplicated set of domain types. It does not remove a backend engineer.

What it adds is a thinner hiring pool on the server as well as the app, and a runtime with less production mileage behind it than Node or the JVM. For a greenfield product with no backend yet, the trade is usually worth taking. For a team already running a backend that works, moving buys a tidier repository and a migration nobody asked for.

There is a cheaper route to most of the benefit: generate your types on both sides from one API schema, and the shared-language question stops costing you anything.

Pick a cross-platform framework on these answers

Ask these while the decision is still free. Which of your screens are fixed layouts, and which would an agent compose at runtime? Who does the annual OS-release work, and does it sit inside a retainer or arrive as a change order? When a user reports that a button was missing, how do you reproduce what they saw? And who maintains this after the team that built it moves on, in which language?

Generated UI is a feature with an operating bill attached, and the framework underneath it is settled by maintenance and hiring. Discovery on a mobile app build goes on exactly these answers before anyone designs a screen, because each one is expensive to reverse.

Write out every screen your app must have and ask whoever is pitching which of them an agent would assemble at runtime. Take back any screen on that list that takes a payment or shows a medical record.