Should you leave React Native? A decision guide after Shopify

What actually changed

React Native's core promise was economic: write a feature once, ship it on two platforms, and pay for one team instead of two. Shopify's argument is that “LLMs changed one of the core assumptions behind our 2020 decision”: coding agents broke that arithmetic. When an agent can implement a feature on one platform using the other as a reference, the cost of a second codebase falls, and the advantages of native — direct platform access, fewer dependency layers, faster startup — stop being luxuries.

Nothing about React Native itself got worse. The price of the alternative went down. That distinction matters, because it means the decision depends on your team and your app, not on a verdict about the framework.

The case for moving

Performance you can measure. If cold start or install size costs you users, that is real money. Measure yours before and after moving one screen, rather than borrowing another company's numbers.

Platform features on day one. Widgets, Live Activities, App Intents, watch apps and new Android surfaces arrive as native APIs first. In React Native each one is a bridge you write and maintain.

One fewer layer to debug. Upgrades of React Native, Expo, and every native dependency's wrapper stop being a recurring project.

The case for staying

Shared code is still the cheapest way for a small team to ship on two platforms. Agents make a second codebase cheaper to write; they do not make it free to review, test, release and own.

OTA updates go away. If your release process depends on shipping JavaScript fixes without store review, native takes that tool from you. See the guide on life after OTA updates before deciding.

React Native is not being abandoned. Meta, Microsoft and Expo all continue to invest in it, and Expo's direction is to make adding native code inside a React Native app easier, not harder.

Four questions that decide it

1. Is something measurably wrong? Startup time, app size, crash rates, or a roadmap blocked by platform features. If you cannot name the problem, you do not have a migration project, you have a news cycle.

2. Who owns native code afterwards? If nobody on the team will read Swift and Kotlin for the next three years, agents writing it is a liability rather than a saving.

3. Is the pain local? If one screen or one capability hurts, write a native module or a native screen inside the React Native app and stop there.

4. Can you afford to do it gradually? A migration that has to land in one release is a rewrite, and rewrites are where projects die. If you can move one screen at a time while both apps keep shipping, the risk drops sharply.

The cheap middle path

Most teams asking this question should not migrate the whole app. They should move the parts that hurt: a native camera screen, a widget, a performance-critical list. React Native apps can host native screens, and native apps can host remaining React Native screens during a transition. You can decide how far to go after the first screen, with real numbers instead of a headline.