Native vs React Native
The question is not which produces a better app. It is whether your app needs the parts of the platform that only native code reaches.
The short answer
Build native when hardware, background behaviour or the newest operating system features are the product, and choose React Native when the app is screens, forms and data that two platforms should share.
One misconception drives most of this debate. React Native is not a web page in a wrapper. Its documentation is explicit that components map directly to the platform's own UI building blocks, and that the app uses the same native APIs other apps do.
So the real trade is reach versus depth. Nothing is lost in how the app looks. What you give up is immediate access to whatever Apple or Google shipped last week.
Side by side
Compared on what changes the decision. Both produce apps that ship in the same stores under the same review rules.
| Dimension | Native (Swift and Kotlin) | React Native |
|---|---|---|
| Codebases to maintain | Two, with two release cycles | One, plus platform-specific pieces |
| User interface | Platform components, directly | Platform components, through React |
| New OS features | Available as the platform ships them | Wait for support, or write the bridge |
| Heavy hardware use | The natural home for it | Usually means dropping into native code |
| Team shape | iOS and Android specialists | React engineers, plus native skill on call |
| Feature parity across platforms | Managed by discipline, and it slips | Shared by default |
| Recommended toolkits | Compose is Android's recommended toolkit; Apple positions SwiftUI alongside UIKit | One React codebase, New Architecture by default since 0.76 |
| Best fit | Camera, sensors, background work, games | Business apps, marketplaces, internal tools |
- Feature requestOne request, either way
- BuildOnce, or twice in two languages
- TestTwo platforms regardless
- ReleaseTwo store reviews regardless
- SupportOld versions live for a year
Only one of these five boxes gets cheaper with one codebase. That is the whole argument, honestly stated.
Native
Where it wins
- Everything the platform can do is available to you, without waiting for a library to catch up.
- Camera work, sensors, background processing and heavy graphics are where native stays clearly ahead.
- Android documents Jetpack Compose as its recommended toolkit for building native UI, so the path is well signposted.
- Debugging goes through the platform's own tools, with no extra layer to reason about.
Where it hurts
- Two codebases means two sets of bugs, two review cycles and two chances for the platforms to drift apart.
- You need specialists in both languages, and covering holidays and departures is harder with two small teams.
- The same feature is specified once, then built twice, which is where budgets quietly double.
- Feature parity is a discipline problem forever, and it slips whenever one platform gets more attention.
React Native
Where it wins
- One team ships to both platforms, and features arrive on both at once rather than weeks apart.
- The app renders real platform components, so it does not look or behave like a website in a shell.
- React engineers are easier to hire than two separate mobile specialisms.
- The New Architecture has been the default since 0.76, which addressed the performance criticism most articles still repeat.
Where it hurts
- A new operating system feature may need a bridge written before you can use it.
- Anything hardware-heavy tends to end in native code anyway, so you need that skill somewhere on the team.
- You inherit an extra dependency layer, and a badly maintained library becomes your problem at the worst moment.
- Upgrades between major versions need planned time, and a project three versions behind is expensive to rescue.
How to choose
- Choose native if the app is the hardware: a camera product, a fitness tracker reading sensors all day, a game.
- Choose native if you must adopt new operating system features the week they ship, which matters for consumer apps competing on novelty.
- Choose React Native if the app is screens, forms, lists and data, which describes most business software.
- Choose React Native if the same small team must serve iOS and Android without one platform falling behind.
- Choose one platform first if budget is tight. A good iOS-only app beats two mediocre ones, and you can add Android once demand is proven.
- Choose neither if nobody has validated the need. A mobile web page tests the idea without a store review, and it costs a fraction of either path.
Apps we have shipped to both platforms
Questions product owners ask
01Will users notice the difference?
In a well-built business app, no. React Native renders the platform's own components, so scrolling, keyboards and system gestures behave as users expect. Where people do notice is heavy graphics, complex custom animation, and anything reading sensors continuously, which is exactly the work that belongs in native code.
02Can we mix native code into a React Native app?
Yes, and serious apps usually do. The documented route is a Turbo Native Module, which lets you write the platform-specific piece and call it from your shared codebase. That is the pattern to plan for: shared code for the product, native code for the few places that need it.
03Does going cross-platform halve the budget?
No, and expecting that is how projects disappoint. You still test on two platforms, submit to two stores, and support old versions of both. The saving is in writing the features once, which is real but is only part of the total. Budget a meaningful share of the work for the parts one codebase does not remove.
04What if we start with React Native and outgrow it?
You move the demanding parts to native code first, rather than rewriting everything. Because a React Native app can call native modules, a screen that needs more can be replaced in place while the rest stays shared. Full rewrites are usually chosen for reasons other than the framework, and they cost a year of feature work.
05How do we decide if we have no mobile experience in-house?
Start from the feature list, not the technology. Write down everything the app must do with the device itself: camera, location in the background, offline use, notifications, hardware peripherals. If that list is short, one codebase is the sensible default. If it is the product, hire or buy native skill.
