Flutter vs React Native: how we'd choose for your app

Choose React Native if your own team writes React and will maintain the app, or if you already have a React Native app. Choose Flutter for a new app a studio builds and maintains, especially one on Firebase and AdMob: Google lists official Flutter SDKs for both and calls the React Native libraries unofficial. Developers use the two about equally. In Stack Overflow's 2024 survey, 9.4% had worked in Flutter and 8.4% in React Native. We're a Flutter studio, so weigh our view accordingly. Below are the numbers, update costs and rules behind our Flutter vs React Native advice.

What's the difference between Flutter and React Native?

Both build Android and iOS apps from one codebase. They differ in the language you write and in what draws the screen.

Flutter is an open-source UI framework developed by engineers at Google. You write Dart, which is compiled ahead of time "into native machine code", and Flutter "renders widgets directly using its own engine" instead of using the phone's own controls (Flutter FAQ, updated 29 September 2026).

React Native is a framework for building mobile apps with React, in JavaScript or TypeScript. "At runtime, React Native creates the corresponding Android and iOS views" for your components (React Native docs). Since 24 February 2026 it has been owned by the React Foundation, hosted by the Linux Foundation, and no longer by Meta (React blog). For a new app, the React Native docs "recommend using a Framework" and name Expo (Get started).

Which is more popular, Flutter or React Native?

Among developers, they're close. Stack Overflow's 2024 Developer Survey asked which frameworks people had "done extensive development work in over the past year". Of the 45,841 who answered, 9.4% named Flutter and 8.4% React Native. Among professional developers it was 9.4% and 9.0%. Of the people using each, 60.6% of Flutter users and 56.5% of React Native users wanted to keep using it, and 12.4% and 11.7% of everyone who answered wanted to work with them the next year (Stack Overflow 2024). The 2025 and 2026 results don't report React Native at all, so 2024 is the latest Stack Overflow figure that compares the two.

The languages behind them tell a different story. The 2026 survey had 30,903 responses. Of the 14,099 who answered the language question, 62.0% used JavaScript and 43.8% TypeScript. Dart, the language Flutter uses, was at 4.9% (Stack Overflow 2026, checked 1 November 2026).

So for hiring, the pool of developers who already build apps in each framework is about the same size. The pool who could read and fix your code is much bigger for React Native, because a React web developer can follow most of it from day one. On a Flutter app they'd learn Dart and a new UI toolkit first.

Keep the limits in mind. It's a self-selected survey of Stack Overflow's audience. It counts developers, and says nothing about how many apps in the stores use each framework.

React Native vs Flutter: which is faster?

For screens, forms, lists and payments, neither is slow enough to choose on. Both do the heavy compiling before the app reaches the phone. Flutter turns Dart into native machine code (Flutter FAQ). React Native's Hermes engine compiles JavaScript "to Hermes Bytecode during build time", which its docs say improves startup speed (Hermes docs). React Native 0.82 was "the first React Native that runs entirely on the New Architecture" (0.82 release), and 0.84 made Hermes V1 the default engine (0.84 release).

We haven't benchmarked the two, so we won't give you speed numbers. If someone shows you a benchmark table, ask for the test app and the code, so you can rerun it on your own phones. Where speed really matters (live camera, audio, video editing), the work ends up in native code under either framework. That's rule 1 in our decision rules below.

Will the app look and feel native?

With React Native, standard controls are the phone's own. With Flutter, every pixel comes from Flutter, including its iOS-style widgets, which Flutter's FAQ describes as Flutter's own "implementations of Material Design and Cupertino (iOS-style) widgets".

That cuts both ways:

• A design in your own brand (your buttons, cards and colours) comes out the same on both platforms in Flutter, because one engine draws it. In React Native the same design is built from each platform's views, so it needs checking on both phones.
• When Apple or Google change how standard controls look, React Native apps that use those controls follow the operating system. Flutter apps change when Flutter updates its widgets, which its FAQ says the team does as Apple and Google publish new guidelines.

If your design is mostly your own brand, Flutter's model is simpler. If you want the stock iPhone and Android look with little work, React Native gives you that by default.

Do the SDKs your app needs support both?

Check this early. A missing official SDK can cost you more than any other difference between the frameworks. Between them, the Flutter apps we've shipped use Firebase (sign-in, Remote Config, Analytics, Crashlytics), AdMob ads and RevenueCat subscriptions. Here's how each vendor supports the two frameworks (checked 1 November 2026):

Third-party doesn't mean bad, and Firebase's own page recommends React Native Firebase. The difference shows up on a bad day. When ads stop filling or crash reports go missing, Google's support covers the Flutter SDK and leaves the React Native library to you and its maintainers. Expo's docs add one catch for the alternative, Firebase's official JavaScript SDK: it "does not support all services for mobile apps", and Analytics and Crashlytics are among the missing ones (Expo).

Run the same check on your own list: payments, maps, chat, analytics. When every vendor on it has official SDKs for both, this question stops deciding anything. Anything with no SDK at all means native code in either framework: platform channels in Flutter, Turbo Native Modules in React Native.

Can you fix the app without a store release?

Yes, for the parts that aren't native code, in both. Expo's EAS Update sends "non-native pieces (such as JS, styling, and images)" to apps already installed, and native code and permissions still need a new build (EAS Update). Flutter "doesn't provide built-in code push functionality" and points to Shorebird, a third-party service (Flutter FAQ). Shorebird patches "can change any Dart code", and native code, assets and the Flutter version still need a store release (Shorebird).

Prices checked 1 November 2026 on Expo's pricing page and Shorebird's pricing page:

The two count different things. Expo counts each user who downloads at least one update in the month. Shorebird counts each patch applied on a phone, and a user who skips straight to your latest patch counts once.

Example (hypothetical): an app with 10,000 users and one fix a month that every user installs. On Expo's Starter plan that's $19 plus 7,000 extra users at $0.005 each, so $54 a month. On Shorebird it's 10,000 patch installs, inside the Pro plan, so $20. Ship four fixes a month and Shorebird counts at most 40,000 installs, still $20, while Expo stays at $54. Price both at your own numbers.

Neither one lifts the store rules. Expo's docs say updates must follow the App Store and Play Store guidelines, and Shorebird leaves policy compliance to the developer. We'd use either to get an urgent fix out faster, and still send new features through review.

How much upgrade work does each one need?

Both move fast, and React Native moves faster. Flutter's stable releases were 3.38 in November 2025, then 3.41, 3.44 and 3.47 in February, May and August 2026 (what's new). React Native shipped five versions between February and October 2026, from 0.84 to 0.88 (React Native blog). Its release team supports the latest version "while maintaining the previous two minors" (support policy). At that pace, each React Native version gets fixes for about six months.

Older React Native apps carry one more job. Since 0.82 the New Architecture is the only one, and the React Native team tells apps still on the old one to migrate first on "React Native 0.81 or Expo SDK 54" (0.82 release). If you're taking over a React Native app, ask which version it's on before you plan new features.

Flutter upgrades cost something too. In our Flutter apps, Android SDK levels and plugin versions moved together: a newer permissions plugin needed the app compiled against API level 37, and version 7 of Google's sign-in package changed how sign-in is set up. Each meant code changes, a tested release build and another store review. The updates Apple and Google force each year are in what it costs to keep an app running after launch. Whichever you choose, budget at least two upgrade releases a year.

Is Flutter dead, or is React Native?

Neither, on the evidence. Flutter shipped four stable releases between November 2025 and August 2026, and its web FAQ was updated on 24 October 2026. React Native shipped five versions in 2026 and moved from Meta to the React Foundation in February. The foundation has eight founding Platinum members: Amazon, Callstack, Expo, Huawei, Meta, Microsoft, Software Mansion and Vercel (React blog).

What differs is who backs each one. Flutter is still Google's project. React Native now sits in a foundation that several companies fund. If that matters to your board, it's a point for React Native. We wouldn't let it outweigh the question of who will maintain your code.

Our decision rules

We go down this list and stop at the first rule that fits.

1. The core of the app is camera, audio, video, a widget or a watch. The native part decides, and the framework matters less. We cover those cases in Flutter or native? When we would tell you to go native.
2. You already have a React Native app that works. Keep it and upgrade it into the supported window. A Flutter rewrite buys little that an upgrade doesn't.
3. Your own React or TypeScript developers will maintain the app. React Native with Expo. They can read the code from the first week, and you hire from the larger pool.
4. The app earns from AdMob, or depends on Firebase Analytics and Crashlytics. Flutter, for the official SDKs.
5. The design is your own brand and must match on both platforms. Flutter.
6. None of the above. The framework your builder has shipped the most apps in. Ask to see the store listings.

Rule 3 sits above rule 4 on purpose. If both fit, we'd pick React Native and budget time to test the ad and Firebase libraries on real phones. A team that can't read its own app's code is a bigger risk than an unofficial SDK.

Our preference for Flutter, and how to weigh it

We prefer Flutter, and you should know why before you trust this post. We've shipped Flutter apps. We write React and TypeScript for the web (this site runs on Next.js), but none of the apps this post draws on is a React Native app. So the React Native half of this post comes from its docs and release notes. The Flutter half adds what we learned in our own builds.

Much of our preference is familiarity. The parts that go beyond habit:

• The SDKs our apps depend on are official on Flutter (the table above).
• One engine draws every screen, so there's one layout to reason about and one place to fix it.
• Rule 6 points to Flutter for us, because it's what we've shipped.

What would change our mind on a project: your team writes React, the app shares code with a React web product, or every vendor on your SDK list supports React Native officially. In those cases we'd say so on the scope call. If React Native wins and you want a team with React Native releases behind it, ask every studio you talk to, us included, for store links to apps they built in it.

When neither is the right choice

• The product is a platform engine (video editing, system services) or a watch app. Go native, as rule 1 says.
• You have Android developers who write Kotlin. Kotlin Multiplatform shares code between platforms, and Compose Multiplatform for iOS has been stable since version 1.8.0 in May 2025 (JetBrains). We haven't built with it; we mention it because it's the third option people ask about.
• People find the product through search. Flutter's own docs say Flutter "is not suitable for static websites with text-rich flow-based content" (Flutter web FAQ). Expo can statically render React Native pages for search engines (Expo web), though we'd still build the marketing site on its own. Whether you need an app at all is the question in web app, mobile app or PWA: what to build first.
• It's a 3D game. A game engine fits better than either.

What we would do

For a new app on both stores that we build and look after, we'd use Flutter, with Firebase, RevenueCat and AdMob where the app needs them. That's our Flutter app development work, and the written plan names any native modules before the build starts.

The conditions: your own team won't take over the code in React, there's no React Native app already, and no single native feature is the product. If any of those fails, go back to the rules above. If they point to React Native, we'll tell you on the scope call.

Your next step

Answer two questions in writing. Who will maintain this code two years from now? Which SDKs does the app need? If the first answer is a React team, choose React Native. If it isn't, and the SDK list includes AdMob or Crashlytics, choose Flutter. If neither settles it, choose the framework your builder has shipped the most. Put both answers in your brief and send it to us or to hello@zoftaa.com, and we'll start with a scope call.