Shopify drops React Native: what it teaches us

In 2020, Shopify published a post saying React Native was the future of mobile at the company. Six years later, the engineering team published another one, with a much less festive title: they're going back to Swift and Kotlin. If you work with React Native, this news hits hard. Shopify wasn't just another user of the framework. It was one of its showcases.

I use React Native day to day, and I won't pretend I read this with indifference. But before declaring anything dead, it's worth understanding what changed and what it means for anyone choosing an app stack today.

What Shopify did with React Native

To size up the news, remember how big the bet was. Shopify moved major apps to React Native: the merchant app, Point of Sale and Shop, its consumer shopping app. This wasn't an experiment in some forgotten internal app. It was product that makes money.

And the company didn't just consume. It gave a lot back to the ecosystem:

• FlashList, the list that became the default for anyone suffering with a laggy FlatList.
• react-native-skia, built together with the community, for high-performance drawing and animation.
• It hired core contributors and sponsored work on the new architecture.

So when a company with that track record says "we're going back to native", nobody can accuse the team of not knowing how to use the tool. That's what makes the news interesting.

Why Shopify is going back to Swift and Kotlin

The post details the reasons and is worth reading in full, straight from the source. I won't reproduce it here. What interests me is the pattern behind it, because it shows up in almost every cross-platform app that grows a lot.

React Native's promise has always been: one team, one codebase, two platforms. At first, that's true. You write the screen once, it runs on iOS and Android, and the team moves fast.

Over time, the app matures and starts asking for things that live outside JavaScript. Home screen widgets. Live Activities. Tap-to-pay integration. Fine-grained accessibility. Animations that need to run at 120 Hz without a hiccup. Each of those becomes a native module. And the code starts to look like this:

const CheckoutButton = Platform.select({
  ios: () => <ApplePayButton onPress={pay} />,
  android: () => <GooglePayButton onPress={pay} />,
})!

One Platform.select on its own isn't a problem. Two hundred scattered across the app are. At some point you're maintaining three codebases: the shared JS, the Swift for the iOS modules and the Kotlin for the Android modules. And you still need people who understand the bridge between all three.

Shared code only saves money when the problem is shared too.

That's the cost nobody puts in the spreadsheet when they pick cross-platform on day one.

Is React Native dead? No, and here's why

Every time a big company switches stacks, someone on X says the technology is over. We've seen this movie before with Airbnb in 2018, which also left React Native. The framework didn't die. Quite the opposite: it got the new architecture, Hermes got much better, and Expo became a truly serious platform.

Shopify's decision says more about Shopify than about React Native. Think about its situation:

• It has the money to keep separate iOS and Android teams.
• It has huge apps, with years of accumulated features.
• It competes on experience. A checkout that's 200 ms slower costs sales.
• It needs to adopt new Apple and Google features on launch day, not three months later when the community library catches up.

Now compare that with most projects I see: a small team, a tight deadline, an app that's basically forms, lists and API calls. In that case, hiring a Swift dev and a Kotlin dev to build the same screen twice is throwing money away.

The right question was never "React Native or native?". It's "what stage is my app in, and where is the bottleneck?".

AI enters the equation

There's one detail that changed since 2020, and I think it matters more than it seems. The cost of writing code dropped. With AI agents generating a good chunk of the boilerplate, porting a SwiftUI screen to Jetpack Compose got much cheaper than it used to be.

Before, the big argument for cross-platform was "writing it twice is expensive". If writing got cheap, the bottleneck moves somewhere else: reviewing, testing, maintaining and understanding the code. And then a native app, using the platform's official tools with no extra layer in the middle, can end up simpler to maintain than a hybrid app full of bridges.

I'm not saying that was Shopify's reason. I'm saying this math changed for everyone, and anyone choosing a stack in 2026 with a 2020 mindset risks optimizing the wrong cost.

What changes in practice for React Native users

If you have a React Native app in production, you don't need to panic or open a migration issue tomorrow. But there are some very concrete lessons here:

1. Count your native modules. Run a quick survey of the project:

grep -rl "Platform.OS\|Platform.select" src | wc -l
ls ios/*/*.swift android/app/src/main/java/**/*.kt 2>/dev/null | wc -l

If those numbers grow every sprint, the app is asking for native and you're paying a bridge tax.

2. Separate product from platform. Business rules, validation, state and API calls can live in plain TypeScript, outside the components. If you migrate one day, that part comes along or becomes backend. Whoever mixes everything inside screens will rewrite everything.

3. Don't fight the platform. If the feature is very iOS-specific, write it in Swift and expose a small module. Trying to rebuild in JS something Apple already ships ready-made is the most expensive way to end up looking like the original.

4. Keep Expo and the new architecture up to date. A lot of the pain of old React Native came from the async bridge and delayed upgrades. Teams that fell three versions behind feel the weight of the framework much more.

My take on the return to native

I still start apps with React Native and Expo. For the size of projects that I and most devs reading this blog work on, it's still the fastest way to ship something good to both stores with a small team. My strong opinion is this: going pure native on day one, for a three-screen MVP, is technical vanity.

But Shopify shows something everyone who loves a tool needs to hear: a stack isn't a sports team you root for. The same company that helped build the ecosystem looked at the numbers, saw the context had changed and switched. No drama. That's engineering. Cheering for a framework and defending it in a thread is something else, and nobody pays for that.

If you're unsure which path to take with your app, take a look at the projects I've delivered and how I picked the stack for each one. Spoiler: the answer was almost always "it depends", just with numbers next to it.

In 2020, Shopify said React Native was the future. In 2026, it announced a return to Swift and Kotlin.

I use React Native every day, and I didn't read that with indifference. But the framework isn't dead. The decision says more about where Shopify is right now than about the tool.

Shared code only saves money when the problem is shared too. With two hundred Platform.select calls scattered around, you're already maintaining three codebases.

And AI changed the math: writing things twice got cheap. Now the expensive part is reviewing, testing and maintaining.

For an MVP with a small team, I'm sticking with Expo. A stack isn't a sports team you root for. It's a decision with numbers next to it.

On the blog I explain how I pick the stack for each project. Link in the comments.

#ReactNative #MobileDevelopment #Shopify #SoftwareEngineering #Expo