# Shopify Is Moving Its Mobile Apps Back to Native. Coding Agents Made It Cheaper to Build Twice Than to Share One Codebase. > Source: > Published: 2026-09-10 19:56:58+00:00 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](https://shopify.engineering/back-to-native) 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. Shopify's original case for React Native had three legs: 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. 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.** 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: 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. 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 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. 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.** 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: 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. 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.