On 10 September, Shopify announced that it is moving its mobile apps off React Native and back to Swift and Kotlin. This is a company that went all in on React Native in 2020, said publicly in January 2025 that the framework’s future was bright, and built several of the ecosystem’s most used libraries. The stated reason for the reversal is not performance, and it is not a complaint about the framework. It is AI coding agents.
We published a post on 29 July arguing that agents had become the decisive input to mobile framework choice. We were right about the input and wrong about what it selects for, and the mistake is not really about mobile.
TL;DR
- The Shop app went from proof of concept to shipped native app in 12 weeks: Android cold start down 50%, crashing sessions down roughly tenfold, Android build 109 MB smaller.
- Cross-platform was never a technical choice. It was an amortisation decision, and agents changed the divisor rather than the verdict.
- The transferable asset is not Swift. It is the architecture underneath: headless business logic, a CLI over app state, a checkpointed review loop. All of it works on React Native too.
- Three widely used Shopify libraries are changing ownership on a published clock. For React Native shops that is a lockfile problem this week, not a philosophy debate.
What Shopify actually announced
The decision post is more careful than the commentary around it. Shopify says React Native “remains an excellent framework” and that the 2020 bet was “extremely successful”. Nothing broke. What changed is that by late 2025 the company concluded agents had become good enough at implementation, translation, testing and review that building a feature twice no longer meant doing twice the work. Once that holds, the central benefit of a shared codebase stops covering its own costs.
A companion post reports the numbers from the Shop app. Twelve weeks after the proof of concept, a rebuilt native app was live in the stores. Cold start fell from 3,200 ms to 2,466 ms on iOS and from 4,433 ms to 2,233 ms on Android. Session stability moved from 99.5% to 99.95%, a tenfold reduction in sessions that crash. The Android release build shrank by 109 MB, or 37%.
The argument we got half right
Our July post argued that the React Native versus Flutter performance debate was over, and that the real selection criterion had become AI agent ecosystem maturity: how much public code the agent was trained on. We used agents as a tiebreaker inside the cross-platform category. Shopify applied the same criterion and walked out of the category altogether.
We missed it because we were still treating cross-platform as a technical position. It never was one. It was an amortisation decision: write one implementation, divide it across two platforms, and the shared layer pays for itself out of the saving. Every serious argument for either framework reduces to that sum. Agents did not make the shared layer worse, they attacked the denominator. When the marginal cost of the second implementation drops far enough, the saving that justified the abstraction no longer covers the abstraction’s own upkeep, and every remaining property of the shared layer is a cost you are still paying.
One line in our July post has aged into the point of this one. We wrote that the real cost is “the five-year maintenance bill, not the twelve-week build”. Shopify’s from-scratch rebuild of a top-charting shopping app took twelve weeks. We named the twelve-week build as the thing not worth worrying about, and it turned out to be the variable that moved. The maintenance bill is still the right worry. It just got bigger, because there are now two of them.
The generalisable lesson is not about mobile. Most architecture decisions are priced decisions wearing technical clothes: build versus buy, monolith versus services, self-host versus managed. Each was justified by a specific price at a specific moment, and almost nobody writes that price into the decision record. When it changes there is no trigger to re-open the question, and the decision outlives its own justification. Shopify’s real achievement here is procedural. They noticed.
They did not build a native app. They built a testable one.
The migration runs through a system called Helix, which proposes small ordered checkpoints reviewable in minutes. Each must prove its behaviour with tests, match the running app visually, survive two adversarial reviewers and get human approval before the next begins. On the Shop app, plan acceptance was bound to a hash of the plan’s contents, so editing a plan invalidated its earlier approval. It is a small idea carrying real load: sign-off stays attached to what was actually reviewed.
The second piece is the one we would steal outright. Shopify found agentic mobile work was throttled by the simulator: agents change code in seconds, then wait minutes to see the result. Their fix is an architectural rule. Business logic is fully decoupled from the UI and runs headlessly on a desktop, exposed through a CLI that inspects state, navigates and acts in milliseconds. A companion tool captures events and screenshots from both the old and new apps at named checkpoints, so parity is diffed rather than eyeballed. Their own summary is the sentence to take away: it does not matter how good the model is if it cannot test its work quickly.
None of that is Swift-specific. Headless logic, a CLI over application state and machine-comparable parity captures are equally achievable in a React Native codebase. Shopify’s migration was fast because of the loop, not the language.
What does not transfer
Shopify employs hundreds of mobile engineers and can staff two platform teams indefinitely. That assumption sits underneath the whole decision, and most of our clients cannot meet it. Agents write Swift, but they do not carry a pager, own an architecture, or make the judgement call when a data migration goes sideways on a Friday. Shopify says as much: native expertise remained essential, because generated code satisfied requirements while introducing duplication, architectural drift and performance problems. The question is not whether an agent can produce a Kotlin screen. It is whether you can staff two platform on-call rotas for five years.
There is a subtler risk here. React Native enforced feature parity structurally: one codebase, and divergence was not expressible. Shopify now says parity will be maintained “through our development and release process”, which is a policy rather than a constraint, and policies decay under delivery pressure in a way compilers do not. Parity has to become an automated gate with a named owner, or it becomes a slow divergence that surfaces eighteen months later as two products.
If you are staying on React Native, this is a dependency event
Three libraries many React Native apps depend on are changing hands on a published schedule. React Native Skia is sponsored by Shopify to the end of 2026, after which William Candillon will fork it and publish under a new name, with the original repository archived. FlashList, at roughly two million downloads a week, gets critical compatibility fixes only while Shopify negotiates long-term stewardship elsewhere. Restyle is being archived, kept working to the end of 2026 and then unmaintained.
None of those break anything today, which is exactly why they will be missed. A maintainer transition is the part of a dependency nobody diffs: the version and package name are unchanged, and who is accountable for the next security fix is not in the manifest at all.
What to actually do this quarter
- Write the expiry condition into your decision records. Name the price that justified each decision and the threshold at which you would re-open it. A decision with no stated trigger outlives its reason.
- Audit your React Native dependency tree against the three ownership changes. Assign an owner and a date per library. End of 2026 is a real deadline for two of them.
- Build the feedback loop before you consider a migration. If headless logic and checkpointed parity captures do not pay for themselves on your current stack, they will not pay in Swift either.
- Price maintenance in people, not weeks. The build is now the cheap part. Ask whether you can fund two platform specialisms for five years before doubling your codebases.
- Re-run your own decision, do not copy Shopify’s. Their answer is correct for their headcount and tooling investment. The method transfers. The conclusion does not.
We are not retracting the July post. We simply assumed agents would settle an argument inside the cross-platform category rather than dissolve its premise, which is the shape of most AI-driven change we see in client work. REPTILEHAUS builds and maintains mobile and web products, and increasingly the work looks like this: auditing decisions that were correct when they were made, and building the tooling that decides whether a migration takes twelve weeks or two years. If you are weighing a cross-platform decision, or inherited one and are not sure it still holds, get in touch.
📷 Photo by Design Hills on Unsplash
