Ask a room of technical founders which cross-platform mobile framework they should use and you will still get the same argument you would have got in 2019: React Native or Flutter, JavaScript or Dart, native modules or widgets. It is a comfortable debate because everyone already knows their lines.
It is also, in 2026, largely the wrong debate. Both frameworks matured past the point where raw capability decides anything. React Native’s New Architecture — the Fabric renderer and TurboModules sitting on JSI — removed the asynchronous bridge that used to be the standard objection. Flutter’s Impeller is now the default renderer on both iOS and Android, which quietly killed the shader-compilation jank that used to be its standard objection. Depending on which 2026 survey you read, either one is winning. Both will build the app you have in mind.
So if the frameworks are no longer the differentiator, what is? Three things have changed underneath the debate, and none of them are about rendering performance.
TL;DR
- The React Native vs Flutter performance argument is over. React Native’s New Architecture (Fabric + TurboModules) and Flutter’s Impeller renderer both cleared the bar. Choosing on benchmarks in 2026 is choosing on a metric that no longer separates them.
- AI coding agents flattened the language learning curve but sharpened the ecosystem penalty. Dart vs TypeScript barely matters when an agent writes the boilerplate. What matters is how much public code the agent was trained on — which is why newcomers like ByteDance’s Lynx carry a hidden cost.
- Distribution changed more than the tooling did. Apple’s single EU business model from January 2026, web distribution, and alternative marketplaces mean “how does this reach users” is now a genuine architectural input, not an afterthought.
- The real cost is the five-year maintenance bill, not the twelve-week build. Framework upgrade cadence, native module rot, and hiring depth dominate total cost of ownership.
- Pick for your team and your distribution model, not for a benchmark chart. We give a straightforward decision framework below.
1. AI agents changed which costs matter
The single biggest input to framework choice used to be “what does our team already know”. A JavaScript team picked React Native because retraining four developers in Dart was a real, expensive, months-long cost.
That cost has collapsed. A competent developer working with a coding agent can be productive in an unfamiliar language within days, because the agent handles the idiom and the developer supplies the judgement. We have watched this happen on our own projects. Language familiarity is now a soft preference rather than a hard constraint.
But something less obvious replaced it. Coding agents are only as good as the corpus they learned from, and framework ecosystems differ enormously in how much public production code exists. React Native and Flutter each have roughly a decade of open-source apps, Stack Overflow answers, and library source in the training data. Agents write both fluently and — crucially — know what the common failure modes look like.
Give the same agent a framework with a thin public ecosystem and the behaviour changes. It confidently invents APIs that do not exist, reaches for patterns borrowed from the framework it does know, and produces code that compiles and then misbehaves. This is the practical case against ByteDance’s Lynx for most teams right now. Technically it is interesting — a dual-threaded architecture separating UI rendering from application logic, a Rust-based build toolchain, and battle-testing inside TikTok before it was open-sourced. But the third-party library ecosystem is sparse, and the AI tooling that your team now depends on has barely seen it.
The lesson generalises: in an agent-assisted workflow, ecosystem maturity is worth more than architectural elegance. That is a genuinely new consideration, and it cuts against early adoption in a way it did not three years ago.
2. Distribution stopped being someone else’s problem
For fifteen years, mobile distribution was a fixed constraint: you shipped to two app stores, you paid the commission, you accepted the review process. Architecture decisions did not touch it.
The Digital Markets Act broke that assumption in the EU. Apple has shipped hundreds of APIs and developer tools to comply — alternative app marketplaces, web distribution direct from your own domain, alternative payment processing, and from 1 January 2026 a single EU business model replacing the earlier Core Technology Fee arrangement. Android is on its own regulatory trajectory.
For most consumer apps this is noise. For a specific and growing category it is not. If you sell digital goods, run a subscription business, or operate in a vertical where store commission meaningfully changes unit economics, distribution is now a variable you can optimise — and that changes what you build. Web distribution rewards architectures where the mobile app and the web app share meaningful surface area. Alternative payment flows need to be designed in, not retrofitted around an in-app purchase assumption.
It also revives a question many teams stopped asking: do you need a native app at all? Progressive web apps have quietly become viable for a wider band of products than most founders assume, and the answer for an internal tool or a B2B dashboard is increasingly no. We have talked clients out of native builds on exactly this basis. The right answer is sometimes the cheaper one.
3. The maintenance bill is the actual cost
Cross-platform frameworks are sold on build cost — one codebase, two platforms, half the team. That pitch is honest about year one and silent about years two through five, which is where the money actually goes.
Three costs dominate:
Framework upgrade cadence. React Native and Flutter both ship frequently, and both periodically require non-trivial migration work. A team that skips upgrades for eighteen months does not save time; it accumulates a migration it will eventually pay for at a worse exchange rate, usually under deadline pressure.
Native module rot. Every third-party package that bridges to platform code is a dependency on someone else’s willingness to keep supporting it. This is where cross-platform projects genuinely decay. Audit your native dependencies before you commit to them: maintenance activity, single-maintainer risk, and whether you could realistically fork it.
Hiring depth. This one is underrated and it favours React Native for most SMEs, simply because the pool of developers who can work in a React codebase is much larger than the pool who can work in a Dart one — and because a React Native team can often absorb web work too.
A decision framework that actually works
Strip out the tribalism and the choice comes down to four questions.
Does your product need to feel like part of the platform, or like itself? Flutter draws its own widgets, which gives you pixel-identical output everywhere and a slight but persistent foreignness on iOS. React Native maps to platform components. If your brand identity is the interface, Flutter’s control is an asset. If your users expect the app to behave like every other app on their phone, React Native’s fidelity is.
How much surface do you share with the web? If you already run a React web application, React Native with Expo lets you share business logic, types, validation, and often whole domain layers. That is a real and compounding advantage. If you have no web product, it disappears.
How deep do you go into platform capability? Heavy Bluetooth, background processing, complex camera pipelines, or platform-specific hardware integration mean writing native code regardless of framework. If a substantial share of your product’s value lives there, evaluate whether cross-platform is buying you anything at all. Sometimes two native apps is the cheaper answer, and refusing to say so is how agencies end up shipping something fragile.
Who maintains this in three years? Answer honestly, in terms of the team you will realistically have, not the team you have now.
Our default recommendation for most SMEs and startups is React Native with Expo — not because it wins on architecture, but because the managed build and update pipeline removes an enormous amount of operational overhead, the hiring pool is deep, and the shared-logic advantage with a web product is real. Flutter is the better answer for design-led products, for teams targeting mobile plus desktop from one codebase, and for anything where visual consistency across platforms is a product requirement rather than a preference. Lynx is worth watching and not worth betting a production roadmap on this year.
The uncomfortable part
The framework you choose matters considerably less than whether you have an answer to the maintenance question. We regularly inherit cross-platform apps built competently in either framework and abandoned to dependency drift — the build no longer runs, the native modules no longer compile against current SDKs, and reviving it costs a meaningful fraction of a rebuild.
That is not a Flutter problem or a React Native problem. It is a planning problem, and it is entirely avoidable with a modest upgrade budget and someone whose job it is to spend it.
REPTILEHAUS builds and maintains cross-platform mobile applications for entrepreneurs, SMEs, and agency partners — including the awkward projects that arrive as an inherited codebase and a build that will not run. If you are weighing a mobile build, deciding between native and cross-platform, or trying to work out whether an existing app is worth reviving, get in touch. We will give you a straight answer, including when that answer is “you do not need an app”.
📷 Photo by William Hook on Unsplash
