Shopify went back to native. The reason was price, not performance

Shopify announced on 10 September 2026 that its mobile apps are going back to Swift and Kotlin, five years after the company committed to React Native.

Mustafa Ali's reasoning is the part worth reading twice. Agents, he writes, now do enough of the implementation, translation, testing and review work that a shared codebase is no longer the deciding factor it was in 2020.

Not a word about performance anywhere in it. The timing was not accidental either. The team was already facing a migration to React Native's New Architecture, and tested what agents could do straight in SwiftUI and Jetpack Compose instead. Shopify bought a shared codebase in 2020 so it would not pay twice for the same screen, and by 2026 that second payment had fallen far enough that the layer bought to avoid it stopped paying for itself.

What they actually shipped

One engineer spent a week pointing coding agents at the React Native source and letting them produce an iOS version. That was enough to green-light the project. Six engineers built the foundations and the main user journeys, product teams joined halfway through, and Shopify had the native Shop app live in both stores twelve weeks after that prototype.

Here is what the numbers looked like before and after.

Android release builds got roughly 75% faster while iOS builds stayed where they were. Session stability climbed from 99.5% to 99.95%, a tenfold cut in sessions that end in a crash, and the Android feed now runs at 120 FPS on a Pixel.

The merchant app is the harder one and it is still in flight. Over 300 screens, home and lockscreen widgets, an Apple Watch app with complications, Siri Shortcuts. It ships later this year.

Why Shopify left React Native

An abstraction layer is a trade. You pay runtime overhead, a dependency on somebody else's roadmap, and one more thing standing between your team and the platform. In return you get saved labour. Drop the price of that labour and the value of the layer drops with it, while the overhead sits exactly where it always was.

React Native did not get worse. The other side of the equation got cheap. That same arithmetic runs under every decision about how much of the output you own and how much you hand to a framework, and it does not always land the same way. We ran it for Next.js against htmx and came out somewhere else entirely.

What made twelve weeks possible

This is the part the coverage skipped.

The agents had something to copy, and Shopify says so directly. They did well where an existing implementation was there to read. Moving a screen from React Native to SwiftUI is a comparison task. Starting from nothing is a different job with a different hit rate.

Everything else is tooling, and the tooling is really the product here. The migration workflow runs as an extension to a coding agent called Pi, where specialised subagents read the React Native source, write down how it behaves, prepare a plan for the target platform, implement it and then check parity. A human accepts the plan, and that acceptance is tied to a hash of the plan's contents, so editing it throws the approval away. Helix paces the work in small steps, a developer aims it at one screen, and feedback from every review is remembered, so the loop needs less supervision the further the migration gets. Tardis, their debugging tool, hands an agent structured access to a running app's events, logs and state plus the ability to send commands into it.

Then there is the one piece any team can take without Shopify's budget. Business logic was pulled out of the UI so it runs headless on a desktop, and agents reach it through a CLI that lets them iterate in milliseconds instead of minutes, with no simulator involved. Architecturally this is an old idea. It is the property that makes code testable, now serving a second consumer.

Where the Shopify case does not transfer

Generated code met the requirement and introduced duplication, architectural drift or performance problems along the way. Native expertise stayed essential for exactly that reason, and review, linting, static analysis and performance checks all stayed with people. That is Shopify's account of it, not mine.

Parity moved rather than vanished. Two codebases mean iOS and Android have to stay feature-identical at all times, held there by development and release process instead of a compiler. The work survived the migration and is now paid for in coordination.

The scale is also not ours. Shop is a five-year-old product inside a company with a mobile platform group and a team building its own agent tooling. Anyone reading the announcement as permission to rewrite their app is reading it wrong. Whether a mobile app earns its budget at all is a separate question, and we wrote about it here.

The question that does transfer

Take every layer you keep because writing the code yourself was expensive and ask what that code would cost today. The question is what the alternative costs, not whether the layer is any good. That number moved in the last year and most companies last worked it out under prices that no longer hold. We took the same question apart for low-code and boxed systems.

The second question is the one that hurts. If your answer leans on an agent, is there something for it to copy, and can you tell within seconds whether what came back is correct? Missing either puts you back at human speed with more code to review than before.

So a mobile rewrite is the last place I would send a client, not the first. Start where both conditions already hold. An integration against a documented API. A report generator whose output diffs line by line against the old one. A move off a framework nobody maintains, where the existing behaviour is the specification. Those three are most of what we do in custom software work.

The framework duel in the headline is the least interesting thing here. What Shopify actually said is more ordinary and more useful. One line of their budget got cheap enough that the rest is worth recalculating, and for most teams that recalculation will change nothing at all. For one or two layers it will, and those tend to be the ones already costing the most.