I've shipped production apps in Swift, in Kotlin, in Flutter, and inherited plenty in React Native. So this isn't a benchmark post. It's the answer I give founders who need to decide this week and not revisit it for two years.
The short version
- Flutter if you need two platforms, one team, and heavy custom UI. Best cost-to-quality ratio for most products in 2026.
- Native if the app is the business, or you depend on platform features the day they ship.
- React Native if you already have a strong React team and a web app to share logic with. Otherwise the case is weaker than it was.
Everything below is why.
Native (Swift / Kotlin)
Two codebases, two skill sets, two release cycles. Roughly 1.6–1.9× the build cost of a cross-platform equivalent — not the 2× people assume, because the shared work (design, backend, product thinking) doesn't double.
What you buy: every platform capability on day one. Widgets, App Clips, Live Activities, CarPlay, Wear, deep OS integrations, the newest camera and ML APIs. No abstraction layer between you and the platform, which means no waiting for someone to wrap the thing you need.
Choose it when: the app is the product and its quality is the differentiator; you're in a category where platform features drive retention; you need the absolute best performance and memory behaviour; or you're large enough that two specialist teams are normal.
Flutter
One codebase, one team, its own rendering engine. That last part is the thing people misunderstand: Flutter doesn't wrap native components, it draws its own. That's exactly why heavy custom UI is cheap in Flutter and exactly why it can feel subtly un-native if you fight the platform's conventions.
What you buy: genuinely the same app on both platforms, one team to hire, one bug to fix. Excellent for design-led products where the interface is bespoke anyway.
What it costs: you're one layer removed from new OS features, and larger binaries. Anything deeply platform-specific means writing a platform channel — which is fine, and is also native code you now maintain.
Choose it when: two platforms matter, the budget is real but finite, the UI is custom, and you'd rather have one strong team than two thin ones.
React Native
The case has narrowed. The new architecture fixed the old bridge performance problems, and if you have React engineers, they are productive on day one — that's a genuine, large advantage.
What it costs: the dependency surface. A React Native app is you plus a long tail of community packages, and their maintenance is not your decision. Upgrades are the most common source of unplanned work I see in inherited RN codebases.
Choose it when: you have a React team and a web product to share logic with. If you'd be hiring for it fresh, Flutter is usually the better bet in 2026.
The cost comparison, concretely
For a mid-sized consumer app — auth, a core loop, payments, push, offline handling, both platforms — the shape looks roughly like this:
- Flutter: one team, one codebase. Baseline. Say €X.
- React Native: ~1.0–1.15× baseline if you already have React people; ~1.2× if you're hiring fresh, because the ecosystem knowledge takes longer to acquire than the syntax.
- Native both platforms: ~1.6–1.9× baseline. Not 2×, because design, backend and product thinking don't double — only the client work does.
- Native one platform first: ~0.75× baseline, and then you have the second-platform conversation in six months with less money than you have now. Popular, and usually regretted.
Maintenance is where the divergence compounds. Two native codebases mean every change is specified once and built twice, forever. Over three years that gap is typically larger than the initial build difference.
The hiring reality nobody prices in
In Barcelona, Madrid, Lisbon and most of Central Europe, hiring a strong Flutter engineer in 2026 takes weeks. Hiring a strong senior iOS engineer takes months, and costs 20–30% more when you find one. In London, Amsterdam or Stockholm both are harder and dearer.
This is a real input to the decision and it almost never appears in the technical comparison. The best architecture you cannot staff is worse than the good architecture you can.
If you're already on one and wondering about switching
Short answer: usually don't, and here's the test. Rewriting costs 60–80% of a fresh build and delivers zero new user value on the day it ships. It's only justified when:
- You physically cannot hire for the current stack at any reasonable price.
- A platform requirement will force the work anyway within twelve months.
- The existing codebase fails the basics — see the audit checklist — in which case you're not rewriting because of the framework.
- You're maintaining two native codebases with a team too small for one.
"Our engineers would prefer X" is not on that list, and it is the reason most rewrites actually start.
The questions that actually decide it
Not "which is fastest". These:
- Who maintains this in two years? Pick the stack you can hire for in your city or your budget. A perfect technical choice with no available engineers is a bad choice.
- How custom is the interface? Heavily custom favours Flutter. Platform-conventional favours native.
- Do you need a platform feature on launch day? If yes, native. Everything else waits for a wrapper.
- Is there an existing web app? If it's React and the logic is genuinely shareable, React Native's case gets much stronger.
- What's the real budget? Native for both platforms on a €40k budget means one platform, badly. Be honest earlier rather than later.
What doesn't matter as much as you think
- Raw performance. For the overwhelming majority of apps, all three are far past the threshold where users notice. Your network layer and your image handling matter more than your framework.
- "It doesn't feel native." Usually true of bad apps in every framework. It's a design and attention problem more often than a technology one.
- Framework longevity arguments. All three will outlive your current roadmap. Bet on your team, not on a foundation's press releases.
If you're inheriting an existing app rather than starting one, the framework question is secondary — start with what an audit should actually look at.