Shopify swaps React Native for Swift and Kotlin: what changes

In 2020, Shopify published a post with a title that became a rallying cry: React Native is the future of mobile at Shopify. Six years later, the same engineering blog announces the opposite move: the company is taking its apps off React Native and going back to Swift and Kotlin. If you have a React Native app in production, or you are choosing the stack for a new project, this news deserves more than a screenshot with a snarky caption.

I work with React Native every day. So I will be direct about what this decision means and what it does not mean.

What Shopify announced

For years, Shopify was the most cited React Native case outside of Meta. It migrated large apps, hired people from the core team, contributed to the New Architecture and wrote a lot about the process. When someone asked "but can React Native handle a serious app?", the standard answer was: "Shopify uses it".

Now the company says it is going back to native: Swift on iOS, Kotlin on Android. Two codebases, two platform teams. The very model it had left behind.

The original post is worth reading in full. Here I want to focus on what this means for people who are not Shopify. That is almost everyone reading this.

Why this decision weighs more than an isolated case

Companies switch stacks every week. Airbnb left React Native in 2018 and the community survived. What makes this case different is the history.

Shopify did not use React Native lightly. It invested heavily, knew the framework inside out and helped improve React Native itself. When a team with that level of expertise decides to leave, the reason is rarely "we didn't know how to use it".

That leaves an uncomfortable question: if even the people who mastered the tool didn't want to stay, what does that say to the rest of us?

My answer: it says a lot about Shopify's scale and very little about your app.

Does this mean React Native is dead?

No. And whoever says so on LinkedIn this week is selling a course on something else. (The Flutter crowd is already warming up their fingers to comment "told you so". Well, they also use a layer between the code and the platform.)

React Native solves a specific problem: shipping a decent app on both platforms with a small team, reusing React and TypeScript knowledge. That problem still exists. A startup with three devs gains nothing by maintaining two native apps.

What changes is the break-even point. In a huge app, with dozens of teams working on the same codebase, the cost of the middle layer grows:

• Every new iOS or Android feature arrives late or needs its own native module.
• A performance bug becomes an investigation across three layers: JS, the bridge (or JSI) and the platform.
• Upgrading React Native becomes a quarter-long project.
• You end up hiring Swift and Kotlin people anyway.

That last point is the one few people admit. A large React Native app does not eliminate native code. It just hides part of it.

The cost that shows up as the app grows

Anyone who maintains an app in production knows this path. Everything starts in TypeScript. Then comes a requirement for a custom camera, a home screen widget, a Live Activity on iOS, an integration with some payment SDK. You open the ios/ folder for the first time in months.

A simple module with Expo Modules looks roughly like this:

import ExpoModulesCore

public class ReceiptPrinterModule: Module {
  public func definition() -> ModuleDefinition {
    Name("ReceiptPrinter")

    AsyncFunction("print") { (payload: String) -> Bool in
      return PrinterSDK.shared.send(payload)
    }
  }
}

And on the JavaScript side:

import { requireNativeModule } from 'expo-modules-core'

const ReceiptPrinter = requireNativeModule('ReceiptPrinter')

export const printReceipt = (payload: string): Promise<boolean> =>
  ReceiptPrinter.print(payload)

Looks nice. Now multiply that by 40 modules, two platforms, tests on each one and a team that needs to understand all three sides. At some point the math flips: you are maintaining a native app and a React Native app at the same time.

A single codebase is only cheaper until you have to fight it.

What changed since 2020

This part is my own reading, not necessarily Shopify's argument.

In 2020, React Native's strongest argument was economic: writing the same screen twice is expensive. Today, with coding agents writing a good chunk of the repetitive code, that cost has dropped a lot. Asking an agent to port a screen from SwiftUI to Jetpack Compose is not free, but it is far from double the work.

When writing code gets cheaper, the cost of maintaining and debugging weighs more. And on both, native has the edge: fewer layers, official documentation, tooling straight from Apple and Google, no dependency waiting for a community update.

This doesn't apply to everyone. No agent replaces someone who truly understands the lifecycle of a view on iOS. But the argument "one codebase because code is expensive" has lost strength, and I think more companies will redo this math in the coming years.

When React Native still makes sense for your app

My rule of thumb, after shipping a few apps:

• Small team, product still finding its market: React Native with Expo, no second thoughts. Speed matters more than anything.
• An app that is basically forms, lists and API calls: React Native. The native gain there is almost invisible to the user.
• You already have a strong React web team: React Native leverages that knowledge like nothing else.
• An app that depends on hardware, heavy graphics or new platform features on launch day: start considering native seriously.
• Dozens of mobile devs and budget for per-platform teams: now you are in Shopify territory.

If you are in the first three groups, the Shopify news changes nothing in your Monday backlog.

What I would do today

If I were starting an app tomorrow, for most of the clients I work with, I would stick with React Native and Expo. For 90% of the apps I see, switching to native today would be an expensive decision to solve a problem they don't have.

But I would take two lessons from Shopify. First: treat the ios/ and android/ folders as first-class code, with people on the team who know how to work in them. Second: choosing a stack is not a marriage. Shopify changed its mind twice in six years, and that's fine. The right decision in 2020 can be the wrong one in 2026, because the context changed.

The mistake is copying the decision of a company with thousands of engineers and assuming it applies to a team of four. Look at your size, your product and your team. If you want to see how I've been handling this in practice, some apps are in my projects.

In 2020 Shopify said React Native was the future. In 2026 it is going back to Swift and Kotlin.

I use React Native every day, and my take is simple: this decision says a lot about Shopify's scale and very little about your app.

In a huge app, with dozens of teams, the middle layer gets expensive. Upgrades turn into quarter-long projects, bugs turn into investigations across three layers, and you end up hiring Swift and Kotlin devs anyway.

And there is something new: with agents writing the repetitive code, writing the same screen twice got a lot cheaper. What matters now is maintaining and debugging.

For a small team, a product still finding its market, or an app made of forms and API calls, React Native with Expo is still the right choice. A stack is not a marriage. But copying the decision of a company with thousands of engineers is not a strategy either.

I wrote the full analysis on the blog. If you are facing this question with your app, tell me how you are thinking about it.

#ReactNative #MobileDevelopment #Swift #Kotlin #Expo