On September 10, Shopify published a post titled Native is now the future of mobile at Shopify. Six years after going all-in on React Native, they're rebuilding every mobile app in Swift and Kotlin. Within an hour there were "React Native is dead" videos. Within a day the Hacker News thread was full of people who'd apparently been waiting since 2020 to say "told you so".
I've been building mobile apps for ten years, seven of them on React Native, and my first reaction wasn't worry. It was confusion. Why is everyone taking this so seriously?
The PHP test
Every few years a big company changes its stack and the internet declares a technology dead. People said PHP was finished a decade ago. Today a huge share of the web still runs on it, and people are shipping new sites and CMSs on it every day. Airbnb left React Native in 2018 and the framework has grown every year since — it's at roughly 4.5 million weekly downloads now, more than it's ever been.
Shopify is one company. A big and influential one, but one. Meta, Microsoft, Coinbase, Discord and thousands of smaller teams are still shipping on React Native. One departure, however well-argued, doesn't change that.
So no, I'm not worried. But the post itself deserves a fair reading, because the reasoning is more interesting than the headlines.
What Shopify actually said
Credit where it's due: the post is generous to React Native. Their words, not mine — the 2020 bet was "extremely successful", their RN apps are fast, and it "remains an excellent framework". They're not leaving because React Native failed them.
They're leaving because one assumption changed. In 2020 the biggest argument for React Native was not building the same feature twice. Shopify's claim is that coding agents now handle enough of the implementation, translation, testing and review work that building twice is no longer the deciding factor. Native still means two codebases; it's just cheaper than it was.
To make that real they built an internal tool called Helix. It reads a React Native screen, breaks the port into small checkpoints, and each one has to pass tests, match the running app visually, survive two adversarial AI reviewers, and get a human sign-off before the next starts. They also redesigned their app architecture so business logic runs headless on a desktop and agents can test it in milliseconds instead of driving a simulator. With that machinery, the Shop app went from proof-of-concept to published native apps in 12 weeks.
That's impressive engineering. It's also the key to understanding why this decision is right for Shopify and probably wrong for you.
Why Shopify's math doesn't transfer to small teams
Read the Helix description again. Custom agent orchestration, adversarial review pipelines, a headless business-logic layer, a CLI for agents to drive the app. That took a large team with a large AI budget to build, and it's what makes "maintaining two native codebases" tolerable.
Strip that away and you're back to what maintaining two codebases has always meant for a normal team. Every feature is designed once and implemented twice. Every bug is reproduced on two platforms. QA and testing double, because you now have two apps that can drift apart in subtle ways. Even if an agent writes most of the Kotlin from the Swift, someone still has to review both, and the agent bill for doing that at Shopify's scale is not small.
My honest take: this is a good decision for Shopify. For a 1–10 person team, or a founder paying an hourly rate, it would be very hard to justify. The thing React Native gives you — one team, one codebase, one QA pass, two stores — is still the single biggest cost lever a small mobile team has.
What I tell clients who ask
Here's something I've learned over a lot of client projects: most clients genuinely don't care what the tech stack is. They want a healthy, smooth, reliable product. The end result is what matters to them, and it should.
So when a founder asks me "should we go native now, like Shopify?", my answer is still React Native — with Expo, on the New Architecture. It's the fastest way I know to get a quality app into both stores with a small budget.
If a client is technical and pushes for native, I'm not going to refuse. I started my career writing Java for Android, so it's not a foreign world. But I'll be clear about what they're buying: two codebases, extra agent and tooling cost, and a debugging and QA budget that roughly doubles because every change has to be verified on both platforms. If they understand that and still want native — for reasons that hold up — that's a legitimate choice. Most don't need it.
Where native genuinely wins (and what to do about it)
None of this means React Native does everything. It doesn't, and I've hit the edges myself.
On DineHome, a food delivery platform I helped build from scratch, three things had to be written natively: hardening the kitchen POS app into kiosk mode (overriding Home, Back and the power button in Java/Kotlin), driving thermal printers over ESC/POS, and streaming rider GPS from a background service with the screen locked. Shopify's own 2025 post listed similar territory — on-device ML, scanning, widgets, watch apps, long-running background work.
But notice what the fix was in every case: a native module, bridged into the React Native app. Not a native app. You write the piece that needs the platform in Kotlin or Swift, expose it through a TurboModule, and keep the other 90% of the product in one codebase.
This is where I think AI agents actually help the React Native developer more than they help Shopify. Bridging used to be the intimidating part — the boilerplate, the type marshalling, keeping iOS and Android modules in sync. That's exactly the kind of work agents are now good at. Build your structure in React Native, and when something needs the platform, drop to native for that piece with an agent doing the tedious parts. Having both skills has always been valuable. Now the gap between them is smaller than ever.
The Expo question
One detail from the discussion that matters: Shopify wasn't on Expo. An Expo co-founder called the decision more political than technical, and several people pointed out that a lot of the upgrade pain Shopify described is pain Expo now absorbs — builds, updates, dev clients, native module scaffolding.
I can only speak for my own experience, and Expo has improved enormously. Rendering, upgrades, the module system, the release pipeline — all of it is in a different league from three years ago. Shopify's move was their call, made inside their team with their constraints. From where I sit, with what Expo offers today, I don't think it was necessary.
What about FlashList?
This is the part that worries me a little. FlashList — Shopify's high-performance list, around 2 million downloads a week — will get critical compatibility fixes from Shopify while they look for a new maintainer, but that's it. React Native Skia is being forked under a new name by its original author. Restyle is being archived at the end of 2026.
I recommended FlashList in my performance article and I still do. The current version is stable. The risk isn't today; it's a year from now, when a new React Native release changes something and nobody has synced FlashList to it.
What I'd tell a client whose app depends on it:
- Pin it. Don't let a patch version drift into a broken build.
- Watch the stewardship news. If a credible company picks it up, this problem disappears.
- Have a fork plan. If it stalls, forking and maintaining the fixes you need is realistic now — it's the sort of focused, well-scoped work agents are good at, and I'd rather maintain a small fork for a client than rewrite their list screens.
{
"dependencies": {
"@shopify/flash-list": "2.1.0"
}
}
Exact pin, no caret. Boring, but it's the difference between "we'll deal with it when we choose" and "the build broke on Monday".
The one thing I can't answer yet
Some critics say Shopify's before-and-after numbers — faster startup, smaller app — compare an old-architecture React Native app against a fresh native rewrite, and that any greenfield rewrite would show big wins. I honestly don't have the data to judge that, and I'm not going to pretend I do. What I'll say is that rewriting a large app is hard and expensive no matter the language, and if you're using Shopify's numbers to justify your own rewrite, make sure you're comparing like with like.
What this changed for me
Here's the honest part. This news didn't make me doubt React Native, but it did confirm something I'd already been thinking: I shouldn't depend on one stack.
I started in native Java. When React Native arrived I switched, because it was the right tool for the work I was doing. Now, with agents making it far cheaper to work across Kotlin, Swift and whatever comes next, there's no reason to fence myself in. If a client needs native, I'll build native. If the time demands a different stack, I'll learn it. React Native remains my default because it's still the best answer for most of the products I'm asked to build — but it's a default, not an identity.
That, I think, is the real lesson from Shopify's post. Not "go native" or "stay on React Native", but: revisit your assumptions when the world changes, and choose the stack that fits your team, your budget and your product — not the one that fits a company with a thousand engineers.
Weighing React Native against native for a new app, or worried about a dependency like FlashList in an existing one? Here's how I work, or get in touch and we can talk it through.
