Flutter vs React Native: Which Cross-Platform Framework Should You Use?

If you want one codebase on iOS and Android, you are still choosing between two grown-up options: Google’s Flutter and Meta’s React Native. The old “Flutter is immature / React Native is always slower” talking points do not match the current stacks.

This is a decision guide, not a scoreboard. Pick the framework that matches the team you have, the UI you need, and the platforms you actually ship — then verify performance on a release build, not a conference slide.

What actually changed

Flutter’s renderer is no longer “the Skia era with jank on the first animation.” Impeller is the default on iOS and on Android API 29+, and it is the only supported engine on iOS. Shaders compile at engine build time so the first heavy frame is less likely to hitch. Flutter also ships first-party targets for web, Windows, macOS, and Linux — useful if the same product really does need a desktop shell.

React Native retired the old asynchronous bridge as the core path. The New Architecture (JavaScript Interface, Fabric renderer, TurboModules) is the default on current React Native releases, and recent Expo SDKs run on it by default. Hermes is the JavaScript engine you should assume. Expo is no longer a toy wrapper; for most new RN apps it is the sane starting point.

How the two frameworks work now

Flutter draws its own pixels with Dart and widgets. You get the same UI on iOS and Android unless you opt into Cupertino or Material differences. That is why Flutter apps can look “the same everywhere,” and why a designer’s custom motion is easier to keep consistent. You talk to native code through platform channels or FFI when you need a camera, a store kit, or an OEM SDK.

React Native still maps to native views. JavaScript (usually TypeScript) describes the UI; Fabric mounts real UIKit / Android views. That is why RN apps can feel closer to a native kit, and why a React web team can be productive in a week. You still write native modules for anything the JS layer cannot do — Expo’s module set just covers more of that than it used to.

Side-by-side: language, UI, and platforms

• Language: Dart (Flutter) vs JavaScript/TypeScript (React Native). Hiring and shared web code usually favor TypeScript.
• UI model: Flutter owns the pixels (widgets + Impeller). RN uses native views (Fabric). Custom, animated, brand-heavy UI is easier in Flutter; platform-look UI is easier in RN.
• Reload: both have fast hot reload / Fast Refresh. Neither replaces a real device pass before store submit.
• Platforms: Flutter’s mobile + desktop + web story is first-party. RN is strongest on iOS/Android; web is a separate, more uneven path (React Native Web, Expo web).
• Ecosystem: npm + React is enormous. pub.dev is smaller but coherent. Count the specific SDKs you need (payments, maps, IAP, analytics) before you fall in love with a logo.
• Updates: Expo can push JavaScript updates without a store review (native binary changes still need a build). Flutter ships a new binary for most changes.

If you are shipping on Android outside the Play Store as well, the sideload and store story is the same problem for both frameworks — start from a current Play Store alternatives plan, not from a 2018 PhoneGap checklist.

When Flutter is the better pick

• The UI is the product: custom charts, editors, brand motion, or a design system that should not drift between iOS and Android.
• You want one team to ship mobile and a Windows/macOS companion without standing up a second UI kit.
• The team is fine learning Dart, or already writes in a typed, class-heavy style.
• You care about predictable animation more than matching every iOS nav-bar quirk.

Flutter is a poor default when the app is a thin skin over a dozen OEM SDKs and the only developers you can hire are React web folks who will never touch Dart.

When React Native (and Expo) is the better pick

• You already have a React or React Native codebase, or a web team that must share people this quarter.
• You want Expo’s project tooling and over-the-air JS updates for a product that iterates weekly.
• The UI should look and behave like UIKit / Material, not like a custom game shell.
• Most of the work is forms, lists, auth, and API screens — the boring apps that pay the bills.

React Native is a poor default when you need pixel-identical custom UI on six platforms and you do not want to fight yoga layout plus a pile of native modules. Also drop the old “Airbnb still uses it” line — they left years ago. Current RN users that matter are the ones you can still find in production: Meta’s own apps, plus a long list of Expo shops.

What to ignore from older comparisons

• “Flutter is too new.” It shipped in 2017 and has been production-default at large companies for years.
• “React Native cannot do 60 fps.” The old bridge could stall a frame. The New Architecture exists specifically so that excuse ages out. Profile before you repeat it.
• “Write once, run everywhere” as a promise. Both still need platform-specific work. Budget 10–30% of the app for it, not zero.
• PhoneGap, Corona, Sencha, and Node.js on a “frameworks” list. Those are either dead, unrelated, or a different category.
• Vendor scorecards that declare a winner. Agencies pick the stack they staff. Read the constraints, not the CTA.

A practical way to choose

1. List the platforms you will ship in the next 18 months, not the ones that sound nice in a pitch deck.
2. List the three nastiest native features (background location, IAP, BLE, DRM, a vendor camera SDK).
3. Check those packages on pub.dev and in the Expo / RN ecosystem the same afternoon.
4. Spike the hardest screen in both stacks if the team is not already committed — two or three days, release mode, on a mid-range Android phone.
5. Pick the stack the people you can actually hire will not abandon in six months.

If you are still tied, default to the language the team already writes. A good React Native app beats a Flutter app written by people who resent Dart, and the reverse is just as true.

Once the app is in users’ hands, treat store listing, permissions, and device security as product work — the same Android security settings your users should already have on.

FAQs