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 the product needs both platforms and shared behavior, and one team can own the platform-specific integrations as well as the shared UI.
- Native if particular iOS or Android capabilities, system integration, or platform-specific behavior are central to the product and you can staff the two clients.
- React Native if you already have a React team and can keep the JavaScript and native dependency surfaces healthy. Price the upgrade and integration work into the decision.
Everything below is why.
Native (Swift / Kotlin)
Two platform clients mean separate implementation and release work, but not every project activity doubles. Product decisions, much of the design and a shared backend can be common. Ask suppliers to show which tasks are shared and which are built and tested separately. Native app development is useful when direct access to platform capabilities is part of the requirement.
What you buy: direct access to the platform SDKs your target devices and OS versions support. Widgets, App Clips, Live Activities, CarPlay, Wear and camera or ML integrations each have their own requirements. You still need to verify availability, entitlements, device behavior and release constraints; choosing native does not remove that work.
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
Flutter uses its own rendering approach rather than wrapping every native UI control. That can make a consistent custom interface easier to share, while platform conventions and accessibility still need deliberate design and testing on each operating system. The Flutter app development service covers implementation, device testing and handover.
What you buy: shared application logic and much of the UI across platforms. A shared fix can benefit both clients, but native integrations, accessibility and operating-system behavior still need platform-specific testing. This can fit design-led products with a deliberately shared interface.
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
A React team may be productive quickly in React Native, but existing web code is not automatically reusable as mobile UI. Check the native modules, package maintenance, upgrade path and the engineers who will own them after launch.
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
A useful estimate compares the same flows and acceptance criteria in each stack. Ask every supplier to separate shared product and backend work from platform clients, integrations, testing, release preparation and ongoing maintenance. The comparison should show the work; a framework multiplier hides it.
- Freeze one brief. List the same user flows, supported OS versions, devices and integrations for every estimate. Keep optional features separate.
- Separate shared work from client work. Ask for design, backend and product tasks alongside iOS and Android implementation, platform integration and device testing.
- Price release ownership. Include signing, store submission, crash monitoring, OS compatibility updates and the person responsible when an update breaks a plugin or native module.
- Compare a two-platform outcome with a one-platform launch. If budget forces a staged launch, state which users and features wait for platform two and what evidence will trigger the next investment.
Maintenance is where the cost shape becomes clearer. Count the engineers who can ship each client, the release checks you repeat, and how often dependencies or operating-system changes require platform-specific work. Put those assumptions beside the build estimate instead of treating maintenance as a percentage of the initial quote.
The hiring reality nobody prices in
Engineer availability depends on seniority, location, compensation and the product's technical requirements. Before choosing a stack, check the actual candidate pool you can reach and the experience needed for its native integrations. A framework that fits the product but cannot be staffed is a delivery risk.
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
A rewrite consumes time that could have gone to new product work, so compare it with a repair or incremental migration before committing. It is easier to justify 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? Name the exact API, SDK, device and required behavior. Verify current support and its maintenance owner in the chosen stack; native access can reduce wrapper risk, but it does not make every integration effortless.
- 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? Compare the same release scope at your real budget. If both platforms do not fit, decide which one launches first, what the second launch depends on, and how you will keep the first release maintainable.
What doesn't matter as much as you think
- Performance by reputation. If launch time, frame pacing, memory, background work or device communication matters to your product, profile the critical flows on target devices before choosing. General claims about a framework do not replace that test.
- "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.
- Predictions about which framework will win. Review the release cadence, supported dependencies and upgrade path you would actually adopt. Your team needs a maintainable choice, not a forecast.
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.