Most teams still frame react native vs native as a performance question. For ordinary app screens that question is largely settled as of 2026, and the questions that decide budgets are different: which features live outside the app’s main screens, who will own the code after launch, and how many release trains you can afford to run.
This post is the practical version of that decision for teams already leaning towards React Native. If you have not yet decided between one codebase and two, start with our broader native vs cross platform guide. If React Native is the likely answer, our React Native app development company page explains how we run those projects. Here we stay on the comparison itself: React Native on the New Architecture against separate Swift and Kotlin apps.
By native we mean SwiftUI (or UIKit) on iOS and Jetpack Compose (or Views) on Android, each in its own repository or module, each with its own build and release.
What changed in React Native, and why old comparisons are out of date
Most comparison articles you will find still describe the asynchronous bridge: JavaScript serialising messages to native code and waiting for replies. That model is gone. React Native 0.76 made the New Architecture the default in October 2024, the Legacy Architecture was frozen in 0.80, and according to the React Native 0.82 release post (October 2025), React Native now runs entirely on the New Architecture. As of October 2026 the current release is 0.88.
For the comparison, this matters in two ways. First, JavaScript now calls native code directly through JSI, so the classic bottleneck of chatty traffic across a bridge no longer applies. Second, an app that has not made the move is now on a frozen, unmaintained code path. If you are weighing React Native for an existing app that is still on the old architecture, the comparison that matters is the cost of upgrading against the cost of rebuilding natively. Our React Native New Architecture migration guide covers the full version timeline and the audit step by step.
Performance: where users can and cannot tell the difference
On lists, forms, checkout, profile and settings screens, a React Native app built with care is not distinguishable from a native one. React Native renders real platform views, so text input, scrolling physics and accessibility behave the way each OS expects. The gap shows up in a narrower set of places, and you can usually predict them from the feature list.
Work that runs on the JavaScript thread
Your business logic runs in JavaScript on its own thread. Parsing a very large API response, sorting thousands of records on the device or running crypto in JavaScript competes with rendering. Native code does the same work on background threads with less ceremony. In React Native the fix is to move that work into a native module or a worker, which is normal, but it is native code you now maintain.
Gesture-driven animation
Animations that follow a finger (bottom sheets, swipe cards, pinch-to-zoom) need to run on the UI thread. Reanimated and Gesture Handler do that well, but it is a discipline the team must keep. Native toolkits do it by default.
Cold start on budget Android phones
A React Native app loads a JavaScript runtime and bundle before the first screen. Hermes precompiles the bundle to bytecode, which helps a lot, but a native app with no runtime still starts with less work. If your users are on low-end Android devices, measure cold start on one of those devices before you commit, not on a new iPhone.
Camera frames, audio and real-time graphics
Processing every camera frame, mixing audio or rendering 3D scenes are native jobs in any cross-platform app. React Native can host them, but the core of the feature is written in Swift and Kotlin either way.
Where native still wins: features that live outside your React screens
The strongest case for native is not speed. It is the growing list of OS features that run outside your app’s main process or UI, where the React Native runtime is not present.
- Home-screen and lock-screen widgets. iOS widgets are WidgetKit extensions written in SwiftUI. Android widgets are built with Jetpack Glance or RemoteViews. A React Native app can ship them, but the widget itself is native code that reads shared data.
- Apple Watch. A watch app is a separate target in Swift and SwiftUI whatever the phone app uses. Complications are built with WidgetKit, because Apple deprecated ClockKit complications from watchOS 10. Our Apple Watch app development company page explains what that work involves.
- Live Activities and Dynamic Island. Built with ActivityKit and SwiftUI views, again outside the React tree.
- AR. ARKit and RealityKit on iOS and ARCore on Android are native frameworks. Libraries that wrap them exist, but serious AR products end up mostly native; our augmented reality app development company page explains why.
- New Apple and Google APIs. Apple’s Foundation Models framework, announced in June 2025, gives on-device model access through Swift. New APIs like this arrive in Swift and Kotlin first, and in React Native when someone writes and maintains a module.
None of these rules React Native out. Each one adds a native island to a React Native codebase. Two or three islands are fine and common. When the islands become the product (a watch-first fitness app, an AR measuring tool, a widget-led habit tracker), you are paying for a JavaScript layer that carries little of the value.
React Native vs native: decision table
How the two options compare on the factors that usually decide the budget. React Native here means the New Architecture, with Expo as the framework, which the React Native team has recommended for new apps since June 2024.
| Factor | React Native (New Architecture + Expo) | Native (Swift/SwiftUI + Kotlin/Compose) |
|---|---|---|
| Codebases for the app UI and logic | One TypeScript codebase plus small native modules | Two, one per platform |
| Standard screens (lists, forms, checkout) | Indistinguishable when built well | Reference quality |
| Heavy on-device computation | Move it to native modules or workers | Background threads by default |
| Widgets, watch, Live Activities, AR | Native extensions alongside the app | Same language and tooling as the app |
| New OS APIs | When a module exists or you write one | Available with the SDK |
| Shipping fixes | Over-the-air JavaScript updates within store rules | Every change goes through store review |
| Upgrade cadence | Roughly one minor release every two months, plus yearly store requirements | Yearly Xcode and Android target API changes |
| Hiring | Large TypeScript and React pool; mobile depth varies | Two specialist pools: Swift and Kotlin |
| Sharing with a web app | Types, API clients and logic shared with React web | Little or none |
| Client build cost | Baseline | Roughly double, per Clutch |
Release facts from the React Native blog. Cost row reflects Clutch’s finding that separate native iOS and Android apps roughly double cost compared with one cross-platform build.
List every native island in your first two releases (widget, watch app, Live Activity, AR view, custom SDK wrapper) and write a named owner next to each one: the person who will maintain its Swift or Kotlin code after launch. If every island has an owner on the team, React Native holds up well. If the islands outnumber the people who can maintain them, or one island is the product, price native before deciding.
Team shape: who you need for each option
The comparison that decides most projects is the team, not the runtime. Here is what each option needs to ship and maintain a typical two-platform business app.
React Native
Two or three TypeScript developers who know React and mobile specifics (navigation, permissions, push, offline storage), plus at least one person who is comfortable inside Xcode and Android Studio. That person handles signing, native modules, widget extensions and the occasional build failure that has nothing to do with JavaScript. A QA engineer tests on real iOS and Android devices. If you already run React on the web, your web developers can review mobile pull requests and share types and API clients, which is the biggest hidden benefit of the stack.
Native
At least one iOS developer and one Android developer, and realistically two of each for steady velocity on a growing product. Every feature is designed once, built twice and tested twice, so sprint plans need someone who checks both builds against the same acceptance criteria before a release goes out. The benefit is that platform knowledge sits inside the team: a new Apple or Google API is a ticket, not a search for a maintained module.
When screening React Native candidates, ask them to walk through the last store release they shipped: signing, a rejected build, a native crash they had to debug. Strong React developers without that history are a common mismatch. Our hire React Native developers page explains how we screen for it. On the native side, the risk is the opposite: strong platform engineers with no shared plan, so the two apps drift apart within a year.
Want a second opinion on your feature list?
Send us your feature list and target devices. We reply within one business day, mark which features need native work and say whether React Native or native fits better.
Cost: where the money goes in each option
Clutch’s app development cost research says separate native iOS and Android apps roughly double the cost of one cross-platform build. That applies to the app itself; design, backend and project management are shared either way. The React Native line items that estimates tend to skip are these:
- Native islands. Every widget, watch app or custom SDK wrapper is Swift or Kotlin work, priced like native work.
- Upgrade rhythm. With roughly one minor release every two months, falling behind is easy. Budget a small, regular upgrade task each quarter instead of a large rescue every two years.
- Library risk. Each third-party package must keep pace with React Native releases. Fewer, well-maintained packages cost less over three years than a long list of small ones.
Native has different hidden costs: keeping two apps in step, two sets of UI tests, and two release trains that drift unless someone actively manages them. Over a three-year product life, those coordination costs can rival the build saving.
For a ballpark on your own scope, the app cost calculator lets you compare one codebase with two. The other drivers are covered in how much does it cost to build an app.
The middle path: React Native inside a native app, or native inside React Native
The choice is not always one or the other. Two hybrid setups are common and sensible.
React Native screens inside a native app
If you already have native iOS and Android apps, you can add React Native for specific flows (a new onboarding, a settings area, a content section) without rewriting the rest. This is often called brownfield React Native. It suits companies with a React web team that wants to contribute to mobile, but it adds a second build system to each app, so do it for a meaningful area, not a single screen.
Native modules and extensions inside a React Native app
This is the normal shape of a mature React Native product: a TypeScript app with a handful of native modules (written with the Expo Modules API or as TurboModules) and native extensions for widgets or a watch app. Keep each native piece small, documented and owned by a named person, because it is where upgrades break first.
If you want UI written natively but logic shared, Kotlin Multiplatform is a different answer to the same question. Our Kotlin Multiplatform vs Flutter post explains how it works.
Questions to settle before you choose
Answer these in writing during discovery. Most of them have a clear answer for React Native or native.
- Which features in the first two releases run outside the main app UI (widgets, watch, Live Activities, AR, background audio)?
- Does any core feature process camera frames, audio or 3D graphics in real time?
- Do you run a React web app whose types, API clients or logic the mobile app could share?
- Who will own the app after launch, and what language do they already write?
- How often will you need to ship fixes, and would over-the-air JavaScript updates help your support team?
- Which third-party SDKs (payments, KYC, analytics, a partner’s SDK) are mandatory, and does each have a maintained React Native package?
- What is the lowest-spec Android device your users actually own?
- Can you fund two platform specialists for the life of the product, not just the build?
React Native vs native FAQs
Is React Native slower than native?
Not on standard screens. React Native renders platform views and, since 0.82, runs entirely on the New Architecture with direct calls between JavaScript and native code. The differences appear in heavy on-device computation, gesture-driven animation, cold start on budget Android phones and real-time camera or audio work. Each has a known fix, usually a native module, so plan for them from the feature list.
Can a React Native app have widgets and an Apple Watch app?
Yes, but those parts are native. iOS widgets are WidgetKit extensions in SwiftUI, Android widgets use Glance or RemoteViews, and a watch app is a Swift target. They share data with the React Native app through app groups or shared storage. Budget them as native work, priced like any Swift or Kotlin feature.
Is it cheaper to build with React Native than native?
Usually, for the app build, because one TypeScript codebase replaces two. The saving shrinks with every native island, since widgets, watch apps and custom SDK wrappers are priced like Swift or Kotlin work, and with the upgrade task React Native needs every few months. Design, backend and project management cost about the same either way, so compare total budgets, not just app build quotes.
Should we move our React Native app to native?
Only with a clear reason. Good reasons are a product that has become mostly native features, a team that is now mainly Swift and Kotlin, or an old codebase where upgrading costs close to a rebuild. If the app is only behind on versions, upgrading to the New Architecture is usually cheaper than rewriting both platforms.
Do we need Expo, or can we use bare React Native?
The React Native team has recommended a framework, and specifically Expo, for new apps since June 2024. Expo still lets you add custom native code through config plugins and the Expo Modules API, so it rarely blocks native work. Bare projects suit apps embedded in an existing native host app or with very unusual build needs.
Get a React Native or native recommendation in writing
Share your feature list, target devices and team setup. We reply within one business day, mark every native island and recommend a stack with reasons. See how our React Native app development company team works.