In 2020, Shopify announced that React Native was the future of mobile at Shopify. In January 2025, the same team published "Five years of React Native at Shopify," saying the framework's future was bright and Shopify planned to keep investing in it. Yesterday, September 10, 2026, the same team published a post with a different conclusion: Shopify is migrating every mobile app back to Swift and Kotlin.
The Shop app is already done. A team of six engineers rebuilt it fully native, from proof of concept to a published app in the stores in 12 weeks. The main Shopify app is underway now: 300+ screens, home and lockscreen widgets, an Apple Watch app, Siri Shortcuts. The rest of the fleet follows.
Most coverage of this news will frame it as "React Native lost." That reading is wrong, and the difference matters for how you read your own stack decisions. The announcement is explicit on this point. React Native worked at Shopify. It delivered what it promised. What changed is not the framework. What changed is the cost of the alternative.
What 2020 was optimizing for
Shopify's original case for React Native had three legs:
- Stop building the same features twice, once in Swift and once in Kotlin
- Let developers work across the stack instead of staying in one platform silo
- Spend less time chasing feature parity and more time shipping
These were not lazy reasons. They were the dominant reasons most teams pick a cross-platform framework, and they still are. And React Native delivered. The January 2025 retrospective is full of receipts: sub-500ms P75 screen loads in the Shopify app, over 99.9% crash-free sessions, feature parity described as a non-issue. The team's own summary was that native does not automatically mean fast and React Native does not automatically mean slow.
So when you read that Shopify is leaving, resist the reflex that says the framework failed. Shopify's apps were fast and stable on React Native. The retrospective says so, in numbers.
What changed: the LLM did not just write code, it repriced the tradeoff
Shopify has been using LLMs for development since 2021. By late 2025, something shifted. Their own words: agents were "no longer just helping us write code faster. They were capable of making us question whether building software twice still meant doing twice the work."
That is the actual news in this announcement, and it is bigger than one company's stack choice. The core argument for a shared codebase was always an economic one. Two platforms means two implementations, two test suites, two everything. A shared codebase is cheaper because you build once. Coding agents attack exactly that assumption, from both sides:
Translation between platforms got cheap. In Shopify's prototypes, agents could implement a feature on Android using the iOS version as the reference, and the reverse. One engineer, one week of agent-assisted prototyping, most of the Shop app ported to SwiftUI from the React Native codebase. The result was not production ready, but it was close enough to prove the point.
Cross-stack ramp-up got cheap. Agents helped developers contribute effectively outside their primary stack. Your best iOS engineer can now meaningfully drive a Kotlin migration, because the agent is the one who knows Kotlin.
Parity maintenance got cheap. Shared specs, shared tests, and review checkpoints let agents carry most of the parity load that a shared codebase used to absorb. Shopify is direct about the limit: native still means building and maintaining two platforms, and that cost has not disappeared. It is just no longer the deciding factor it was in 2020.
And the costs on the other side of the ledger did not go anywhere. Shopify spent significant resources on React Native performance work, framework fundamentals, and keeping up with framework updates and external dependencies. Native keeps you closer to platform capabilities and first-party tooling, with fewer layers between your code and the platform. When agents shrunk the shared-code advantage, the remaining advantages of native decided the outcome.
If you remember one sentence from this article, make it this one: when agents can translate Swift to Kotlin and vice versa, "we only have to build it once" stops being a moat. It becomes an unnecessary constraint.
Greenfield over brownfield, because the rewrite is no longer the expensive part
Shopify's apps are enormous, and millions of merchants earn their livelihood through them. The conventional wisdom says never rewrite a working app. In 2020 they chose brownfield migration for exactly that reason. This time they chose greenfield, a full rebuild, for three reasons:
- Agents build features in Swift and Kotlin using the React Native version as a working reference
- A clean slate removes old constraints instead of carrying them forward
- Prototypes showed a rebuild was substantially faster than pre-agent estimates
The Shop app numbers back that up. Six engineers, 12 weeks, fully native in the stores. Priorities during the migration: preserve feature behavior and analytics events, keep users signed in, keep push notifications working. It should feel like a normal app update.
Helix: the anti-slop migration machine
The most valuable engineering detail in the post is what does not work. Shopify tried the obvious thing, pointing an LLM at the React Native codebase and asking for a one-shot native port. Their verdict: "you end up with a huge amount of unmaintainable code that can't be shipped."
Instead they built a system called Helix. The idea is a gradual, gated rebuild:
- The developer points Helix at a screen. It reads the React Native source and proposes a sequence of checkpoints, small ordered slices of work.
- Each checkpoint must prove its behavior with tests.
- Each must match the running app in a visual review.
- Each must survive two adversarial AI reviewers.
- Then a human approves before it is committed and the next slice starts.
- Feedback from every review is remembered, so the loop gets more autonomous as the migration progresses.
The design principle is worth stealing even if you never migrate a mobile app: the first output is not expected to be correct. An imperfect attempt simply cannot move forward until it becomes a good result. That is the opposite of one-shotting, and it is the same shape as every production agent workflow that actually ships.
The unsung breakthrough: fast feedback loops, not smarter models
Shopify's own account of its bottleneck is not model quality. It is that agents could make code changes in seconds but needed several minutes to test the output through simulators. Their words: "It doesn't matter how good the model is if it can't test its work quickly."
Simulator control was slow and brittle because agents relied on the accessibility tree and screenshots to read app state, act, and verify. React Native hot reload helps humans, but agents were still babysitting simulators.
The fix is architectural, not model-related. Shopify redesigned the app so business logic runs completely decoupled from the UI, headlessly on desktop. Agents get a CLI that can inspect app state, navigate sections, and perform actions in milliseconds instead of minutes, without a simulator at all. When real UI interaction is needed, the CLI connects to simulators in remote mode and drives the UI via commands, no layout or accessibility tree parsing. The result is agents that work autonomously for hours.
If you are building agent workflows anywhere, not just mobile, this is the transferable lesson: the fastest path to useful agents is not a better model. It is an architecture the agent can drive at millisecond latency.
What happens to the React Native ecosystem
Shopify is not abandoning its open-source libraries abruptly, and the handling here is a model for how to leave an ecosystem without burning it:
- React Native Skia. Shopify sponsors it through the end of 2026. William Candillon continues beyond that, forking the repo and republishing under a new name. The original repo gets archived after the transition. The post asks users of the library to consider sponsoring it.
- FlashList. Around 2M downloads per week, the default high-performance list library in React Native. Shopify keeps fixing critical compatibility issues and is in discussions with several companies about long-term stewardship.
- Restyle. Smaller user base, so it gets archived. Working through end of 2026, then unmaintained. Forks welcome, handover help offered.
FlashList is the one to watch. When the company behind the default list library exits the ecosystem, stewardship details matter to a lot of production apps.
What this means for your stack
Be careful with the takeaways here, because the easy ones are wrong.
This is not "React Native failed." Shopify's own data says their RN apps were fast and stable. Meta's team gets thanked in the announcement itself. If your RN app is working, nothing in this post says you should migrate. Shopify is not even claiming your situation matches theirs.
This is "the build-twice penalty was the whole argument." Shopify reevaluated from first principles when a core assumption changed. The result is not universal truth either. Your team size, your hiring market, your platform surface, and your agent maturity may still favor a shared codebase. The lesson is not the conclusion, it is the process: identify the assumption your stack decision rests on, watch for when it changes, and be willing to re-ask the question even after five successful years.
The interesting signal for mobile teams is smaller than the headline. You likely will not rewrite your app. But you can copy the Helix checkpoint pattern for any agent-driven refactoring, and you can copy the headless business-logic-with-a-CLI architecture for any agent workflow. Those two ideas apply everywhere.
Shopify ran its React Native era well and is leaving it well, with sponsored handovers and public numbers. The company that once bet the mobile stack on "build once" is now betting it on "agents make building twice cheap enough." That bet only became available in the last two years. Watch what it does to web, backend, and infrastructure decisions next.
Top comments (0)