Flutter's Counter to Two Native Agents: Code Generation Is Cheap, Keeping Platforms Identical Is Not
Flutter's official stance: In the AI era, code is getting easier to write, so why still maintain one codebase?
Recently, whether it's Shopify or the public discussion over the past two months, it seems everyone is saying: since AI can already produce native Swift and Kotlin code at low cost, why would companies still use Flutter? Just let two Agents maintain iOS and Android separately, wouldn't that be enough?
Flutter's official answer to this is: ongoing maintenance cost.
The cost reduction people attribute to AI is actually the cost of writing code for the first time. But the ongoing maintenance cost after an app has been live for several years — such as keeping different platforms behaving the same, and fixing one bug correctly across multiple code repositories — is still real cost.
Simply put, the official perspective is:
- A single codebase accumulates not just code, but a large history of product decisions and bug fixes. When AI maintains two native implementations at the same time, it may interpret one requirement in two different ways and land them in different repositories.
- Writing code is indeed not slow, but in the AI era, the cost of acceptance/verification is the real problem and bottleneck. For example, Flutter wiring hot reload, Widget tests, the Analyzer, and the runtime Widget Inspector into the Agent toolchain is an attempt to shorten the "modify → run → check" loop.
- Flutter is already treating Agent workflows as engineering infrastructure. This includes MCP, Skills, rules provided by package authors, and test gates in real plugins. In other words, Flutter has transformed into an AI-facing development framework. We've talked about these things before.
These points are actually quite easy to understand. Take the first one: AI can certainly write two native codebases, but behavioral divergence still accumulates along the way. Here's a checkout state machine example:
- The iOS Agent uses an async stream to handle network responses, discarding old requests when they become stale.
- The Android Agent implements it with Flow, but instead queues old events and keeps processing them.
Both sides of this code are actually reasonable, and local unit tests might pass. But when a user triggers a retry under an unstable network, one side may ignore stale results while the other side writes stale results back into the state.
In other words, AI can lower the production cost of Swift and Kotlin, but it cannot, at zero cost, eliminate differences in requirement understanding, retry timing, and boundary behavior between two implementations. For example, every time a requirement changes in the future, both sides still need separate implementation and cross-validation.
This is where Flutter still matters, especially for small and medium teams. With Flutter, a single set of Dart business logic and state machine means at least that part of the behavior only needs to be defined once, and UI integrity only needs to be accepted/verified once, then shared across iOS, Android, and even HarmonyOS and other platforms.
Of course, the most important thing is that Flutter is starting to build a verification loop for Agents. For example, Flutter Stateful Hot Reload can go below 200 milliseconds, and Widget tests below 500 milliseconds. Compared with traditional native builds that need 2–5 minutes, an Agent can actually get deterministic feedback after every code change, and try and fix more problems in the same amount of time.
Native plugin parts, however, cannot be this fast. But that part is actually the most valuable place in the AI era. In the past, the scariest thing about writing Flutter was native plugins: no one adapted them, you didn't understand them yourself, and working on them was painful.
But now, in the AI era, if a plugin has a problem you can fix it directly. This has become an advantage.
Currently the official team maintains Flutter Agent Plugins and Dart Skills, with 10 Flutter Skills and 14 Dart Skills respectively. Combined with dart mcp-server, static analysis, test execution, and runtime checks can be connected into development tools like Codex, Claude Code, and Cursor.
Even now, package authors can publish the corresponding Skill together with their
pub.devdependency, and developers can rundart run skills@ getto discover the rules provided by current dependencies.
Other things like A2UI and GenUI SDK for Flutter, or the GenKit Agent SDK, are all part of Flutter's adaptation and infrastructure capabilities around AI.
So Flutter is not just a cross-platform framework. In the AI era, it is also evolving further around AI, and this is Flutter's significance in the AI era.
Links
https://flutter.dev/blog/ai-makes-it-easy-to-migrate-flutter-makes-it-easy-to-scale
Top 4 from juejin.cn, machine-translated. The original thread is authoritative.
These days, a pure native Xcode 27.1 build is roughly all it takes to adapt to iPhone Duo, while Flutter's latest tab bar still cuts through the side status bar and the navigation bar's back button remains at the top.
In the human era, save manpower; in the AI era, save tokens.
It feels like, in the future, we'll be like assembly-line workers in an electronics factory.
Facing AI.