Verification Is the Bottleneck: Flutter Team Makes the Case Against Writing Every App Twice

The Flutter team published a long argument on October 20, 2026 that addresses a question circulating in mobile engineering leadership: if AI models can generate Swift and Kotlin in an afternoon, why maintain one cross-platform codebase? The post, by Carlos Mendonça and Emma Twersky, answers with a distinction between the first day of a project and the two thousandth.

Their framing is deliberately narrow. AI has genuinely made migration cheaper, and the post concedes it. What it disputes is the inference that follows, that a unified codebase has lost its economic advantage.

Day 1 Is Not Day 2,000

The first observation is that a production codebase is not a bundle of screens, it is accumulated memory. An agent rewriting an app on day one performs well because a greenfield project carries no history: syntax translation, REST endpoints, layouts, and data models are the material models are strongest on. A mature codebase instead holds settled product debates, post-mortem findings, compliance rules, and edge case fixes, none of which appear in a specification handed to an agent.

Eric Seidel, the Shorebird founder and Flutter co-creator, is quoted making the point sharply: an application is not a bundle of UI screens but an artifact of intent delivery and intent capture. Under that definition, asking AI to write an app twice does not remove complexity. It bifurcates it, because each new requirement and edge case has to be resolved and maintained independently in every stack.

The second observation is quantitative: coordination overhead between N discrete interfaces grows as N times N minus one, divided by two, and the assumption that agents absorb that tax does not hold. Generation is probabilistic, so two agents given identical prompts in different language paradigms make different assumptions and can both pass local tests while behaving differently in production. The post cites a checkout state machine written on iOS as an asynchronous stream that drops stale events and on Android as a reactive flow that queues them. Android conversion later fell three percent because retry timing diverged during network drops. Flutter reduces this to one state machine and one source of business logic.

Verification Is the Bottleneck, Not Generation

The third observation is the central claim of the piece. Code generation stopped being the expensive part of software development, and verification became the constraint instead. The post cites survey figures that 73 percent of developers feel more productive starting tasks with AI, while 46 percent do not trust AI accuracy for critical debugging without manual inspection. An agent improves only as fast as its feedback loop allows.

• Code to run latency: two to five minutes per build, link, archive, and simulator deployment in native workflows, against under 200 milliseconds through stateful hot reload into the running Dart VM
• Automated testing: operating system simulator lifecycles and background emulators, against widget tests completing in under 500 milliseconds in hermetic environments
• UI and state inspection: screenshots passed to vision models to infer layout accuracy, against structured queries of the exact widget and render object tree through the Dart VM Service and DevTools

That table is the strongest part of the argument because it inverts the usual framing. Flutter was designed for human feedback latency, and the authors contend the same architecture makes it effective for machine verification, where the winner is whichever stack can tell an agent whether a change worked in the shortest time.

The fourth observation concerns tooling discipline. Left alone, an agent knows Flutter only as well as its training cutoff, so it reaches for deprecated APIs and stops before verifying. Prompt engineering does not fix this reliably. Project One Shot tested the alternative by asking an agent to resolve production bugs in camera_android_camerax, a plugin built on Android CameraX lifecycles and surface texture bindings. Generic instructions to avoid memory leaks failed. The agent succeeded once paired with a deterministic harness: abstract syntax tree analysis over MCP, package specific skills, and a reproduce, fix, verify loop enforced by tests and leak linters.

Three capabilities were released to give every team that harness: official Dart and Flutter agent plugins bundling an MCP server with ten Flutter skills and fourteen Dart skills, Antigravity agents that audit a running app for accessibility problems and submit fixes, and an Agent Skills CLI built with Serverpod so package authors can ship library specific rules. Benchmarks on everyday evaluation suites show Gemini 3.5 Flash moving from 84.1 to 85.5 percent and Gemini 3.1 Pro from 89.6 to 92.7 percent with the harness in place.

Scale Arguments and Store Ratings

The fifth observation extends the argument to runtime. Generative interfaces built on the A2UI standard and the GenUI SDK need a portable declarative canvas, and the post notes an agent cannot reasonably synthesise dynamic interfaces while negotiating five native layout engines. GenLatte, an AI ordering system on Flutter, Firebase Functions, and Genkit that has served over three thousand real coffee cups, is offered as evidence that the pattern works outside a demo.

For breadth, the post lists production users across surfaces: Xiaomi for the SU7 app and core HyperOS 4 system applications, Universal Destinations and Experiences cutting codebase size by 45 percent, Toyota and Lexus infotainment in models including the RAV4, and Nubank serving over one hundred million customers.

The closing claim targets the assumption that cross-platform UI imposes a visible experience tax. Reviewing Apptopia data across 201,000 top apps, Flutter and non-Flutter apps average 4.1 stars on Google Play and 4.0 on the App Store. Users rate responsiveness and polish, not the framework underneath.

Whether the argument persuades an organisation depends on where it sits on that curve. For a team starting from scratch, native duplication with AI assistance remains viable. For a team with years of accumulated decisions in one codebase, the cost of splitting that memory is not paid at migration but every release afterwards.