← Blog
·Updated ·8 min read

React Native vs Native: When to Choose Which

React Native vs native iOS/Android vs Flutter — codebase costs, performance reality, hiring, and OTA updates, with evidence from three shipped React Native apps.


Key takeaways: React Native shares 80–90% of code across iOS and Android — that's the whole app, not just UI. For most products the performance difference from native is imperceptible, and when you do need native power, Expo modules let you drop down without abandoning the stack. Choose native only for frame-perfect graphics or deep platform-API work.

The Mobile Development Choice That Matters

When you commission a mobile app, one of the most consequential technical decisions is the development approach. Build native (separate iOS and Android codebases), use React Native (one codebase, both platforms), or go with Flutter or a web wrapper?

Our default is React Native. Here's why — and honestly, when it isn't.

What React Native Actually Is

React Native is a framework developed by Meta that lets you build mobile apps using JavaScript and React. Unlike web wrappers (which render a website inside a shell), React Native compiles to native UI components. Your app uses real iOS and Android components — it just doesn't require you to write them twice.

The result: apps that look and feel native, built at the speed of cross-platform development.

The Comparison

React NativeNative (Swift/Kotlin)Flutter
Codebases to maintain121
Code shared across platforms80–90%0%~90%
UI componentsReal native componentsNativeCustom-rendered (Skia)
PerformanceNative-equivalent for most appsMaximumNear-native
Hiring poolHuge (React/JS ecosystem)Two separate specialist poolsGrowing (Dart)
Web skill transferDirect (React)NoneNone
OTA updatesYes (Expo Updates)No — store review every timeLimited
Native escape hatchExpo/TurboModulesN/APlatform channels
Best forMost productsFrame-perfect graphics, deep platform APIsDesign-heavy custom UI

Why We Chose React Native

One Codebase, Both Platforms

A React Native app shares roughly 80–90% of code between iOS and Android. That's not 80% of the UI — it's 80% of the entire application: business logic, navigation, data fetching, state management, and most screens.

What does that mean for your budget? Instead of paying for two development teams, you pay for one. Instead of maintaining two codebases, you maintain one. Every bug gets fixed once.

React Expertise Transfers

The React ecosystem is vast. We build web applications with Next.js and mobile applications with React Native. The mental models, patterns, and libraries overlap significantly. When a developer is skilled in one, they're productive in the other. That's good for you — your team's knowledge compounds instead of fragmenting.

Performance Is Close Enough — or Better

For the vast majority of applications — social apps, productivity tools, marketplaces, dashboards — React Native performance is indistinguishable from native. The apps ship to the App Store and Play Store as normal apps. Users can't tell the difference.

Faster Iteration

React Native's hot reload and fast refresh mean developers see changes instantly without recompiling the whole app. Combined with Expo's OTA updates, some bug fixes and content updates can reach users without an app store review cycle.

Evidence: Three Shipped Apps

This isn't theoretical for us — it's how our products are built:

  • [FieldDojo](/case-studies/fielddojo) — 16+ trade calculators with offline SQLite history, native tab navigation, and a keyboard-heavy UI that had to feel native. React Native + Expo handled all of it from one codebase.
  • [Wageasy](/case-studies/wageasy) — GST-compliant invoicing with offline PDF generation via the platform's native print APIs. The tax logic and PDF pipeline are shared code; the native print integration comes free through Expo.
  • [expo-panoramic-stitcher](/case-studies/expo-panoramic-stitcher) — the counter-example that proves the rule. When we needed OpenCV's C++ stitching pipeline, we didn't abandon React Native; we wrapped it in a thin Expo native module and kept one JavaScript API across both platforms.

That last one matters most for the "but what if we need native?" worry: React Native doesn't lock you out of the native layer. It lets you visit it only where it pays.

When We Recommend Native Instead

We'll tell you when React Native isn't the right choice:

  • High-performance graphics: Apps that need frame-perfect 3D rendering or heavy GPU processing throughout
  • Deep platform API access: Apps whose core is extensive platform-specific APIs not yet bridged for React Native
  • Very large existing native codebases: When migrating to React Native would cost more than the maintenance savings

The Bottom Line

For most mobile products, React Native gives you native quality at a fraction of the cost and timeline. That's why we chose it, and why we'll be honest with you when a project is one of the exceptions.

Talk to NOTchip about your mobile app project and we'll give you our honest assessment of the right approach.