Shopify drops React Native: what it means for you

Shopify is walking away from React Native. On September 10, 2026, the company's Head of Mobile, Mustafa Ali, published two engineering posts saying Shopify's apps are being rebuilt in Swift and Kotlin, one codebase per platform again. The Shop app already shipped as a fully native build. The main Shopify app, with more than 300 screens, a Watch app, and lock-screen widgets, is next, and it's due later this year.

What makes this worth reading is the timing. In January 2025 the same person wrote a piece called "Five years of React Native at Shopify" and told the industry that if you hadn't tried React Native in a while, now was a good time to look again. Twenty months later he's migrating off it. That's not a company that fell out of love with a framework. It's a company that watched one of its core assumptions change and had the nerve to say so in public.

The assumption was cost. Shopify moved to React Native in 2020 to stop building every feature twice. Ali is blunt that the framework did its job: "React Native apps can be fast. Ours are." The reason for leaving isn't performance. It's that AI coding agents got good enough that writing the same feature in Swift and Kotlin no longer costs what it used to. Once an agent can carry a lot of the second implementation, the main argument for a shared codebase gets weaker, while the benefits of going native, closer to the platform and fewer dependency layers, stay exactly where they were.

The numbers are real. Rebuilt native, the Shop app cut cold start by 23% on iOS and 50% on Android. Crashing sessions dropped roughly tenfold, from 99.5% session stability to 99.95%. Android release builds got about 75% faster, the Android binary shrank by 109 MB, and the feed holds 120 FPS while scrolling. Six engineers took it from proof of concept to the App Store in 12 weeks, after a single engineer spent one week proving the idea could work at all.

Where we'd slow you down

The headline everyone shared is "AI killed cross-platform." The more useful detail is buried in the migration write-up: Shopify's biggest speed win came from decoupling business logic from the UI so it runs headlessly, driven by a command-line tool instead of a simulator. Their agents could then iterate in milliseconds instead of babysitting a simulator for minutes per change. That trick has nothing to do with Swift or Kotlin. You can do it in React Native today. Push your logic into plain modules with no UI imports, run them under Node behind a thin CLI, and your agents, and your tests, get the same fast loop. In our native iOS and Android work, and in the healthcare and IoT apps we've built where correctness matters more than pixels, that separation is the single change that pays off whether or not an agent ever touches the code.

Second thing worth saying out loud: Shopify still needed native experts. Their own post admits the generated code introduced duplication, architectural drift, and performance problems, and that native expertise remained essential. The cost of two codebases didn't disappear. It moved from writing code to reviewing it. Reviewing Swift you didn't write, and knowing whether it's actually any good, is the expensive part, and it doesn't parallelize the way generation does. A five-person startup does not have Shopify's review bench. Copy the decision without copying the review capacity and you end up with two codebases and half the confidence.

So the concrete advice: don't read this as a signal to rewrite anything. Read it as a nudge to run one experiment. Pick a screen, pull its logic out from behind the UI into a headless module with its own tests, and measure how much faster both your engineers and your agents move against it. That's a day of refactoring, it's reversible, and it tells you more about your own codebase than any Shopify metric will.

There's a quieter security lesson in Ali's 2025 post too. He flagged that React Native's reliance on third-party libraries widens your supply-chain attack surface. Still true, and not unique to React Native. Every native project leans on packages as well. During our pentesting engagements the dependency tree is one of the first places we look, because a compromised transitive package is a far more common way in than a bug in your own code. Fewer framework layers can mean fewer moving parts to audit, but only if you actually track what you pull in.

None of this means React Native is finished. Shopify is a very specific case: huge apps, budget for AI inference and native reviewers, and a looming New Architecture migration that made a from-scratch rebuild competitive with upgrading in place. Most teams are not in that position. The right stack still depends on your team, your apps, and how much of the second build you can honestly trust an agent to carry.

If deciding between native, cross-platform, or a headless refactor for your next mobile release sounds familiar, let's talk. We've shipped both native and cross-platform apps, and we'll tell you plainly when a rewrite is the wrong call.