Shopify spent five years telling everyone React Native was the right call. Shared code across iOS and Android, non-mobile developers contributing to mobile apps, no more chasing feature parity between two teams. As recently as January 2025, they published an article saying the future of React Native at Shopify was bright.
Then they reversed it. Shopify is moving Shop and their other flagship apps back to Swift and Kotlin, native code, no shared framework.
I've spent years defending React Native publicly, so this one is personal for me. But instead of getting defensive, it's worth actually sitting with what Shopify said, what they got wrong, and what this genuinely signals for anyone building mobile apps right now.
Why Shopify says they're switching
Their reasoning isn't "React Native is bad." It's more specific than that. In 2020, the calculation was simple: building the same feature twice, once for iOS and once for Android, cost too much engineering time. React Native collapsed that cost by letting one team ship to both platforms.
Shopify's claim is that AI coding agents changed that math. Their internal experiments showed agents could implement a feature on Android using the iOS version as a reference, and vice versa, close to autonomously. If an agent can translate, test, and review platform-specific code fast enough, the core reason to share a codebase in the first place starts to erode. Native gets you closer to platform capabilities with fewer abstraction layers in between, and if the "cost of building twice" argument disappears, that trade starts to look better.
To make this workable at scale, they built internal tooling called Helix. It doesn't let an agent one-shot a feature port. Instead, it breaks the work into checkpoints, each one needing to pass automated tests, survive adversarial code review, and get human sign-off before the next checkpoint starts. They also built a CLI layer so agents could test business logic headlessly, without waiting on a slow simulator for every iteration, which had apparently been a real bottleneck.
The Shop app, their flagship, went from a working prototype to a fully rebuilt, shipped app in 12 weeks with AI doing most of the implementation work.
What the comparison actually leaves out
A few things in Shopify's story don't hold up as cleanly as presented, and they matter if you're trying to draw a general lesson from this.
They weren't using React Native's New Architecture. Shopify's exploration into native happened around the same time as React Native's biggest recent overhaul, the New Architecture, which dramatically improves how JavaScript and native code communicate. Their performance comparisons were against an older architecture, not the current one. That's a meaningfully different baseline.
They weren't using Expo either. Expo handles a huge amount of the tooling pain in React Native: builds, over-the-air updates, dev clients, simulator and web support for testing. If you're running React Native without it, you end up rebuilding a worse version of Expo yourself, which is expensive in a completely different way than "native vs cross-platform." Some of what Shopify was fighting wasn't React Native. It was React Native without the tooling that makes it good.
App size didn't actually improve. One of the most common anti-React-Native arguments is bloat. Shopify's own numbers show the native rewrite shaved off about one megabyte. That's not a meaningful difference, and it's worth remembering next time someone claims cross-platform apps are inherently bloated. Most bloat comes from assets, localization, and media, not the framework.
The single biggest omission is OTA updates. Over-the-air updates let you push a JavaScript bundle change without going through app store review. If you ship a bug, you can fix it within the hour instead of waiting days for approval and then weeks for users to actually update. Anyone who's looked at real usage data knows a huge share of users sit on outdated app versions at any given time. Native code doesn't have an equivalent to this. It's arguably React Native's single biggest practical advantage, and it barely gets mentioned in the reasoning for leaving it behind.
The real downsides worth taking seriously
None of this means React Native is flawless, and some of the criticism is fair.
Dependency management inside Xcode, CocoaPods, and native linking is genuinely painful, and that pain has very little to do with JavaScript or React itself. React Native also attracts a wider range of developer skill levels than native development does, mostly because it's more approachable, which means the footguns that hurt any React codebase hurt harder on mobile, where one bad effect can tank the whole experience. Major architectural rewrites over the years have made version upgrades unreliable enough that a full reinstall is often faster than a clean bump. And being downstream of Meta's roadmap means waiting on them to support new platform features instead of using them the day they ship.
These are real trade-offs. They're just a different set of trade-offs than the ones getting the most attention.
What happens when you actually try the AI-assisted port yourself
Here's where it gets interesting. A separate experiment, ported an existing React Native mobile app to native SwiftUI using AI coding agents, working solo, part time. The agent was given a simulator, the existing React Native source, and a clear reference implementation to match. The result: a near-complete, working native port, generated largely unsupervised, in a matter of hours, not weeks.
That doesn't match Shopify's experience of this being a slow, difficult, multi-month migration. The most likely explanation is model choice. Different AI coding agents perform very differently on this kind of large-scale, cross-language porting task, and the gap between "this works great" and "this is a slog" seems to come down heavily on which model is doing the work.
One detail from that porting experiment is worth calling out specifically, because it says something bigger than "which framework is faster." SwiftUI's native navigation stack only recognizes the back-swipe gesture from a narrow strip on the left edge of the screen, and you can't widen it. A lot of real users swipe back starting from the middle of the screen instead. Apple's own first-party apps, like Settings, don't actually use the pure native navigation stack for this exact reason, they've built custom gesture handling to support both. Even fully native, first-party Apple software works around Apple's own platform defaults to meet real user behavior. "Native" isn't automatically a UX shortcut. Good mobile UX takes deliberate work regardless of what's rendering it.
The quieter, more important signal
The most consequential part of this story isn't about React Native versus Swift at all. It's about what's happened to the teams building these frameworks.
At its peak, Meta reportedly had roughly ten times as many engineers on React Native as on core React and the web side combined, and for good reason: exposing the entirety of iOS and Android's native capability inside a single JavaScript-accessible layer is a genuinely harder engineering problem than improving how React updates the DOM. Some of the strongest native engineers around ended up on that team specifically because they wanted less-experienced developers writing native-adjacent code without wrecking the platform experience.
That investment has been shrinking. A number of senior engineers who worked on React and React Native have left Meta over the past year, several landing at companies building AI coding tools instead. The framework isn't going away, but the pace of investment and the depth of talent behind it has clearly changed. If you're betting on a framework for the next five years, the health of the team maintaining it matters as much as this quarter's benchmark numbers.
Where this actually leaves mobile developers
This was never really a "write once, run everywhere" argument, and treating it that way misses the point on both sides. It was always closer to "learn once, understand everywhere." Once you understood React, you could apply that understanding to two platforms without learning two entirely separate languages and ecosystems from scratch. What mattered wasn't the code sharing, it was the shared mental model.
AI coding agents are changing the cost of both paths at once. They lower the cost of building native twice, which is Shopify's argument. But they also lower the skill floor needed to work confidently in React Native, and they make porting between the two dramatically cheaper than it used to be. Neither side of this debate gets to claim agents as exclusively their advantage.
If there's one practical takeaway for anyone building or hiring for mobile right now, it's this: the framework decision matters less than it used to, and the platform-understanding decision matters more. Whichever stack you pick, someone on your team needs to actually use the other platform daily, not just build for it. A huge share of the bugs and UX complaints that make an app feel "off" come from a team that only really tests on one device. That was true before agents, and it's still true now.
React Native isn't dying. But the reasons to choose it, and the reasons not to, are shifting under everyone's feet at the same time the tools for building it are.
