Choose React Native when your team already writes React and TypeScript, when you want to share people and some code with a React web app, or when the app is content, commerce or account self-service that should use real native controls. Start it with Expo, which the React Native team itself recommends. Look elsewhere when the device is central to the product, or when your team has no JavaScript background and would be more productive in Flutter or native code.
React Native has changed more in the last two years than in the five before. This post covers where it stands now, what Expo gives you, and when we would and would not pick it.
How React Native works now
You write components in React, usually with TypeScript, and React Native renders them as real iOS and Android views. A button is a platform button, a scroll view scrolls with the platform's physics. That is the core difference from Flutter, which draws its own widgets.
What changed underneath is the New Architecture. The old design passed messages between JavaScript and native code over an asynchronous bridge, which caused the lag and dropped frames React Native used to be known for. The New Architecture replaces it with direct calls between JavaScript and native code (JSI), a new renderer (Fabric) and lazily loaded native modules (TurboModules). The milestones that matter:
- React Native 0.80 (June 2025) froze the legacy architecture.
- React Native 0.82 (October 2025) was the first release that runs entirely on the New Architecture; the legacy one can no longer be switched on.
- React Native 0.84 (February 2026) made Hermes V1 the default JavaScript engine.
- The current release at the time of writing is 0.87 (August 2026).
In practical terms: the architectural debate is over. If a library or tutorial assumes the old bridge, it is out of date. When you assess an existing React Native app, the first question is whether it has made the move, because an app stuck on the legacy architecture cannot take current releases.
Expo is the default way to start
The React Native documentation now says plainly that new apps should be built with a framework, and names Expo as a production-grade one. Expo adds file-based routing (Expo Router), a standard library of native modules, and build and update services (EAS).
npx create-expo-app@latest
Expo ships SDK releases that each pin a React Native version. SDK 57 (June 2026) is built on React Native 0.86; SDK 58 is in beta on a release candidate of React Native 0.88. Recent SDKs have made Expo UI's SwiftUI and Jetpack Compose APIs stable, so you can use genuine platform UI components from React code, and let you write small Swift and Kotlin modules directly in your project.
Where React Native is the right choice
You already have React developers. This is the strongest reason. Your web team's knowledge of React, TypeScript, state management and testing carries over, and hiring for React is usually easier than for Dart or for two native stacks.
You have a React web app. Business logic, API clients, validation and types can be shared between web and mobile in a monorepo. UI components mostly cannot be shared directly, but the thinking and the team can.
Platform-native controls matter. Because components render as real native views, text inputs, pickers, navigation and accessibility follow each platform's conventions with little effort. For customer-facing apps that should feel at home on both systems, that is a real advantage.
Frequent content and logic changes. Over-the-air updates (EAS Update) let you ship JavaScript changes without a full store release. They must stay within the store rules, and anything that touches native code still needs a store build.
Where it is not the best fit
The device is the product. Heavy Bluetooth work, camera pipelines, background processing and new platform features on release day mean much of the value sits in native modules. You can write them in React Native, but at that point native apps are worth pricing up.
No JavaScript in the building. A team of Kotlin or Swift developers will not enjoy being moved to React. Kotlin Multiplatform, native, or Flutter is a kinder choice.
Pixel-identical custom UI everywhere. If the design is heavily custom and must look exactly the same on both platforms, Flutter's own-renderer model does that with less effort.
You cannot commit to upgrades. React Native apps pull in many third-party packages. Staying current with React Native, Expo SDKs and those packages is routine work, a few times a year. Apps that skip it for two years face a painful catch-up.
Setting up a React Native project sensibly
- Start on the current Expo SDK with TypeScript. Use development builds from the start rather than relying on Expo Go.
- Check every native dependency supports the New Architecture. Prefer libraries Expo maintains or recommends.
- Choose navigation and state patterns once. Expo Router for navigation keeps routes predictable; pick one data-fetching and state approach and document it.
- Design offline behaviour before screens. Decide what lives on the device and how it syncs. See offline-first mobile apps and sync architecture.
- Put SDK upgrades on the calendar. Plan an upgrade after each Expo SDK release rather than letting versions pile up.
If React Native is on your shortlist, read Flutter: when to choose it for the strongest alternative, and the overview in choosing a mobile app framework. If you also run a React web product, React and Next.js: when to choose them covers the web side. Our mobile app development team works with both.
Questions we get asked
What is the React Native New Architecture?
It is the redesigned core of React Native, replacing the old asynchronous bridge between JavaScript and native code. It uses JSI for direct calls, the Fabric renderer and TurboModules for native modules. React Native 0.82, released in October 2025, was the first version that runs only on the New Architecture, so every current app and library must support it.
Should I use Expo or plain React Native?
Use Expo for new apps. The React Native documentation recommends starting with a framework and names Expo as production-grade. Expo provides routing, a standard library of native modules, and build and update services, and development builds still let you add any custom native code. Plain React Native mainly makes sense when integrating into an existing native app.
Is React Native slower than Flutter or native?
For typical business apps, users will not notice a difference when the app is built well. The New Architecture removed the old bridge that caused many performance complaints, and Hermes V1 is now the default engine. Very animation-heavy or computation-heavy screens may still need native code or careful optimisation, whichever cross-platform framework you choose.
Can React Native share code with a React website?
Partly. Business logic, API clients, validation rules and TypeScript types can be shared between a React web app and a React Native app in one repository. Most UI components cannot be shared directly, because web and mobile render different primitives, but developers move between the two easily, which is often the bigger benefit.
Can I update a React Native app without the app store?
You can ship JavaScript and asset changes over the air with services such as EAS Update, so fixes reach users without a full store review. Anything that changes native code, permissions or the app's core purpose still needs a new build submitted to the App Store and Google Play, and updates must respect both stores' policies.