If you've spent any time on r/FlutterDev or the React Native Discord, you already know this argument never really ends. Every few months someone posts a "benchmark" and the comments turn into a small war. Meanwhile teams still have to ship apps, and the "it depends" answer, while true, doesn't help you pick a stack on a Tuesday afternoon with a deadline in six weeks.
So let's skip the tribalism and go through this the way you'd actually decide it: performance, developer experience, cost, and the specific situations where each option wins.
The three options, quickly
Native (Swift/Kotlin) — you write iOS and Android as two separate codebases, each using the platform's own language and tooling.
Flutter — one Dart codebase, compiled to native ARM code, rendered with Flutter's own engine (Skia/Impeller) instead of native UI components.
React Native — one JavaScript/TypeScript codebase, using native UI components under the hood, bridged (or in the New Architecture, directly connected via JSI) to native code.
At the level of a single button or form field, all three look and feel similar to write — SwiftUI, Flutter's widget tree, and React Native's JSX all get you to the same result in a handful of lines. The real differences don't show up in one component; they show up once the app grows past a few screens, which is what the rest of this comes down to.
Performance
Native wins here, but the margin depends heavily on what the app actually does.
For CRUD screens, forms, lists, and typical business-app UI, the difference between native and Flutter is close to imperceptible to a user. Flutter compiles to native ARM code and draws its own widgets frame by frame — it doesn't go through a JS bridge, so it holds 60/120fps well even on mid-range devices.
React Native's older bridge architecture used to be the honest weak point — janky animations, dropped frames on list scrolling. The New Architecture (Fabric + JSI, now the default as of recent RN versions) closes most of that gap by removing the async bridge entirely. It's a real improvement, but it's newer, and older RN codebases that haven't migrated still carry the old baggage.
Where native still clearly separates itself: heavy camera processing, ARKit/ARCore work, custom Metal/OpenGL rendering, background audio processing, anything CPU/GPU-bound. If that's your app, this section is the whole decision.
Developer experience and iteration speed
This is where Flutter and React Native both beat native, and it's not close.
Hot reload (both Flutter and RN) means you change a line of UI code and see it update in under a second, state preserved. Native development means a full rebuild — Xcode and Android Studio have gotten faster, but you're still looking at tens of seconds per iteration, twice, because you're maintaining two apps in parallel.
That "two apps in parallel" part is the real cost of native that doesn't show up on a features list: two codebases, two sets of bugs, two release cycles, and a team that either knows both Swift and Kotlin or is actually two separate teams.
Ecosystem and packages
Native: full, immediate access to every new OS API the day it ships. No waiting on a third-party wrapper.
React Native: the largest cross-platform package ecosystem, being JavaScript-based — huge npm overlap, easiest hiring pool.
Flutter: smaller package count than npm, but pub.dev packages tend to be more consistently maintained and null-safe, and Google ships first-party packages for most common needs.
If your app depends on a brand-new OS feature (say, a new iOS 26 API) on day one, native is your only real option — cross-platform frameworks lag behind by weeks to months while bindings catch up.
Team and hiring reality
This ends up mattering more than most comparison articles admit.
JavaScript/TypeScript developers are the easiest to find and the cheapest to onboard — which is the biggest practical argument for React Native.
Dart developers are rarer, but Dart is close enough to Java/TypeScript that any competent developer picks it up in days, not months.
Native means hiring (or training) for Swift and Kotlin specifically, or running two separate hiring pipelines.
Cost and timeline
Roughly, for a comparable mid-complexity app:
Native: highest cost, longest timeline — you're building two apps.
Flutter: single codebase, close to native performance, generally the fastest time-to-market for apps with custom UI.
React Native: **single codebase, fastest for teams that are already JavaScript-heavy (existing web team, existing React codebase to share logic with).
**A simple way to decide
Pick native if: your app is performance-critical (games, AR, heavy media processing), needs a brand-new OS feature on day one, or you're building something platform-specific enough that shared code barely applies anyway.
Pick Flutter if: you want pixel-identical UI across iOS and Android, you're building something UI-heavy (custom animations, branded design systems), and you don't already have a JavaScript team.
Pick React Native if: you already have a React web app and want to share logic, your team is JavaScript-first, or you need to hire fast and want the largest possible talent pool.
None of these are wrong choices in the abstract — they're wrong for a specific project when the constraints (team, timeline, feature set) don't match. This is also the exact conversation worth having before any code gets written, and it's a big part of why teams bring in outside help just for that decision — a good mobile app development services provider will actually walk through your specific constraints instead of defaulting to whatever stack they know best.
Wrapping up
There's no universal winner here, and anyone telling you otherwise is usually selling something (including, occasionally, a framework they personally like). Match the choice to what the app actually needs to do, who's going to build it, and how fast it needs to ship — in that order.
I write about mobile development and software strategy at Entalogics. Happy to go deeper on any of this in the comments.
Top comments (0)