Native vs React Native: A Technical Decision Guide
Native vs React Native comes down to one trade: native development (Swift for iOS, Kotlin for Android) gives you the deepest platform access and the most control, while React Native gives you one codebase that still renders real native UI on both platforms. For most product apps in 2026, React Native delivers native-quality results at lower cost. For apps built around heavy graphics, AR or deep system extensions, fully native still wins.
I work on both sides of this line. I maintain react-native-compressor, an open-source library with native iOS and Android code under a JavaScript API, and I have worked on large production apps such as The Entertainer and Zirtue. This guide compares the two approaches at the level of rendering, threads, APIs and team structure, then gives you a scored matrix and real scenarios so you can decide for your product.
Planning a mobile app or stuck on one? Message me on WhatsApp or see how I work with app teams.
What "native" and "React Native" mean in 2026
Native means writing each platform's app in its own language and UI toolkit: Swift with SwiftUI or UIKit on iOS, Kotlin with Jetpack Compose or Android Views on Android. Two codebases, two teams or two skill sets, full access to everything the operating system offers on the day Apple or Google releases it.
React Native means writing the app mostly in TypeScript and React. The framework does not draw pixels itself and does not wrap a web view. Your components map to real platform views: a <Text> becomes a native text view, a <ScrollView> becomes a native scroll view. Platform-specific code lives in native modules written in Swift, Objective-C, Kotlin, Java or C++.
That distinction matters because "cross platform vs native" debates often lump React Native together with web-view hybrids from a decade ago. They are different technologies with very different results.
Rendering and the New Architecture
The old React Native design passed serialized messages between JavaScript and native code over an asynchronous bridge. That bridge was the source of most historical complaints: laggy gestures, slow startup when many modules loaded, and layout that could not be measured synchronously.
The New Architecture replaced it and is now the default for new projects, with recent releases dropping the legacy path entirely. It has four main parts:
- JSI (JavaScript Interface): a C++ layer that lets JavaScript hold direct references to native objects and call them synchronously, with no serialization step.
- Fabric: the new renderer, written in C++ and shared across platforms. It supports synchronous layout reads and React's concurrent features, so urgent updates such as typing can interrupt less urgent rendering.
- TurboModules: native modules loaded lazily and called through JSI, with typed interfaces generated from a spec, which reduces startup cost and type mismatch bugs.
- Hermes: the JavaScript engine tuned for mobile, which compiles to bytecode ahead of time to reduce startup time and memory.
Native apps, by comparison, have no translation layer at all. SwiftUI and Compose render directly through the platform's own pipeline. I cover the migration details and library compatibility in React Native New Architecture in 2026; the short version is that the architectural gap between React Native and native is much smaller than it was a few years ago.
Performance: where the difference still shows
I will not quote benchmark numbers here, because results depend heavily on the device, the app and how well each version is written. What I can describe is where the differences reliably appear in production profiling.
| Area | Native | React Native (New Architecture) |
|---|---|---|
| Cold start | Fastest baseline | Slightly slower because the JavaScript runtime must start; Hermes bytecode narrows the gap |
| Typical screens (forms, lists, feeds) | Smooth | Indistinguishable to users when built well |
| Long, complex lists | Smooth with platform list views | Smooth with virtualized lists such as FlashList and careful re-render control |
| Gesture-driven animation | Runs on the UI thread natively | Smooth when animations run on the UI thread via Reanimated worklets; janky if driven from JavaScript |
| Heavy real-time graphics, AR, 3D | Best: direct Metal, Vulkan, ARKit, ARCore access | Possible through native views or C++, but you end up writing native code anyway |
| App size | Smallest | Larger, because the runtime and JavaScript bundle ship with the app |
| Memory | Lowest baseline | Somewhat higher baseline due to the JavaScript runtime |
The honest summary: for business, commerce, fintech and content apps, a well-built React Native app performs like a native one, and a poorly built app of either kind performs badly. Most React Native performance problems I am hired to fix come from unnecessary re-renders, oversized images and heavy work on the JavaScript thread, not from the framework itself. My React Native performance optimization guide covers those fixes.
Access to platform APIs
This is where native development has a structural advantage, and where it matters most to be precise.
Day-one APIs. When Apple or Google ships a new API at WWDC or Google I/O, native developers can use it in the beta SDK immediately. In React Native you either wait for a community or Expo module, or write a small native module yourself. For most apps a delay of weeks is irrelevant. For apps whose marketing depends on launching with the new OS feature, it matters.
Native modules close most gaps. Anything a native app can call, React Native can call through a native module. With TurboModules or the Expo Modules API, wrapping an SDK such as a payment terminal, a Bluetooth device or a camera pipeline is routine work for a developer who knows both sides. react-native-compressor is exactly that: video and image compression implemented natively on each platform and exposed as one JavaScript function.
Extensions are the real boundary. iOS home screen widgets are written with WidgetKit and SwiftUI. Apple Watch apps, App Clips, Live Activities, Siri intents, Android widgets and Wear OS apps all run as separate native targets. A React Native app can include them, but those parts are native code regardless of what the main app uses.
React Native vs Swift and React Native vs Kotlin
When founders ask about React Native vs Swift, the real question is usually "do we need an iOS-only app, done the Apple way?" Swift with SwiftUI makes sense if iOS is your only platform for the foreseeable future, you rely on Apple-specific frameworks (HealthKit-heavy features, watchOS, CarPlay, visionOS), or you want the smallest, most idiomatic app possible. If you plan an Android version within a year, React Native usually saves you building the app twice.
React Native vs Kotlin follows the same logic for Android. Kotlin with Jetpack Compose is the right choice for Android-only products, deep hardware integration (custom devices, kiosks, point of sale) or Android Automotive. A related option is Kotlin Multiplatform, which shares business logic between platforms while keeping native UI on each; it suits teams that already have strong native developers on both sides.
If you do go fully native, I offer native iOS app development and native Android development as well as React Native.
Team size, cost and maintenance
The biggest difference is often organisational, not technical.
| Factor | Two native apps | One React Native app |
|---|---|---|
| Codebases | Two (Swift, Kotlin) | One shared codebase, with small native folders |
| Minimum team | One iOS plus one Android developer, often more | One or two React Native developers with native knowledge |
| Feature parity | Needs coordination; platforms drift apart | Mostly automatic |
| Build cost | Often approaching double a single cross-platform build | Baseline |
| Hiring pool | Specialised, smaller per platform | Large, drawn from the React and TypeScript community |
| Shared code with web | None | Business logic, types and validation can be shared with a React or Next.js web app |
| Release fixes | Store review for every fix | JavaScript fixes can ship over the air, within store policies |
Maintenance differs too. Native apps need yearly updates for new iOS and Android versions and SDK requirements. React Native apps need those plus periodic framework upgrades and dependency updates, which can be painful if you skip versions for a long time. A good rule is to upgrade React Native at least once or twice a year and to prefer well-maintained libraries. The extra upgrade work is usually far smaller than maintaining two full codebases.
Scored decision matrix
The scores below are my professional judgment on a 1 to 5 scale (5 is best) for a typical product startup or scale-up. Adjust the weights to your situation.
| Criterion | Weight | Native (Swift + Kotlin) | React Native |
|---|---|---|---|
| Time to market on both platforms | 3 | 2 | 5 |
| Build and maintenance cost | 3 | 2 | 5 |
| Performance for typical product UI | 2 | 5 | 4 |
| Heavy graphics, AR, 3D | 1 | 5 | 2 |
| Day-one OS feature access | 1 | 5 | 3 |
| Widgets, watch and system extensions | 1 | 5 | 3 |
| Hiring availability | 2 | 3 | 5 |
| Code sharing with web | 1 | 1 | 5 |
| Weighted total (out of 70) | 44 | 61 |
If you raise the weight on graphics, OS features and extensions, native pulls ahead quickly. That is the point of the matrix: it shows which assumptions your decision actually depends on.
Real scenarios where native wins
- AR, 3D and real-time graphics: furniture placement, games, camera filters with custom shaders.
- Watch-first or widget-first products: fitness trackers with a strong Apple Watch app, glanceable widgets as the main experience.
- Single-platform products with deep OS integration: a CarPlay navigation app, an Android launcher, a kiosk or point-of-sale device.
- Very size-sensitive markets: apps that must stay as small as possible for low-storage devices or instant install.
- Teams that already have strong native engineers on both platforms and no plans for a web product.
Real scenarios where React Native wins
- Most B2C apps: commerce, delivery, travel, booking, loyalty, content and social. Large consumer apps in loyalty, retail and payments show this category works at scale.
- Fintech apps: account management, payments and onboarding flows, with native SDKs (for example identity verification or bank linking) wrapped as modules. My work on Zirtue with Plaid and Dwolla fits this pattern.
- Startups that need iOS and Android at launch with one small team.
- Companies with a React web product that want shared logic, design tokens and developers who move between web and mobile.
- Apps that change weekly, where over-the-air updates for JavaScript changes shorten the feedback loop.
The hybrid option: native modules and brownfield
You do not have to choose one approach for the entire app.
React Native with native modules. The most common hybrid. The app is React Native, and specific features (a camera pipeline, a widget, a watch companion, an AR screen) are written natively and connected through native modules or native views. You get cross-platform speed for most screens and native depth where it counts.
Brownfield React Native. An existing native app embeds React Native for selected screens or flows. Large companies use this to move faster on frequently changing areas such as onboarding, checkout or promotions without rewriting a mature native app. It requires care with navigation, shared state and build setup, but it is a well-trodden path.
Native app with shared logic. Kotlin Multiplatform or a shared C++ core keeps UI native while sharing business rules. This suits teams committed to native UI.
My general advice on cross-platform mobile app development is to start with React Native plus native modules unless one of the native-wins scenarios is central to your product.
FAQ
Is React Native as fast as native?
For typical product apps, a well-built React Native app feels the same as a native one to users. Native still has the edge in cold start, memory, app size and heavy graphics.
Is React Native better than Swift?
Neither is better in general. Swift is better for iOS-only products with deep Apple integration. React Native is better when you need iOS and Android from one team and codebase.
Can React Native use native features like widgets and Apple Watch?
Yes, but those parts are written natively. A React Native app can ship with a WidgetKit widget or a watchOS companion, and share data with them, while the main app stays in React Native.
Should I rewrite my native app in React Native?
Usually not all at once. If you want faster delivery on both platforms, consider a brownfield approach: build new or frequently changing flows in React Native inside the existing app and migrate gradually.
Make the call with someone who builds both
The right answer depends on your product, your team and your next two years, not on framework loyalty. I am Numan, an independent full-stack developer: I build React Native apps, write the native iOS and Android modules underneath them, and work across web and AI as well. If you want an honest recommendation for your app, or someone to build it, hire a React Native developer who will tell you when native is the better choice.