React Native vs Flutter in 2026: how to choose

For most business apps in 2026, the React Native vs Flutter decision comes out in favour of React Native with Expo, because it shares a language and a hiring pool with the web product you probably already have. Flutter is the better choice when the app is its own visual world, when it must look identical on every device, or when your team already writes Dart. Both are mature, both are fast enough for nearly anything a founder will build, and both run in production at companies far larger than yours. The choice is about people, design and how the app changes over the next few years, not about which one wins a benchmark.

We build with React Native, so read this with that in mind. We have tried to say plainly where Flutter wins, and there are real cases where it does.

React Native vs Flutter under the hood

The two frameworks solve the same problem in opposite ways. Most of the practical differences follow from that one fact.

React Native lets you write the app in JavaScript or TypeScript using React. At runtime it creates real platform views, so its components are “backed by the same views as Android and iOS”. A switch on an iPhone is the iPhone’s own switch.

Flutter takes the other route. It ships its own implementation of every control, written in Dart, and paints every pixel itself. Flutter’s architecture overview gives three reasons: unlimited room to customise controls, no back-and-forth between framework and platform code while drawing a frame, and an app that looks the same on every operating system version. Release builds compile Dart ahead of time to machine code.

So React Native apps inherit the platform’s look and behaviour, including when the platform changes. Flutter apps look exactly as designed everywhere, including when the platform changes and you might have wanted them to follow.

Both have changed a great deal recently, which is why older comparisons mislead.

The long-standing complaint about React Native was the bridge, an asynchronous queue that serialised every message between JavaScript and native code. The New Architecture replaced it with a direct interface (JSI) that lets JavaScript hold references to native objects, and added synchronous layout and React’s concurrent features. Since React Native 0.82 in October 2025 it is the only architecture; the setting to turn it off is ignored. React Native 0.84 then made Hermes V1, a faster version of its JavaScript engine, the default on both platforms, and ships precompiled iOS binaries so builds take less time.

The long-standing complaint about Flutter was stutter the first time an animation ran, caused by shaders compiling while the app was in use. Its newer renderer, Impeller, compiles a smaller set of shaders when the engine is built instead. It is the only renderer on iOS and the default on Android API 29 and above. Older Android devices, and those without Vulkan support, fall back to the previous OpenGL renderer.

Both are proven at scale. The React Native showcase lists apps from Meta, Microsoft, Amazon and Shopify. The Flutter showcase lists Google Pay, NotebookLM, Nubank, BMW, Toyota and Dream11.

Performance is rarely the deciding factor

Founders ask about performance first, and it is usually the wrong first question. Lists, forms, feeds, maps, chat and payment flows make up most business apps, and both frameworks handle them without users noticing which one was used.

We could not find a recent, neutral benchmark that compares the two on current versions, so we will not quote one. Most published numbers predate React Native’s New Architecture or Flutter’s Impeller, or come from someone selling one side. The honest data is each project measuring itself. On the Expensify app, the React Native team measured Hermes V1 cutting total time to interactive by 7.6% on a low-end Android device and 2.5% on iOS, according to the 0.82 release notes. That is an engine getting faster, not a comparison with Flutter.

Where the architectural difference does show is at the edges. Flutter composes the whole screen in one pass without crossing into platform code, so heavily custom, animation-dense interfaces are its home ground. React Native’s strength is the opposite case. When a screen is mostly standard controls, those controls are the platform’s own, and they look and behave the way users of that platform expect.

If the app is a game, a 3D viewer or a real-time video editor, neither is the obvious answer. Native code or a game engine may be the better starting point.

Hiring and the size of the pool

This is the factor that most often decides the question, and it is the one comparison articles spend least time on.

React Native is written in JavaScript or TypeScript. In the 2025 Stack Overflow Developer Survey, 66% of respondents said they used JavaScript and 43.6% TypeScript. Dart, Flutter’s language, was at 5.9%. Those figures are about languages, not mobile experience. But they describe who you can move onto the app. The engineers building your web dashboard or your Next.js site already write the language React Native uses, and can share types, validation and API code with it.

The frameworks themselves are much closer. In the 2024 survey, 9.4% of all respondents used Flutter and 8.4% React Native. Among professional developers it was 9.4% and 9%. The 2025 survey did not list either. On GitHub, Flutter has about 179,000 stars and React Native about 127,000, as of September 2026. Stars measure attention rather than production use, but every figure here says the same thing: neither framework is a niche bet.

For a founder, the reading is this. Flutter has a large community of its own. A React Native app can be picked up by a much larger set of engineers, including the ones you may already employ.

The framework matters less than who maintains the app in three years. Choose the one whose language your current team, and the next people you hire, already write.

React Native with Expo is the default for most teams

People searching “React Native vs Expo” are usually comparing two things that are not alternatives. Expo is a framework built on top of React Native, much as Next.js sits on top of React. Since 2024 the React Native team has recommended starting new apps with a framework, and Expo is the only one it recommends. React Native without a framework is still supported.

The old objection, that Expo shut you out of custom native code, no longer holds. Expo’s FAQ covers development builds and config plugins for any native library. The one-way “eject” has been replaced by prebuild, which generates the native projects whenever you need them. The framework is free and open source. Its cloud build and update services, EAS, have a free tier and paid plans.

The feature that matters most commercially is over-the-air updates. EAS Update lets a published app download new JavaScript, styling and images without a store release. A bug in a checkout screen can be fixed without waiting for app review. It cannot change native code, permissions or the SDK version; those still need a new build. Flutter’s nearest equivalent, Shorebird, is a separate product rather than part of Flutter. It ships a modified Flutter engine and, likewise, updates only Dart code, not native code.

Following the platform also pays off when the platform changes. On iOS 26, Expo Router’s native tabs get the new Liquid Glass tab bar because the system draws it, not the framework. That feature is still marked alpha, which is worth knowing before you depend on it.

This is the stack we use for mobile app development, and for a typical product with a web app, a backend in TypeScript and a design that follows iOS and Android conventions, it is what we would recommend.

When Flutter is the better choice

There are products where we would recommend Flutter, and we say so.

• The design is the product. A fully custom, animation-heavy interface that should look the same on an old Android phone and a new iPhone is exactly what Flutter’s own rendering is for. You design once and get that design everywhere.
• Your team already writes Dart. Or you are building a dedicated mobile team from scratch with no web codebase to share. The hiring argument above then mostly disappears.
• Consistency matters more than feeling native. Kiosks, field tools and branded apps used on managed devices benefit from looking identical regardless of operating system version.

The trade-off is the mirror image of React Native’s. Because Flutter draws its own controls, operating system redesigns do not arrive by themselves. In June 2025 the Flutter team said it would not build Apple’s new Liquid Glass design into its Cupertino widgets for the time being, and the same applied to Google’s Material 3 Expressive update. In July it decided to move both design libraries out of the core framework into separate packages. As of September 2026 that issue is still open, and community packages fill the gap. For a bespoke design none of this matters. For an app that is meant to feel like iOS, it does.

Flutter on the web has a limit worth knowing too. The Flutter web FAQ says it is not suited to static, text-heavy sites, and recommends building landing and marketing pages in HTML. A web app behind a login is fine. The marketing site that needs to rank on Google should be built with something else.

React Native vs Kotlin and fully native

Some teams are not choosing between two cross-platform frameworks, but between one of them and native code: Kotlin for Android and Swift for iOS.

Go native when the app is on one platform only, when it lives close to the hardware (Bluetooth, long-running background work, camera pipelines), or when you can fund two separate mobile teams. An Android-only app for a field workforce gains little from a cross-platform layer. In the 2025 survey, 10.8% of respondents used Kotlin and 5.4% Swift.

There is also a middle path. Kotlin Multiplatform lets a team share business logic between Android and iOS, and with Compose Multiplatform the interface as well. JetBrains declared Compose for iOS stable in May 2025. It suits a company whose engineers already write Kotlin for Android.

Neither React Native nor Flutter removes native code entirely. The first time the app needs a platform feature that no library covers yet, someone has to write a little Swift or Kotlin. Budget for that person whichever you choose.

A decision checklist

Work through these in order. The first one that gives a clear answer usually settles it.

• Do you have a web product in TypeScript, or engineers who write it? Lean towards React Native with Expo.
• Is your team already fluent in Dart? Flutter is at least as good an option, and probably better.
• Is the interface a custom brand experience that should look identical everywhere? Lean towards Flutter.
• Should the app look and behave like a native iOS and Android app, and keep up as those platforms change? Lean towards React Native.
• Do you need to ship fixes without waiting for store review? Expo covers this directly. Flutter needs a separate product.
• Is it one platform only, or tied closely to device hardware? Consider native Kotlin or Swift.
• Do you also need a marketing site that ranks in search? Build it in HTML, whichever framework the app uses.