Shopify Just Walked Back Its Biggest Mobile Bet. The Reason Isn't What You'd Guess.

Six years ago Shopify went all-in on React Native and told everyone why. This week they published a post walking a big chunk of it back — Shop, their flagship shopping app, is already rebuilt natively in Swift and Kotlin, and the rest of their apps are next.

I run a site called NativeFirst. You’d think this is the easiest victory lap I’ll ever write. It isn’t, because the actual reason they switched back is more interesting than “native won,” and more useful to you if you’re not Shopify.

What they didn’t say

Here’s the thing that jumped out reading their post: they don’t say React Native failed. They say it explicitly — “React Native apps can be fast. Ours are.” No performance complaint, no framework-is-broken story, no “we finally saw the light” energy. The 2020 decision was good, for the reasons they gave then: build once, let backend developers touch mobile code, stop chasing feature parity across two codebases.

What changed isn’t React Native. It’s the cost of the alternative.

Shopify’s own framing: “building the same feature in Swift and Kotlin no longer carries the cost it used to.” That’s a cost-of-native claim, not a quality-of-React-Native claim. Coding agents got good enough at translating a feature from one native platform to the other — implement it in Swift, use that as the reference to implement the Kotlin version, or vice versa — that the core reason for going cross-platform in the first place started to erode. If an agent can port your feature between platforms nearly as fast as it can write it once in JavaScript, the “write once” argument stops being the deciding factor.

That’s a genuinely different claim from “AI writes better code than humans,” and it’s worth sitting with the distinction, because most of the hot takes I’ve seen on this story blur it.

The part that’s actually hard, and the part that isn’t

I’ve written before about why coding agents are bad at testing even when told exactly what technique to use, and about three months of pairing with Xcode’s own AI agent — so I read Shopify’s post with a specific question in mind: are they claiming the agent just one-shots a feature port? Because if so, I don’t believe it, and neither should you.

They don’t claim that. They call it out directly:

“It’s tempting to just point an LLM to the React Native codebase and try to one-shot the same features in native, but it doesn’t work. Even if you ask it to gather as much information as it can up front, freeze that into specs, task files, and then implement it, you end up with a huge amount of unmaintainable code that can’t be shipped.”

That’s the same lesson I keep landing on in my post about prompts not being skills: a big upfront spec doesn’t buy you a correct big output. Shopify’s fix, a system they built called Helix, is structurally the opposite of one-shotting. Point it at a screen, it breaks the migration into small ordered checkpoints, and each checkpoint has to pass tests, survive a visual diff against the running app, get through two adversarial code reviewers, and get a human’s sign-off before the next checkpoint starts. Small slice, hard gate, repeat. It’s TDD’s red-green-refactor loop wearing a different hat, applied to platform migration instead of feature development.

The honest takeaway isn’t “AI can port your app.” It’s “AI can port your app if you build a review pipeline strict enough to catch it lying to you at every step, and that pipeline is most of the actual engineering work.”

The bottleneck nobody talks about

The most useful paragraph in the whole post has nothing to do with LLM code quality. It’s about simulators.

“Agents can make code changes in seconds, but it takes them several minutes to test the output. This makes iterating extremely slow and manual. It doesn’t matter how good the model is if it can’t test its work quickly, which is especially difficult on mobile.”

I’ve felt this one personally, at a much smaller scale, every time I’ve had an agent try to verify a SwiftUI change against the simulator. The accessibility tree walk, the screenshot-and-squint loop, the general slowness of driving a UI through automation — it’s real, and it caps how autonomous an agent can be regardless of how smart the underlying model is. Shopify’s answer was architectural: decouple business logic from UI entirely, make it runnable headlessly on desktop, and give agents a CLI to drive it in milliseconds instead of minutes. Only fall back to the simulator when you actually need to verify pixels.

That’s not an AI trick. That’s just… good architecture, the same “keep your logic testable and your UI dumb” advice that predates LLMs by a decade. It just turns out that architecture pays off differently when your test suite includes an agent hitting it thousands of times a day.

What doesn’t transfer to you

This is the part worth being blunt about, because “Shopify did it, so should I” is a bad instinct here.

Shopify built a custom orchestration system (Helix), a custom agent-addressable CLI layer, and dedicated infrastructure and mobile engineers to run this migration on apps with 300+ screens, home screen widgets, an Apple Watch companion, and complications. They’re hiring specifically for “the intersection of AI and software engineering.” This is a resourced, multi-quarter engineering initiative, not a weekend vibe-coding session.

If you’re one developer shipping one or two apps, you don’t need Helix. You need the underlying idea at a much smaller scale: don’t ask an agent to port or rewrite a whole feature in one pass, break it into checkpoints small enough that you can actually review each one, and keep your business logic testable without spinning up a simulator every time. That’s advice that was already true before this story broke — Shopify just proved it scales to 300 screens.

What I do think generalizes is the underlying cost curve. If agents are getting good enough that a company the size of Shopify can afford to rebuild flagship apps on two native platforms instead of one shared codebase, that same math is quietly shifting for everyone building cross-platform, including anyone who chose Flutter or React Native mainly to avoid writing Swift twice. It doesn’t mean cross-platform frameworks are dead — Shopify says as much, they’re still sponsoring React Native Skia through the end of the year. It means the “native is too expensive to justify” argument just got measurably weaker, and it’s worth re-running the calculation on your own project instead of assuming a five-year-old decision still holds.

I build ThinkBud entirely native and on-device for reasons that have nothing to do with this story — privacy, mostly. But it’s a nice, unexpected bit of validation to see one of the biggest names in e-commerce arrive at “native, actually” from a completely different direction: not ideology, just a spreadsheet that changed shape.

Takeaway: Shopify’s move isn’t proof that native beat cross-platform. It’s proof that “write once” stops being a deciding argument once an agent can translate your feature to the other platform almost as fast as it can write it the first time — and that the hard part was never typing out the Swift, it was building a review loop tight enough to trust the output.