React Native vs native: the honest decision framework
When to pick React Native, when to go fully native, and when to do both — written by a team that has shipped both for real customers.
For a B2B SaaS mobile companion app, an internal tool, or a content-heavy consumer app, React Native is almost certainly the right choice in 2026. For a game, a high-performance creative tool, a deeply OS-integrated utility, or a fitness tracker with sustained background sensors, go native. For everything in between, the question is whether the team has more React talent than native talent — because for the middle tier, both technologies will ship a good app, and the deciding factor is which one your team can move faster on. The "performance" debate is largely settled. Native is faster in narrow ways that don't matter to most apps. React Native is fast enough for most things and dramatically faster to iterate on.
We've shipped React Native apps and native apps for real businesses. This is the framework we use to decide.
What changed in 2026
If you read a React Native review from 2021, throw it out. The runtime has changed materially:
- New Architecture (Fabric + TurboModules + JSI) is stable and the default for new projects
- Bridgeless mode removes the old async bridge — most app perf comparisons predate this
- Hermes is the default JS engine, with significant memory and startup improvements
- React Native Skia for performant 2D graphics that match Canvas/SwiftUI
- Reanimated 3 runs animations on the UI thread natively
- Expo SDK 53 is mature enough to use for production apps
A modern RN app does not feel like a web view. It feels like a native app, because under the hood it is a native app — just one driven by a JS reconciler.
What I'd build in React Native
Confident default for:
- B2B SaaS companion apps (CRM, support, inventory)
- Marketplace apps (Uber-style — both sides)
- Content-heavy social apps (feed-based UIs)
- Subscription content apps (course apps, podcast apps)
- E-commerce storefronts
- Crypto wallets (most production ones already are)
- Most internal enterprise apps
Reason: every one of these is a "screens + lists + forms + network" app. React Native excels at that shape.
What I'd build natively
Confident default for:
- 3D games or apps with custom rendering pipelines (use Unity or native + Metal/Vulkan)
- Apps with sustained background sensor work (fitness trackers, navigation, AR)
- System-level utilities (clipboard managers, keyboard extensions, network tools)
- Camera-first apps (heavy ARKit/ARCore, real-time video processing)
- Watch / TV / car / vision OS — every Apple sub-platform has its own SDK
- Anything that has to ship a Widget or App Clip with deep integration
Reason: these depend on platform APIs and performance characteristics that RN abstracts away or doesn't expose well.
The middle tier — where it gets interesting
The cases where either could work:
- Music streaming apps
- Podcast apps
- Banking apps
- Note-taking apps
- Productivity tools
- Travel booking
- Many consumer SaaS
For these, decision factors are:
- Team composition. Five React devs and zero Swift devs? RN. Two native iOS devs and a part-time Android dev? Probably native.
- Shared web codebase. Are you also shipping a web app with the same business logic? React Native with React Native Web is the most direct path to shared code. Native + web means duplication.
- iteration speed. Are you in early product-market-fit mode where you'll ship 20 versions in 6 months? React Native cuts iteration time roughly in half — and the New Architecture closed most of the performance gap that made this trade-off harder in 2021.
- Deep integration with platform features. Are you using share extensions, widgets, deeplinked actions, App Clips, Push notifications with rich custom UI? Each one of those has RN libraries but the integration story is bumpier than native.
The performance question, honestly
For most apps the perf gap is invisible. For some, it's real.
Where RN matches native: scrolling lists (with FlashList or Legend List), animations (Reanimated on UI thread), network-bound screens, image rendering, navigation transitions. All comparable.
Where native still wins: sustained 120Hz UI work, heavy compute on every frame (think Photoshop for mobile), real-time video processing, background tasks that need to run for hours.
We measured a recent customer app: cold start 850ms RN, 720ms native iOS. Below the perception threshold for most users.
// FlashList — the perf path for long lists in RN
import { FlashList } from "@shopify/flash-list";
<FlashList
data={messages}
estimatedItemSize={64}
renderItem={({ item }) => <MessageRow message={item} />}
keyExtractor={(item) => item.id}
// The bit that closes the gap with UICollectionView
recycleItems
/>Expo vs bare React Native
Use Expo. The 2021-era "you'll outgrow Expo" warning is no longer true. Expo's prebuild flow lets you drop down to native code when you need to, and EAS Build handles the otherwise-painful native build/sign/upload pipeline.
The only reason to bare-RN in 2026 is if you have very unusual native dependencies that Expo doesn't support yet. For 95% of apps, that doesn't apply.
pnpm create expo-app my-app --template
cd my-app
pnpm expo prebuild # generates ios/ and android/ when needed
pnpm expo run:ios # runs on simulatorState management
Stop using Redux for new RN apps. The defaults that work:
- TanStack Query for server state (the only thing most apps actually need)
- Zustand or Jotai for occasional client state (sub-feature scoped)
- React Context for app-level concerns (theme, auth)
Most RN apps do not have enough "client state" to justify Redux. Server data plus per-screen local state covers 80% of needs.
Cost framework
A rough budget comparison for a six-month build:
| Build | Senior engineering months | Outcome | |---|---|---| | React Native single dev | 5-6 | iOS + Android shipped | | Native iOS only | 4-5 | iOS shipped, no Android | | Native iOS + Android | 8-12 | Both shipped, separate teams | | Hybrid (RN core + native modules) | 6-8 | Both shipped, complexity tax |
React Native single-dev for both platforms is roughly half the engineering cost of native both-platforms. The trade-off is in the deep-integration bumpiness.
The hybrid pattern
Some of the most successful RN apps are hybrids — RN for screens, native modules for performance-critical surfaces. Discord did this for years. Instagram does it too. The pattern works:
- RN for ~80% of the app — feeds, settings, forms, lists
- Native modules for ~20% — camera, video processing, complex animations
Don't reach for the hybrid pattern on day one. Reach for it when you've measured a specific bottleneck.
The App Store side
Both RN and native ship to the App Store the same way. RN-shipped apps are not flagged or downgraded by App Review in 2026 (this was briefly an issue around 2018; not anymore). However, the App Store still rejects apps for reasons unrelated to RN — covered in our mobile app store rejection checklist.
OTA updates — RN's secret weapon
RN apps can update their JS bundle without going through App Review using Expo Updates or CodePush. Push a bug fix in 5 minutes instead of 24-72 hours.
Two caveats:
- App Store rules say OTA updates can't change "functionality or features." Bug fixes and content changes are fine. Adding new screens you couldn't have shipped at build time — grey area.
- Don't make OTA your primary release vehicle. Use it for hotfixes. The full release should still go through App Review for the metadata change.
Building a mobile app?
We've shipped React Native and native iOS/Android for B2B SaaS, marketplaces, content apps, and consumer products.
FAQ
Is Flutter a better choice than React Native?
Flutter is a good runtime. It loses to React Native on hiring (React talent is more common than Dart talent) and on web code reuse (React Native Web is mature, Flutter Web is not). For most teams, RN wins on those alone.
Can I have one developer ship both iOS and Android?
With React Native, yes — that's the entire pitch. With native, you can also have one developer ship both using Kotlin Multiplatform Mobile (KMM) for shared logic, but separate UI per platform. KMM is excellent if you have strong Kotlin people.
What about Capacitor / Ionic?
Capacitor is fine for apps that are basically a web view. If you're shipping a mobile-first PWA-equivalent, it works. For anything more native-feeling than that, RN is the better choice.
Should I use React Native Web?
Yes if you're also shipping a web app and want shared code. Be aware: RN Web is workable but not as polished as a real React + Tailwind web app. For a marketing site or a public-facing web product, build it as a Next.js app and share only the business logic with RN.
How long does an MVP take in React Native?
A typical first-version mobile MVP at YAEL is 8-12 weeks for a single platform, 10-14 weeks for both. Less if the scope is genuinely small.
What's the deal with React Native's New Architecture?
It replaces the old async bridge with a JS Interface (JSI) and a new rendering pipeline (Fabric). The result is synchronous-feeling JS-to-native calls and faster startup. It's the default for new projects and worth migrating to on existing ones.
Do I need to know Swift / Kotlin to ship React Native?
Helpful but not required. You can ship a full RN app without writing native code. You'll occasionally need to read a native lib to debug an issue or write a small custom module. A weekend of Swift tutorials is enough background.
What about Vision OS / Apple Watch / TV?
Apple's sub-platforms have varying RN support. Vision OS is early. WatchOS doesn't really fit RN's model — write a small companion native app. TV is supported by RN-TV. For most teams these are post-MVP concerns.