React Native or native? The honest answer
After fifteen React Native apps and four native ones, here is what we have learned about when each is genuinely the right choice.
The "React Native vs native" debate is one of the most religious conversations in mobile development, and almost all the loud opinions on both sides are wrong. Or, at least, missing context.
Having shipped fifteen production React Native apps and four pure-native ones over the past seven years, here\'s the framework we use to choose. It is, intentionally, not the answer most blog posts give you.
The TL;DR
React Native is the right choice for roughly 80% of new mobile apps. Native is the right choice for the other 20%. The interesting work is figuring out which 20% you\'re in.
What React Native actually is
First, let\'s get terminology right. React Native is not a "wrapper around a webview" — that was Cordova/PhoneGap, and it\'s been dead for years. React Native renders real native UI components (UIView on iOS, View on Android). Your JavaScript code instructs the platform to display real native widgets.
The performance ceiling is therefore very close to native for UI rendering. The performance gap shows up in three places:
- Compute-heavy work on the JS thread — image manipulation, complex animations driven by JS, video editing. The "new architecture" (rolling out through 2024–2025) reduces this gap significantly but doesn\'t eliminate it.
- Startup time — a React Native app takes 200–400ms longer to launch than a pure native app. Most users don\'t notice; some categories (utilities you launch many times a day) might.
- Deep platform integrations — anything that requires custom native modules. You can build them, but you\'re writing native code anyway, so the calculus changes.
Where React Native wins
The case for React Native is strongest when:
You\'re building for both platforms from day one
The math is straightforward. Native iOS + native Android means two codebases, two teams (or one team with split focus), two release cycles, two bug surfaces. React Native means one of each, with platform-specific code as needed (typically 5–15% of the codebase). Roughly speaking, you\'re looking at 60–70% of the cost of dual-native — and the gap widens over the project\'s lifetime, because maintenance is the same multiplier.
Your app is a UI over an API
Most apps are. CRUD over a backend, lists and details and forms, some images, some authentication, payments via Stripe, maybe push notifications, maybe a map. For this enormous category — which includes virtually every B2B app, most B2C apps, every booking and ordering app — React Native is comfortably good enough. You will not run into framework limits.
You have web developers, not iOS/Android developers
This is the unspoken but real reason most startups choose React Native: they have a React team already. The same developers can ship the mobile app. The same component patterns apply. There\'s a learning curve, but it\'s a hill, not a mountain.
The product will change rapidly
Pre-product-market-fit, you\'re going to ship the wrong thing many times before you ship the right thing. React Native\'s shorter iteration cycle (no compile, hot reload, OTA updates via Expo) means you can change direction faster. Speed of iteration usually beats raw runtime performance at that stage.
Where native wins
The case for native is strongest when:
Performance is the product
If you\'re building Procreate, Final Cut, or a real-time AR app, native is not optional. You need direct access to Metal/Vulkan, fine-grained memory control, and the platform\'s newest performance APIs the moment they ship. React Native\'s abstractions help with productivity but cost in places where every frame matters.
The app is mostly system integration
Apps deep in the OS — keyboard apps, lock screen widgets, accessibility tools, complex Apple Watch / Wear OS companions — are easier in native. You can do them in React Native, but you\'ll write so much native code anyway that the cross-platform benefit evaporates.
You\'re only shipping one platform, ever
If you genuinely will never need the other platform — maybe you\'re building an internal tool for a company that\'s iOS-only, or a watchOS-first product — there\'s no cross-platform value in React Native. Use the platform\'s native stack.
You\'re a native-staffed team
If your team is Swift and Kotlin developers, hiring them to write React Native is a bad use of their skill. The reverse is also true.
The bad reasons to pick each one
Bad reasons for React Native:
- "It\'s cheaper." It\'s sometimes cheaper. Sometimes it\'s actually more expensive, when your project hits one of its sharp edges and you have to rebuild things in native modules.
- "Facebook uses it." Facebook also has 50 engineers maintaining React Native internals. You won\'t.
- "It\'s faster to build." Initially, maybe 20–30% faster. Over the project lifetime, the gap narrows to ~10%.
Bad reasons for native:
- "React Native is slow." Untrue for 95% of apps. Profile your actual bottleneck before choosing based on this.
- "We might need to do something custom." You can build native modules in React Native when you need them. The escape hatch exists.
- "The app store reviews React Native apps differently." Apple has explicitly endorsed cross-platform frameworks. This concern is from 2017 and outdated.
The third option: Flutter
We\'re asked about Flutter often, and the honest answer is we don\'t use it much. Flutter is technically excellent — the Skia-based rendering is a more elegant approach than React Native\'s bridge model. But the ecosystem is smaller, the talent pool is smaller, and the JavaScript/TypeScript ecosystem React Native plugs into has unmatched gravity. For our clients, that ecosystem advantage usually outweighs Flutter\'s technical advantages.
Flutter is a great choice if you have a Dart-experienced team or are starting fresh and care more about engineering elegance than ecosystem size.
What we recommend by default
Our default recommendation, when someone walks in with a typical app idea:
"Start with React Native. If we hit a wall, we\'ll know. We never have, in projects of your shape."
That recommendation has been right about 14 times out of 15. The one time it wasn\'t (a video-heavy app that needed custom GPU pipelines), we rebuilt the affected screens in native and kept the rest in React Native — that\'s a valid path too.
Scoping a mobile app and not sure which stack fits? Tell us about your project and we\'ll give you our honest take. Get in touch.