React Native is our default for mobile work, and it has been for years. That is not the same as saying it is always right. There are projects where we tell clients to build native, and being clear about which is which saves everyone money.
This post was originally written in 2023. Enough has changed since then, particularly the New Architecture becoming the default, that it needed a rewrite rather than a touch-up.
The short version
Choose React Native when your app is primarily screens, forms, lists, navigation, and API calls, which describes the large majority of business and consumer apps. Choose native when the app's core value depends on sustained high-performance graphics, deep platform integration, or hardware access at the edge of what the platform supports.
The mistake is not picking wrong on a close call. It is not making the call deliberately at all.
What changed since 2023
Three things are worth knowing if your last look at React Native was a few years ago.
The New Architecture is the default. The old asynchronous bridge between JavaScript and native code, which was the source of most legitimate performance complaints, is gone. The current model uses a synchronous interface layer, which means native modules can be called directly and the UI can update without serializing every message across a queue. In practice this shows up as smoother list scrolling, faster startup, and far fewer of the frame drops that used to define the "feels like a web app" criticism.
Expo became the sensible default. For most projects, starting outside Expo now costs you more than it saves. Over-the-air updates, managed builds, and a large library of vetted native modules remove weeks of setup and maintenance. You can still drop to bare native code when you need to.
The talent math got clearer. A team that already writes React can ship mobile without hiring two additional platform specialists. That was always the pitch. What is different now is that the quality ceiling is high enough that the tradeoff is no longer "cheaper but worse."
When we recommend React Native
One codebase, two platforms, one team. This is the core argument and it holds. Shared business logic, shared state management, shared API layer, shared component structure. Platform-specific code where it matters, which is usually less than you would guess. If your team already works in React, the same people who build your web frontend can build the app.
You need to ship and iterate quickly. Fast refresh during development and over-the-air updates after launch mean the loop from idea to a user's phone is measured in hours for JavaScript-layer changes, not days waiting on app review.
The app is mostly product, not platform. Onboarding flows, feeds, search, forms, payments, notifications, offline caching. React Native handles all of it well, and the interesting engineering is in the product logic and the backend, not in the rendering layer.
Design consistency matters to you. Sharing a design system across platforms is dramatically easier when there is one component tree. Two native codebases drift, always, and the drift is invisible until someone screenshots them side by side.
When we recommend native instead
We say this out loud on calls, so we will say it here too.
Sustained heavy graphics or real-time rendering. Games, AR, live video effects, complex custom animation running continuously. If the app's core loop is pushing pixels at 60 frames a second, go native.
Deep or bleeding-edge platform integration. Widgets everywhere, complex background processing, Apple Watch or Wear OS as a first-class surface, brand-new OS APIs the day they ship. React Native can reach all of these through native modules, but if that is most of your app, you are writing native code with an extra layer on top.
Specialized hardware access. Custom camera pipelines, Bluetooth peripherals with unusual protocols, low-level sensor work. Possible in React Native, but the bridge maintenance becomes the project.
A team that is already strongly native. If you have experienced iOS and Android engineers and no React expertise, the cross-platform argument mostly evaporates. Use the team you have.
The performance question, answered honestly
For a typical business app, users cannot tell. Startup time, scroll performance, and interaction latency in a well-built React Native app are indistinguishable from native to anyone who is not measuring.
Where the difference shows up is at the extremes: very long lists with complex cells, heavy image processing, animations that run continuously rather than in response to a gesture. Most of those have known solutions, and the rest are cases where you should have gone native.
The more common cause of a slow React Native app is not React Native. It is the same thing that makes web apps slow: too much work on the main thread, unnecessary re-renders, images that were never sized correctly, and an API that makes six sequential calls where one would do.
What we build with
For most projects: Expo with the New Architecture, TypeScript throughout, React Navigation, and a state layer chosen to fit the app rather than by habit. Native modules where a platform capability requires them. Over-the-air updates for anything that does not need a store release, and a CI pipeline that produces signed builds for both stores without anyone running a local build.
Testing is unit tests on business logic, component tests on the pieces that carry real logic, and end-to-end coverage on the flows that would cost you money if they broke: sign-up, checkout, anything touching payments.
How to decide
Ask one question first: is the hardest part of this app the interface layer, or is it everything else?
If the hardest part is the rendering, the hardware, or the platform integration, build native. If the hardest part is the product, the data, and getting to market, build React Native and put the saved budget into the parts users actually notice.
We have shipped both. Hungry Monster and Boycottr are React Native apps where the interesting work was product and backend, not rendering, which is exactly the profile React Native was built for.
If you are weighing this decision for a specific app, our mobile development page covers how we scope and ship these projects, and product strategy is where we start when the question is still whether to build at all.