Flutter vs React Native: which to choose, from someone who ships both

Zayin Krige, 2025-04-19. 4 min read.

Choose Flutter when the app talks to hardware, needs pixel-identical rendering on both platforms, or when the team is starting from scratch. Choose React Native when the company already has React web developers and wants to share code and people with the web product. Both frameworks are mature enough to ship a serious app; the wrong choice costs you in hiring and maintenance, not in whether the app works.

I have shipped production apps in both. In Flutter: a wearable SDK with Bluetooth Low Energy device integration for a health-data company, a gig-work marketplace with iOS and Android apps, and an eReader. In React Native: a retail stock-management and mobile-ordering app, and an eReader for a digital-publishing platform serving international publishers. The comparison below is what those projects taught me.

Rendering

Flutter draws every pixel itself through its own rendering engine, so a screen looks the same on iOS and Android, and on every OS version. React Native renders to native platform views, so a button is a real UIButton on iOS and a real Android button on Android. Flutter's approach makes custom design systems cheap: the wearables SDK shipped a widgets library with sleep graphs and screening flows that rendered identically on every device we tested. React Native's approach makes an app feel native by default, at the cost of platform differences appearing in edge cases you did not test.

Native and hardware integration

This is where the decision is usually made. The wearables SDK needed BLE (Bluetooth Low Energy) device pairing, background data collection and an acute-event listener running while the app was closed. Flutter's platform channels and its ability to compile to native ARM code made that tractable. React Native's New Architecture, which became the default in version 0.76, closed much of the old bridge-latency gap, and for ordinary native modules the two are now comparable. For hardware that streams data continuously, I still reach for Flutter.

Language and tooling

Flutter is written in Dart, a typed language with sound null safety that most developers learn in a week. React Native is JavaScript or TypeScript with the whole npm ecosystem behind it. That ecosystem is both the advantage and the maintenance burden: a React Native app of any age accumulates dependencies that break on upgrade. Upgrading React Native itself between major versions has historically been the most expensive recurring task on the projects I have maintained. Flutter upgrades are usually a version bump.

Hiring

React Native has the larger hiring pool because every React web developer is a plausible React Native developer. If your web app is React, that shared pool is the strongest argument for React Native.

Code sharing with the web

React Native shares business logic, and with the right setup some components, with a React web app. Flutter compiles to the web as well, and for an internal dashboard it is fine, but a Flutter web app is a canvas-rendered application rather than an HTML document, which hurts text selection, accessibility tooling and search indexing. For a public marketing site or anything that must rank in Google, do not use Flutter for the web.

Performance

Both are fast enough for almost every app. Flutter compiles ahead of time to native code and does not carry a JavaScript runtime, so cold start and animation-heavy screens tend to be smoother without tuning. React Native with the New Architecture and the Hermes engine is close, and a well-built React Native app is indistinguishable to a user. Performance is a tie-breaker, not a reason.

Decision table

What I would not do

I would not rewrite a working React Native app in Flutter, or the reverse, to gain performance. I have maintained an eReader in each and the rewrite cost always exceeds the gain. Rewrite when the upgrade path is dead or the team cannot be hired, not because a benchmark says so. If the backend behind the app is the real constraint, the guide to designing an event-driven serverless platform on AWS is where I would start instead.