Shopify picked React Native in 2020. In 2026 the cost of a rewrite fell far enough to flip the answer.

In January 2025, Mustafa Ali published a post on Shopify's engineering blog titled "Five years of React Native at Shopify." He concluded that the framework's future was bright and that Shopify planned to keep investing in it.

On 10 September 2026 he published the follow-up. Shopify is moving every one of its mobile apps (Shopify, Shop, Point of Sale, Inbox) from React Native back to Swift and Kotlin. The Shop app has already shipped as a fully native rebuild.

The main Shopify app is next and ships later this year. It has more than 300 screens, widgets, an Apple Watch app and Siri Shortcuts.

The interesting part is what did not happen. React Native did not fail. Ali says the 2020 bet "has been extremely successful," that the apps are fast, and that the framework "remains an excellent framework." Shopify thanks Meta's React Native team in the same post announcing its departure.

So why leave?

The 2020 decision had three inputs. One of them moved.

Shopify's 2020 case for React Native came down to three reasons. Ali repeats them:

1. Stop building the same features twice.
2. Allow developers to work across the stack.
3. Spend less time chasing feature parity and more time shipping value.

Every one of those is about the cost of building software twice. That cost decided the question in 2020. In exchange, Shopify accepted React Native's price: performance work, foundational fixes to the framework, updates and external dependencies. Ali called these trade-offs acceptable because the benefit was larger.

Then the deciding factor stopped being a factor. Shopify has used LLMs to write software since 2021. By late 2025, the models were good enough for the team to ask whether building software twice still meant doing twice the work.

They rebuilt several core parts of their biggest apps natively with agents and, in Ali's words, "were surprised by how well it worked." An agent could use the iOS version of a feature as a reference while implementing it on Android, or do the reverse. Shared specifications, tests and review checkpoints kept the platforms in step.

Ali is careful about what changed: "Native still means building and maintaining software on two platforms, that cost has not disappeared." Agents now do enough implementation, translation, testing and review that the doubled cost no longer decides the question.

Once that cost stops deciding the question, the old reasons to build natively still remain: closeness to platform capabilities, first-party tooling, and fewer framework and dependency layers between the code and the OS. None of those changed after 2020.

That is the whole argument. Nothing about the framework got worse. One line in the 2020 spreadsheet got cheaper. That line had been holding the answer in place.

Greenfield, because the agent can read the old app

The second decision is the one most teams get wrong. Shopify made the opposite choice from last time.

When Shopify moved to React Native in 2020, it went brownfield for some of its biggest apps. It migrated gradually, screen by screen, because a from-scratch rewrite would take years and freeze feature work. That was the correct call with humans doing the typing.

This time it chose greenfield, a rebuild from scratch, for three stated reasons. Agents can build a feature in Swift or Kotlin using the React Native version as the reference. The old codebase becomes a specification instead of a burden.

A clean slate lets the team drop constraints imposed by the old architecture. The prototypes also showed that coding agents could make the rebuild substantially faster than anything possible before.

The proof point is the Shop app. It went from proof of concept to a fully rebuilt native app published in the app stores in twelve weeks. Shop regularly sits at the top of the shopping category in both stores. That is not an internal tool.

The part that keeps it from being slop

The obvious move is to point an LLM at the React Native codebase and ask for the same features in native. Ali says plainly that this does not work. Even with an up-front pass that gathers everything into specs and task files, you get "a huge amount of unmaintainable code that can't be shipped."

Shopify's answer is a system called Helix. Its design principle matters for anyone trying this at any size: it does not expect the first output to be correct. It creates a loop where an imperfect attempt cannot move forward until it becomes a good result.

A developer points Helix at a screen. Helix reads the React Native code and proposes a sequence of checkpoints: small, ordered slices of work that can each be reviewed in minutes. Then it builds them one at a time. Every checkpoint has to:

• prove its behaviour with tests,
• match the running app in a visual review,
• survive two adversarial code reviewers,
• and get a human's approval before it is committed and the next one starts.

Feedback from every review is remembered, so the loop becomes more autonomous as the migration continues.

Read that list again and notice what it is. It is not a prompt. It is a gate. The model's job is to get through it. The team's job is to define what "through" means.

Checkly used the same structure earlier this month when Claude Code rewrote a service handling about 92 million messages a day from Node.js to Go. A black-box harness that replayed production data was the main acceptance criterion.

The agent ran overnight. The result, roughly 13,000 lines, shipped with zero incidents and 70% fewer pods. Different company and stack, same shape: the rewrite is cheap because the test of the rewrite already exists.

The bottleneck moved to the feedback loop, so they moved the app

The second thing Shopify had to change is less obvious from outside: the architecture of the apps themselves.

Agents could change code in seconds, but testing it took minutes. Testing a mobile app means driving a simulator. Driving a simulator means reading the accessibility tree or screenshots and clicking.

Shopify built tooling that allowed agents to reproduce bugs, fix them and verify the fix. It was slow and brittle. Ali's line: "It doesn't matter how good the model is if it can't test its work quickly."

The new apps are therefore designed for two kinds of user. Business logic is fully decoupled from the UI and runs headlessly on a desktop. A CLI exposes it. An agent can inspect state, navigate between sections and perform actions in milliseconds instead of minutes, with no simulator involved.

When a simulator is genuinely needed, the CLI drives it directly by command instead of inspecting the layout.

That is a real architectural cost paid up front. It also tells you what Shopify now considers the constraint. Model quality is not the constraint. Iteration speed is. They rebuilt the apps so agents could work on them for hours unattended.

Shopify says the migration's success will be measured partly by "how much work agents can complete autonomously."

What this costs the people who built on Shopify's choice

Shopify did not just use React Native. It shipped some of the React Native community's most important libraries. The post is honest about what happens to them.

FlashList, the default way to render high-performance lists in React Native, gets about 2 million downloads a week. Shopify will keep fixing critical compatibility issues and is talking to other companies about long-term stewardship.

React Native Skia stays sponsored through the end of 2026. Its author, William Candillon, will fork it under a new name, and the original repo will be archived. Restyle is being archived, kept working through 2026, then dropped.

If your app depends on any of those, the cost of Shopify's decision just landed on you. Remember that the next time a large company's technology choice looks like a safe default. It was safe until their spreadsheet changed.

Re-run your own 2024 decision

The transferable lesson is not "go native." Ali says explicitly that React Native was the right call for Shopify in 2020 and native is the right call now. A smaller team with one platform to serve may get a different answer from the same arithmetic.

The lesson is about the arithmetic. Every build-versus-buy and rewrite-versus-maintain decision you made before late 2025 includes a line for "the cost of writing this again." That line has fallen.

It fell at Shopify and Checkly. It also fell for Pieter Levels, who this week listed fourteen things he has replaced with his own code and AI: twelve SaaS products and two human services. He puts the saving at about $25,000 a month. The three cite different tools and stacks. They all cite the same changed input.

So the question is not which framework to use. The question is which of your standing decisions was held in place by that one number, and whether anything else in the reasoning has aged as badly.

For Shopify, nothing else changed, so the decision flipped. Yours may hold. But you will not know until you re-run it with the 2026 price.

Two conditions come first. You need the test to exist before the rewrite starts. Helix's checkpoints and Checkly's harness made the cheap rewrite safe. A team without either is buying speed with risk.

The new code also has to let the agent test it quickly. If verification still takes minutes, model quality will not save you.

Shopify is going to publish more on Helix and what it calls its agent-addressable architecture. Read those when they land. The React Native post from January 2025 is still up too, and it is worth reading first. It was right, and it still flipped.