"React Native or Flutter?" is the wrong question, and the confident universal answer is a reliable sign that whoever gave it has shipped mostly one kind of app. Both are excellent. Native is still correct for a real set of cases. The useful question is narrower: for this app, with this team, on this timeline, which trade-offs are acceptable?
Where each option genuinely wins
React Native
Strongest when your organisation already lives in the JavaScript ecosystem. A team writing React for the web can be productive in React Native in days rather than months, share validation logic and types with the backend, and hire from a very large talent pool.
The modern architecture closed most of the historic performance gap. Where React Native still asks for care is heavy continuous animation and anything unusually graphics-intensive — solvable, but it is where you will spend your optimisation budget.
Best fit: content-driven apps, marketplaces, booking and ordering, business tools, anything where the app is primarily a well-designed interface over an API.
Flutter
Strongest when visual consistency and animation are central to the product. Flutter renders its own widgets rather than mapping to platform components, so an interface looks identical on both platforms, and complex custom animation is comfortable rather than heroic.
The cost is Dart — a pleasant language with a smaller hiring pool than JavaScript — and interfaces that need deliberate work to feel native to each platform rather than uniformly Flutter.
Best fit: design-forward consumer products, apps with heavy custom UI or animation, teams starting fresh without an existing JavaScript investment.
Native (Swift / Kotlin)
Strongest when the app's core value depends on deep platform capability, or when it will be maintained for many years by a team that can specialise.
Native gets new OS features on release day rather than after a bridging library catches up, has no abstraction layer to debug through, and has the largest ecosystem for platform-specific problems. It costs roughly two codebases' worth of effort, forever.
Best fit: apps built around camera, sensors, background location, Bluetooth or health data; games and AR; and long-lived products where lifetime maintenance cost dominates initial build cost.
The five questions that actually decide it
1. How deep into the hardware does the app go?
Standard capabilities — camera capture, GPS, push notifications, biometrics, files — are well covered by both cross-platform frameworks. Continuous background location, advanced camera control, Bluetooth Low Energy peripherals, or platform health frameworks push toward native, or at minimum toward accepting that you will write native modules and therefore need native expertise anyway.
2. What does your team already know?
The framework your team can maintain beats the framework that benchmarks slightly better. A React team choosing Flutter on paper is a team that will be slow for three months and dependent on one person who learned Dart fastest. Be honest about who maintains this in year two.
3. Must both platforms look identical, or must each feel native?
These are opposing goals. A branded, identical experience across platforms favours Flutter. An app that should feel like it belongs on iOS and separately like it belongs on Android favours native, or React Native with genuine platform-specific work.
4. How long will this app live?
For a two-year product, cross-platform's speed advantage is decisive. For a ten-year platform, native's lower long-term friction — no framework migrations, no waiting on library maintainers, no abstraction debugging — starts to win on total cost.
5. How much App Store risk can you carry?
Both stores accept cross-platform apps without prejudice; that has not been a real concern for years. What is real is that unusual permission usage, subscription implementations, and account-deletion requirements get reviewed strictly regardless of framework. Budget for at least one rejection and a resubmission cycle in your launch timeline.
The cross-platform costs nobody puts in the proposal
Cross-platform saves substantial money. It does not save all the money the pitch implies, and the gap shows up in four predictable places:
- Native modules. Most non-trivial apps eventually need one. That means a developer who can write Swift or Kotlin — the skill you were trying to avoid needing.
- Framework upgrades. Major version upgrades are real projects, not afternoons, and skipping them compounds until you are stranded on an unsupported version.
- Platform divergence. "Write once" becomes "write once, then handle the seven places iOS and Android genuinely differ" — permissions, back navigation, notification behaviour, keyboard handling.
- Dependency risk. Cross-platform apps lean on community packages. Some are abandoned. Check maintenance activity before you build a core feature on one.
Realistically, cross-platform delivers something closer to a 60–70% saving against two native builds, not the 90% that gets quoted. That is still an excellent trade for most projects — it is simply worth budgeting honestly.
The part that matters more than the framework
Most mobile apps that fail in production do not fail because of the UI framework. They fail because the backend was an afterthought: no offline handling, no pagination, chatty endpoints that drain battery, no push infrastructure, no plan for forcing an upgrade when an old client version breaks.
Four things worth designing before you choose a framework at all:
- Offline behaviour. Phones lose connectivity constantly. Decide what works offline and how conflicts resolve when connection returns.
- API shape. Mobile clients need coarse-grained, paginated endpoints — one call per screen, not twelve.
- Versioning. Old app versions live in the wild for months. Your API must support them, and you need a mechanism to force an update when it cannot.
- Push notifications. Delivery, deep links, permission timing, and what happens when the user declines.
Choose the framework in an afternoon. Spend the week on the API contract and the offline story — that is what determines whether the app feels good six months in.
The short version
Pick React Native if you have JavaScript people and the app is an interface over an API. Pick Flutter if the design is the product and you are starting fresh. Pick native if you are deep in platform capabilities or building something meant to last a decade.
If you want that decision made against your specific requirements rather than in the abstract, it is the first conversation in every engagement of our Mobile App Development service — including the backend and store-submission planning that usually matters more than the framework itself.