# React Native in 2026: when cross-platform mobile is the right call

*By Roberto Lazar, founder of Dock30 · Published 2026-06-20 · Updated 2026-07-25 · 7 min read*

A practical guide to choosing a mobile stack in 2026: where React Native 0.86 stands, what the New Architecture changed, and when to skip cross-platform.

React Native is the right call in 2026 when you already have a React or TypeScript team, you want one codebase serving iOS and Android with the large majority of your code shared, and your app runs on UI and data rather than heavy graphics or exotic hardware. Go native (Swift or Kotlin) when you need deep platform APIs or absolute peak performance. Pick Flutter when the product lives or dies on custom, animation-heavy UI and you accept writing Dart. For most other products, React Native with Expo is the pragmatic default: the current stable release is **0.86 (June 2026)**, it runs entirely on the New Architecture, and the old bridge that caused most of the historical jank no longer exists.

If your last serious look at React Native involved a laggy bridge and a maze of native build errors, it deserves a fresh one. We build mobile apps at Dock30 alongside the React and Next.js work we have shipped since 2021, and the gap between React Native's reputation and its current state is the widest of any tool we use. What follows is the decision process we walk clients through, including the cases where we point them away from React Native entirely.

## When each stack is the right call

| Stack | Pick it when | 2026 reality check |
|---|---|---|
| React Native | Your team writes React or TypeScript and you want maximum code reuse | 0.86 stable, New Architecture only, bridge gone |
| Flutter | Pixel-perfect custom UI, heavy animation, desktop and mobile from one codebase | Mature, but it means adopting Dart |
| Native (Swift, Kotlin) | Deep platform APIs, peak performance, AR, games | Two codebases, roughly double the build and maintenance cost |
| Expo | You want React Native without touching Xcode and Gradle configs | The officially recommended way to start any RN app |

One thing worth internalizing before anything else: Expo stopped being a lite version of React Native years ago. It is the [officially recommended framework](https://docs.expo.dev/) for production apps, and every React Native project we start begins there. You can still write native modules when you need them. You just stop paying the configuration tax on day one.

## What the New Architecture changed, and when the bridge actually died

React Native's biggest historical weakness was the bridge: an asynchronous, serialized message queue between JavaScript and native code. Touches, scroll events, and layout updates all crossed it as JSON, and under load that queue backed up. The New Architecture replaced it with JSI, a direct C++ interface that lets JavaScript call native methods synchronously, with a new renderer (Fabric) and module system (Turbo Modules) built on top.

The timeline matters if you are maintaining an older app:

- 0.76 (October 2024) made the New Architecture the default for new projects.
- 0.81, and Expo SDK 54 alongside it, were the last releases that could still run the Legacy Architecture.
- 0.82 (October 2025) [removed the ability to run on the old architecture](https://reactnative.dev/blog/2025/10/08/react-native-0.82). The opt-out flags stopped doing anything, while interop layers stayed in place so older libraries kept working.
- The leftover bridge code was then stripped out gradually, finishing around 0.85.
- 0.86 (released June 9, 2026) is the [current stable version](https://reactnative.dev/versions); 0.85 from April is still supported but no longer latest.

A precision point we see misquoted a lot: 0.82 did not delete the bridge in one commit. It made the New Architecture mandatory and kept compatibility layers so the ecosystem would not break overnight; the dead code came out over the following releases. The practical consequence is the same either way. Since 0.82, every React Native app ships on the New Architecture whether it opts in or not, and the popular-library ecosystem has followed. The compatibility anxiety that was justified in 2024 is not justified in 2026.

## Is it fast enough? Shopify's numbers say yes

The strongest public evidence comes from Shopify, which spent five years migrating all of its mobile apps to React Native and published the results: screen loads **under 500ms** and **over 99.9% crash-free sessions**, per [Shopify Engineering](https://shopify.engineering/five-years-of-react-native-at-shopify). Those are numbers most fully native teams would sign for.

They also match what we see at smaller scale. On the apps we have shipped, performance problems almost never trace back to React Native itself. They trace back to unvirtualized lists, chatty APIs, and images nobody resized. The framework stopped being the bottleneck; ordinary engineering discipline is the bottleneck, same as on the web.

## React Native vs Flutter in 2026

Both are good, and anyone telling you one of them is dying is selling something.

The adoption data is genuinely mixed. Statista-based figures put Flutter at roughly 42 to 46% of cross-platform developers against React Native's roughly 35%, per [tech-insider's 2026 comparison](https://tech-insider.org/flutter-vs-react-native-2026/). A 2025 enterprise survey flips it, with React Native at 42% against Flutter's 38%, and React Native ahead in job listings, per [Nomtek](https://www.nomtek.com/blog/flutter-vs-react-native). Read all of that as: both ecosystems are huge, and hiring for React Native tends to be easier because the pool includes every React web developer.

So the real decision comes down to two questions.

First, what does your team already write? If the answer is React and TypeScript, React Native reuses those skills, your component patterns, and often literal code from your web app: validation schemas, API clients, state logic. Flutter means Dart, which is a perfectly fine language that your team does not know yet.

Second, what does your UI look like? Flutter draws every pixel with its own rendering engine, which makes heavily custom, animation-rich interfaces easier to keep identical across platforms. React Native renders real platform components, which is why RN apps tend to feel native by default and why an iOS redesign rarely leaves your app looking dated.

For a [design-led consumer product](/services/design) with an unusual visual identity, we would seriously consider Flutter. For nearly everything else clients bring us (marketplaces, fintech UIs, delivery apps, internal tools) React Native wins on team fit and code sharing.

## React Native vs native: when two codebases earn their cost

Fully native still has a place. Choose Swift and Kotlin when the core value of the app is something cross-platform handles badly: console-grade 3D, heavy AR, audio processing with strict latency budgets, or day-one integration with a just-announced OS feature. In those cases the abstraction costs more than it saves.

For everything else, weigh it as money. Two native codebases means two teams (or one team constantly switching contexts), two release pipelines, and every feature built twice, forever. On a typical content, commerce, or productivity app, our estimate is that going native **roughly doubles** both the initial build and the ongoing maintenance, for a difference most users will never perceive. That math is why the default answer for a first app is cross-platform, and why an exception needs a concrete technical reason behind it.

## When not to choose React Native

This section survives every revision of this article because it is the part readers thank us for. Skip React Native if:

- The product is a game or a 3D-heavy experience. Use Unity, Unreal, or native rendering.
- Most of the roadmap is platform-specific native work: widgets, watch apps, deep OS hooks. If 90% of the code is native anyway, the shared layer buys you little.
- You only ever need one platform and the app is small. A single Swift codebase can be simpler than any cross-platform setup.
- Nobody on the team writes JavaScript and nobody wants to. Skill reuse is the main argument for React Native; without it, Flutter and native compete on even footing.

If none of those describe your project, cross-platform is the cheaper and faster path, and React Native is the version of it we recommend most often.

## How we scope a React Native build at Dock30

Mobile work at Dock30 sits next to the web work. The same team that builds your Next.js frontend and [your backend](/blog/fullstack-nextjs-nestjs-postgres-railway) builds the [mobile app](/services/mobile-apps) that talks to it, which matters more than it sounds: the expensive bugs in mobile projects usually live at the seam between app and API, and here one team owns both sides of that seam. You can see the shape of a finished build in [Pally](/work/pallyapp), a cross-platform app we shipped exactly this way.

Our defaults are boring on purpose: Expo, TypeScript, the New Architecture (not that anyone gets a choice since 0.82), and logic shared with the web codebase wherever it genuinely fits. Pricing works like the rest of our work: a [fixed-scope project](/pricing/project) with the exact price and delivery date in writing before we start, or a [monthly partnership](/pricing/partnership) from EUR 1,000 per month for ongoing development, with 30 days of free support after every launch.

If you are weighing a mobile stack right now, I am happy to look at your specific case. Book a [free 15-minute call](https://calendly.com/dock30/15min) and bring the idea. We will tell you inside those 15 minutes whether React Native fits, and if the honest answer is that you do not need an agency yet, you will hear that too.

## Frequently asked questions

**Is React Native still good in 2026?**

Yes. The current stable release is 0.86 (June 2026), it runs entirely on the New Architecture, and the legacy bridge that caused most of the historical performance complaints is gone. Shopify runs all of its mobile apps on React Native and reports screen loads under 500ms with over 99.9% crash-free sessions.

**Should I choose React Native or Flutter for a new app?**

Choose React Native if your team already writes React or TypeScript, because you keep your skills and can share code with your web app. Choose Flutter if the product depends on heavily custom, animation-rich UI that must look identical on every platform and you are comfortable adopting Dart. Both ecosystems are large and actively developed, so team fit should decide it.

**Do I need Expo to use React Native?**

No, but you should almost certainly start with it. Expo is the officially recommended framework for production React Native apps and removes most of the native configuration work. You can still add custom native code later, so choosing Expo does not lock you out of anything.

**How much code can you share between iOS and Android with React Native?**

The large majority of a typical app. Screens, business logic, API clients, and state management are usually written once. Published figures range from 60% to over 95% depending on the app, so treat any single number with suspicion. Apps built around platform-specific features sit at the low end; content and commerce apps sit at the high end.

**When is native development better than React Native?**

When the core of the app is something cross-platform handles badly: 3D graphics and games, heavy AR, strict audio latency, or day-one access to brand-new OS features. It can also make sense for a small single-platform app where a cross-platform setup adds overhead without payoff. For typical content, commerce, and productivity apps, going native roughly doubles the cost for a difference users rarely notice.

---

Written by Roberto Lazar, founder of Dock30. Book a call: https://dock30.com/contact