Most iOS and Android MVPs should use React Native. One TypeScript codebase ships both apps, shares logic with a web product, and gets to the stores with one team. Choose native Swift and Kotlin when the product depends on deep platform features, heavy real-time graphics, or launches on one platform only.
The question usually arrives as "which is better". That is the wrong question. Both produce apps that pass App Store and Google Play review, and both run large production apps today. The useful question is which one fits the first twelve months of your product, your team and your budget.
Here is how we decide it with founders before any code is written.
What changed in React Native recently?
React Native's New Architecture became the default in version 0.76 (October 2024), and from 0.82 it runs entirely on it. That removed the old asynchronous bridge between JavaScript and native code. As of October 2026 the current release is 0.88. Older arguments about bridge performance describe a version you would not start on today.
The New Architecture lets JavaScript call native modules directly and lets React render concurrently. In practice, that means fewer of the jank and startup issues people remember from older React Native apps. The React Native team also recommends starting new apps with a framework, and Expo is the one most teams use. Expo handles builds, over-the-air updates and native configuration, and you can still write custom native modules when you need them.
When is React Native the better choice for an MVP?
React Native is the better choice when you need iOS and Android at launch, your product also has a web app or one is planned, your team writes TypeScript or React, and the app is mostly screens, forms, lists, media and API calls rather than custom graphics. That describes most marketplace, SaaS companion, booking, fintech front end and content apps.
The advantage compounds after launch. One codebase means one feature is built once, tested once and released to both stores. Business logic, validation and API types can be shared with a Next.js web app. Over-the-air updates let you ship JavaScript fixes without waiting for store review, within the store rules for what an update may change.
When should you build native instead?
Build native when the core of the product is a platform capability: advanced camera or AR pipelines, Bluetooth hardware integration as the main feature, audio processing, widgets and watch apps as the primary surface, or real-time 3D. Native also wins when you launch on one platform only and have, or will hire, a dedicated Swift or Kotlin team.
React Native can reach all of these through native modules. The question is how much of your app would live in those modules. If the honest answer is "most of it", you are writing a native app with extra steps, and two native codebases is the more direct route.
How do React Native and native compare for an MVP?
For a typical two-platform MVP, React Native needs one team and one codebase, shares code with the web, and ships fixes faster. Native gives first access to new platform APIs and the most control over performance and platform conventions, at the cost of two codebases, two release tracks and two hiring pipelines.
Question | React Native | Native Swift and Kotlin |
|---|---|---|
Codebases for iOS and Android | One, in TypeScript | Two, in Swift and Kotlin |
Code shared with a web app | Logic, types and validation | None by default |
New platform APIs on release day | Through community or custom modules, sometimes later | Immediate |
Heavy graphics, AR, real-time audio | Possible with native modules | Strongest |
Shipping a fix without store review | Over-the-air updates for JavaScript changes, within store rules | Store release required |
Team you need to hire | React and TypeScript engineers, plus native skill for modules | iOS and Android specialists |
Platform look and feel | Native components, needs design care per platform | Native by default |
What are the five questions that settle the decision?
Ask whether you need both platforms at launch, whether a web product shares the logic, what share of features depend on platform APIs, which skills your team has or can hire, and how often you will ship. Two or more answers pointing the same way usually decide it.
- Do you need iOS and Android in the first release? If yes, React Native removes a second build. If you launch on iOS only to test demand, native Swift is a reasonable start.
- Is there a web app? Shared TypeScript types and logic save real time with React Native.
- What share of the roadmap depends on platform capabilities? List the features. Count the ones that need camera, sensors, background processing or system extensions. A short list favors React Native.
- Who will maintain it? A React team can own a React Native app. Two native apps need two specialists, and a single departure stalls one platform.
- How fast will you iterate? Weekly releases favor one codebase and over-the-air updates.
What does a production React Native setup include?
A production setup uses Expo with EAS for builds and updates, TypeScript in strict mode, Reanimated for animation off the JavaScript thread, crash reporting and analytics from the first sprint, end-to-end tests on real devices, and a release process with staged rollouts on both stores.
The parts teams skip and regret: a clear rule for what may ship over the air versus through the stores, and analytics events defined before launch so the first month of data is usable. We describe how we build in React Native on our React Native page.
What does the decision cost to reverse?
Moving from React Native to native later means rewriting the app per platform, though APIs, designs and product learning carry over. Moving from two native apps to React Native is a rewrite too. Neither path is cheap, so decide on the twelve-month roadmap, not on the first screen.
Teams often fear lock-in that does not exist. React Native apps can add native screens and modules over time, so a gradual move toward native in one area is possible without a full rewrite. The expensive mistake is not the framework. It is choosing before writing down the feature list.
Deciding how to build your app? Book a scoping call and we will work through these five questions with your feature list. Our mobile app engineering team builds in React Native and native, so the recommendation follows your product, not our preference. You are never handed to a junior or a subcontractor. Your product is yours, completely.
Sources
- React Native 0.76, "New Architecture by default", React Native blog, 23 October 2024: https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here
- React Native blog (release history, including 0.82 and 0.88): https://reactnative.dev/blog
- React Native docs, "Get started with React Native" (framework recommendation): https://reactnative.dev/docs/environment-setup
- Expo documentation: https://docs.expo.dev
- Apple App Store Review Guidelines (rules on code downloaded after review): https://developer.apple.com/app-store/review/guidelines/
Questions this raises
Is React Native good for production apps in 2026?
Yes. The New Architecture has been the default since version 0.76, and the current release in October 2026 is 0.88. Production apps from Meta and many others run on it. Quality depends far more on the team's discipline in testing, performance work and releases than on the framework.
Is React Native cheaper than native?
For a two-platform app, usually yes, because one team builds and maintains one codebase. The saving shrinks if most features need custom native modules, because that work still has to be done per platform by people with native skills.
Should I use Expo or bare React Native?
Start with Expo unless you already know you need something it cannot support. The React Native team recommends a framework for new apps. Expo supports custom native code through development builds and config plugins, so choosing it rarely blocks native work later.
Can I switch from React Native to native later?
Yes, but it is a rewrite of the app layer per platform. Your backend, API, designs and product learning carry over. Many teams instead add native modules or screens where they need them and keep React Native for the rest.
Does React Native feel native to users?
It renders real platform components, not a web view, so scrolling, text input and navigation behave like native apps. It still needs design care for platform conventions, such as navigation patterns on iOS and Android, which differ.