React Native vs Native: Which Should You Actually Build?

Choose React Native when your app is screens, forms, lists and API calls — which describes most business apps. Choose native when it depends on heavy graphics, sustained background work, deep OS integration or platform-specific hardware. The decision is usually made on vibes and framework loyalty, which is how teams end up paying twice for something they could have built once. Here is the version that actually decides it.

What is the real difference?

Native means two codebases — Swift for iOS, Kotlin for Android — each written and maintained separately. React Native means one JavaScript codebase that renders genuine native components on both platforms. It is not a web view wrapped in an app icon; the buttons and lists a user touches are the real platform controls.

Criterion	React Native	Fully native (Swift + Kotlin)
Codebases	One	Two
Typical cost	Baseline	Roughly 1.7–2× baseline
Team needed	One JavaScript/React team	An iOS team and an Android team
Feature parity across platforms	Automatic	Requires deliberate coordination
Access to brand-new OS features	Delayed, or needs a native module	Day one
Heavy graphics / games / AR	Poor fit	Strong fit
Sustained background processing	Constrained	Full control
Hiring pool	Large — any React developer is close	Two smaller specialist pools

Is React Native fast enough for a real product?

For the overwhelming majority of apps, yes — and the evidence is public rather than theoretical. Shopify, which runs its flagship commerce apps on React Native, reported in January 2025 that its React Native apps sustain over 99.9% crash-free sessions and sub-500ms screen loads at the 75th percentile. Those are numbers a lot of fully native apps would be pleased with.

The honest caveat is that this performance is not free. It comes from a team that invested years in tooling and knows where the framework's edges are. A React Native app built carelessly can absolutely feel worse than a native one — the framework raises your ceiling, it does not guarantee your floor.

When should you actually go native?

There is a short list of genuine forcing functions, and if none apply to you, the cross-platform argument usually wins. Go native when:

• The app is graphics-heavy. Games, real-time video effects, AR, or anything rendering complex scenes at 60fps. This is not a React Native problem to solve.
• It runs sustained work in the background. Continuous location tracking, health and fitness sensors, audio processing, or anything the OS aggressively suspends. Native gives you the control you will need.
• It depends on brand-new OS features. If your differentiator is a widget type or API Apple announced two months ago, native gets it first.
• You already have two strong platform teams. If you have iOS and Android specialists on staff, forcing them through JavaScript throws away your actual advantage.

Notice what is not on that list: "we want it to feel premium." Feel comes from design and attention, not from the language the app is written in. Plenty of native apps feel cheap and plenty of React Native apps do not.

"Almost nobody needs to choose a framework. They need to decide whether their app is mostly screens or mostly system. If it is mostly screens, building it twice is an expensive way to arrive at the same place."

— Shaheer Malik, product designer and Framer developer

What about Flutter?

Flutter is a credible alternative with one meaningful trade-off: it draws its own components rather than using the platform's, which gives you tighter visual consistency across iOS and Android but means your app follows Flutter's conventions rather than each platform's. Choose Flutter when your brand's visual identity matters more than platform-native feel, and React Native when the reverse is true — or simply when your team already writes React, which is the practical reason most teams land there.

What does a React Native app cost?

The saving over native is real but smaller than the marketing suggests. One codebase does not mean half the work, because design, testing, store submission and platform-specific edge cases still happen twice in miniature. Budget for roughly half to two-thirds of a comparable two-team native build, not a quarter.

I build React Native apps at a fixed $2,500 for a focused first version — a real app on both stores rather than a prototype. That scope suits founders validating something with actual users; it does not suit a marketplace with payments, chat and background location, and I will say so rather than quote it.

What to do next

Write down the three features your app cannot launch without. If none of them touch heavy graphics, background processing or brand-new OS APIs, React Native is your default and the burden of proof is on going native. If one does, that feature — not the framework debate — is the thing to design around first. Costs for the surrounding design work are broken down in my guide to what app design costs, and if you want a read on which side your idea falls, describe the app and I will tell you.