React Native vs native development: how to choose in 2026

What each option actually is

Native development means two apps: one for iOS, usually in Swift and SwiftUI, and one for Android, usually in Kotlin and Jetpack Compose. Two codebases, often two teams, each with direct access to everything its platform offers.

React Native means one codebase in TypeScript that renders real native UI components on both platforms. It is not a website in a wrapper: buttons, lists and navigation are the platform's own. Since React Native 0.76 the New Architecture is enabled by default: it replaced the old asynchronous bridge between JavaScript and native code, which used to be the main performance bottleneck.

Expo is the framework the React Native documentation itself recommends for new apps. It handles builds in the cloud, store submission, over-the-air updates and a large set of ready native modules for the camera, notifications, location, files and so on. When a module doesn't exist, you write it in Swift and Kotlin inside the same project.

So the real choice isn't "native or fake". It is one codebase with native modules where needed, or two fully native codebases.

The short answer

For most business apps, React Native with Expo. That covers accounts and profiles, catalogues, bookings, payments, chats, push notifications, personal dashboards, forms that work offline and companion apps for web platforms.

Native is worth it when the app is the device: heavy graphics, deep hardware work, real-time media processing, or features that must use a new iOS or Android capability on the day it ships.

Side by side

Where React Native wins

One feature, written once. A booking flow, a payment screen or a profile form is designed, built and tested once for both platforms. Design, backend and store work still happen for both, so it isn't half the cost of two native apps, but the difference is real, and it grows with every release after the first.

Both platforms ship together. With two native teams, one platform can lag the other by a sprint or two, and the product starts to differ in small ways. One codebase removes that.

Fast fixes. Over-the-air updates let you ship a fix to JavaScript and assets without waiting for a store review, within the stores' rules. That covers a wrong label, a broken validation or a layout bug on one screen size. Anything that touches native code still goes through review.

Shared language with the web. If your web platform and admin are written in TypeScript, the same team can work across the app, the backend and the admin, sharing types and validation rules. The app and the web platform also share one backend, so an order created on a phone is the same record the manager sees in the browser.

Where native wins

Pay for native when one of these is central to the product, not a side feature:

• Heavy graphics, 3D, AR or games, where every frame matters.
• Deep hardware work: continuous Bluetooth LE sessions with devices, precise background location, sensors at high frequency.
• Real-time audio or video processing on the device.
• Platform features on day one, if your product's value depends on adopting each new iOS or Android capability the week it ships.
• A strong native team you already have, and no web team to share code with.

If the list above describes one screen of your app rather than the whole app, you probably don't need two native codebases. You need a native module.

Three myths worth dropping

"Cross-platform apps feel like websites." That was true of apps built as a web page inside a wrapper. React Native renders the platform's own components, so scrolling, gestures and system dialogs behave the way users expect on each platform.

"You can't reach the hardware." You can, through Expo's modules or your own native code. The real question is how much of the app needs that access, and whether it's worth a second codebase.

"Native is more future-proof." Both age. Native APIs get deprecated, design languages change, and two codebases need updating instead of one. What keeps an app healthy is regular maintenance, whichever stack it uses.

The middle path: React Native with native parts

Most of our apps are written in React Native with Expo. When a feature needs native code, such as background location, Bluetooth or heavy media, we add native modules for that part and keep the rest in the shared codebase.

The same applies to things that live outside the app's main screen. Home-screen widgets, Live Activities on iOS and watch apps are built with native tools on each platform, and they can sit inside a React Native project as separate native targets. You pay native prices only for the parts that need native code.

A word on Flutter and others

React Native isn't the only cross-platform option. Flutter, with its own rendering engine and the Dart language, is a mature choice too, and Kotlin Multiplatform lets teams share business logic while keeping native UI. All three are reasonable. The deciding factors are usually the team you have and the stack around the app. A team that already works in TypeScript on the web gets more from React Native; a team with Kotlin skills may look at Kotlin Multiplatform.

There is also an option without an app at all. If your users don't need the stores, deep device access or reliable background work, a progressive web app installed from the browser may be enough. We compare the two in PWA vs native app.

An example: LUMEN

LUMEN is a platform for fractional investment in real-world assets: real estate, land or a business. Every share comes with an NFT certificate of ownership on chain, monthly income payouts and the option to resell it on an internal OTC marketplace.

Investors use a mobile cabinet with their portfolio, income and wallet, and that investor app is built with Expo. The team runs assets, pools, KYC, payouts and risk on a web platform of about a hundred screens. The split is typical: the app stays focused, while the heavy logic, such as pools, payouts and settlements, runs on the backend under a risk engine. A financial product with a wallet and KYC runs on one Expo codebase for iOS and Android, because the hard parts live on the server.

How to decide for your app

Answer these, and be strict about "central" versus "nice to have":

1. What is the core loop of the app? If it is forms, lists, payments and notifications, React Native.
2. Does the core loop depend on hardware or graphics? If yes, look at native, or at least at native modules for that part.
3. Do you have a web platform? If it is in TypeScript, React Native lets one team cover both.
4. How often will you ship changes? Frequent small changes favour one codebase and over-the-air fixes.
5. Who will maintain it in two years? One codebase needs one set of skills. Two need two, and both have to stay in step.

Risks to plan for, whichever you choose

React Native:

• Framework and Expo SDK upgrades need regular attention; an app left alone for two years is harder to bring up to date.
• Third-party libraries sometimes lag behind new OS versions. Keep native dependencies few and well maintained.
• Debugging can cross layers, from JavaScript down to native code, which takes someone who knows both.

Native:

• Two codebases drift apart in behaviour and look unless someone actively keeps them aligned.
• Every feature is built, tested and reviewed twice.
• Hiring and keeping two specialised teams costs more than one.

Neither risk is a reason to avoid either option. They are reasons to ask a vendor how they handle them.

What this means for cost and timeline

One codebase usually costs noticeably less than two native apps and reaches the stores sooner, because most features are written once. How much less depends on how much of your app is shared UI and logic, and how much needs native work anyway. For orientation on the numbers, see how much it costs to build a mobile app and how long mobile app development takes. Our guide to Expo for business apps goes deeper into the tooling.

At EVA-X we recommend the approach at the team review, after reading your brief: React Native with Expo by default, native modules where a feature needs them, and fully native only when the app's core needs it. To see the modules, timeline and a fixed price for your app, describe it on the estimate, or read more about our mobile app development.