React Native or Native: How to Actually Decide
Sergio JimenezOctober 21, 20266 min read
The question is usually asked as if it were ideological. It is not. React Native and native development are both good answers to different situations, and the right one falls out of four facts about your product: how many platforms you ship, how much of the device you touch, who maintains it, and how long it has to live.
Here is how to decide without a religious argument.
The short answer
| Your situation | Choose |
|---|---|
| Both platforms, one small team, standard product surface | React Native |
| One platform only, and that will not change | Native |
| Heavy camera, audio, Bluetooth or on device machine learning | Native, or React Native with native modules |
| A game, or anything rendering its own frames | Neither. Use a game engine |
| You already have a React web team | React Native |
| Your differentiator is a platform feature on day one | Native |
What React Native actually gives you
One codebase that produces real iOS and Android apps. Not a web page in a shell: the buttons are platform buttons, the lists are platform lists, and the result is indistinguishable from native for the vast majority of products.
The saving is not 50 percent, which is the number people expect. In practice you share 85 to 95 percent of the product code and write the remaining slice twice, so the realistic saving against two native teams is 30 to 40 percent on the first build and considerably more over the following years, because every feature after launch is also written once.
The second saving is organisational and larger than it looks. One codebase means one backlog, one release process and one set of bugs. Two native teams drift: a fix lands on Android in March and on iOS in May, and your support team starts asking which phone the customer has before they can answer anything.
What native actually gives you
Direct access, on the day of release. When Apple ships a new API at WWDC, native has it immediately and React Native has it when someone writes the bridge. If your product depends on being first to a platform capability, that gap is the whole argument and nothing else matters.
Native also wins where the work is close to the metal. Sustained camera processing, low latency audio, Bluetooth peripherals, background location over long periods, on device models. React Native can reach all of these through native modules, but at that point you are writing Swift and Kotlin anyway, and the question becomes how much of the app is that work. If it is most of it, go native.
The performance argument, honestly
For a normal product, React Native performance is not a problem, and people who say otherwise are usually remembering 2018. The new architecture removed the serialised bridge that caused the old complaints.
Where you will still feel it: very long lists with complex cells, animations that must hold 60 frames per second while heavy work happens, and app startup time, where native keeps a real advantage. If your product is a feed that people scroll for forty minutes a day, measure before committing. If it is a booking flow, a marketplace, a dashboard or a tool, this is not your bottleneck. Your bottleneck is network latency, and that is the same in both.
The costs people forget
React Native has an upgrade tax. New versions arrive regularly and bring the ecosystem with them. A team that skips upgrades for eighteen months will spend weeks catching up, usually at the worst possible moment. Budget a few days each quarter and it stays boring.
It also has a dependency surface. Much of what you need comes from community packages of varying quality. Choosing well matters more than in native development, where more arrives in the box.
Native has its own forgotten cost, and it is bigger: you are hiring and retaining two specialist skill sets permanently. Not for the build. Forever.
What about Flutter
Flutter is a genuine alternative and good at what it does. It draws its own widgets rather than using the platform's, which gives you pixel identical results across platforms and a slight uncanny feeling on iOS if you care about platform conventions. The deciding factor is usually your team: if your engineers write React, React Native costs them nothing to learn and Dart is a new language and a separate talent pool. We build in React Native for that reason, not because Flutter is bad.
How we decide
We default to React Native and move to native when something specific forces it. In practice that is a handful of cases: the product is a game, the differentiator is a brand new platform API, or more than half the work is sustained device level processing.
The hybrid is also underrated. Ship React Native, and write the one hard part as a native module behind a clean interface. You get a single codebase for the 90 percent that is ordinary product work and full native performance exactly where it is needed. Most of the apps we ship look like this, and it is what our Studio engagements assume by default.
Frequently asked questions
Is React Native good enough for a production app?
Yes, and it is already running products with tens of millions of users. The limits are narrow and specific: games, sustained device level processing, and same day access to brand new platform APIs. For marketplaces, bookings, social products, fintech apps and internal tools, it is a straightforward choice.
Is React Native cheaper than native development?
Usually 30 to 40 percent cheaper for a first build targeting both platforms, and the gap widens after launch because every subsequent feature is written once rather than twice. It is not cheaper if you only ever ship one platform.
Can you mix React Native and native code?
Yes, and this is often the best answer. You write the product in React Native and implement the one demanding piece, a camera pipeline or a Bluetooth integration, as a native module in Swift or Kotlin behind a clean interface. You keep one codebase for ordinary work and full native performance where it matters.
Does Apple reject React Native apps?
No. App Store review does not care what you built the app with, only how it behaves. Rejections come from missing privacy declarations, broken sign in flows, thin content or payment rules, and those apply equally to native apps.
React Native or Flutter?
Both are capable. Flutter renders its own widgets, which gives identical visuals across platforms and slightly less platform native feel. The usual deciding factor is your existing team: React engineers move to React Native immediately, while Flutter means Dart and a separate hiring pool.
What happens when a new iOS version breaks my app?
The same thing that happens with native: you update and release. The difference is you may wait days for a community package to catch up. This is a real cost and it is managed by keeping dependencies current rather than by letting them rot for a year.
Where to start
Write down the three hardest technical things your app must do. If none of them touch the camera, audio pipeline, Bluetooth stack or a platform API released this year, the decision is already made and you should stop debating it.
If one of them does, tell us which and we will tell you honestly whether it needs native, and what it costs either way.
