React Native vs native 2026: why Shopify went back

Shopify announced on 10 September 2026 that it is moving its mobile apps off React Native and back to separate Swift and Kotlin codebases. Anyone re-running the React Native vs native 2026 decision now has to account for the most-cited cross-platform success story reversing itself in public. The reason is not the one most people will assume. Shopify did not say the framework got slow, or that it failed at scale. It said close to the opposite, and rewrote anyway, because coding agents changed what a second codebase costs.

We build React Native apps for clients and we have published advice that leaned on Shopify as evidence. So this is worth reading properly rather than as a headline, because the transferable part of the announcement is not the framework verdict at all.

What Shopify actually said

The engineering post is unusually direct about its own reasoning. Shopify went all-in on React Native in 2020 for three stated reasons: stop building the same features twice, let developers work across the stack, and spend less time chasing feature parity. It says React Native consistently delivered all three, and that the ongoing investment in performance work, foundational fixes and framework upgrades was an acceptable trade.

React Native apps can be fast. Ours are. We are making this change because agents have reduced the advantages of sharing implementation, while the advantages of building for each platform remain.

That sentence is the whole argument. The 2020 decision rested on an assumption — that building twice means roughly twice the work — and Shopify says that assumption stopped holding. It has been using language models to build software since 2021, and by late 2025 the models were good enough to implement an Android feature using the iOS version as a reference, help developers contribute outside their primary stack, and hold parity between platforms through shared specifications, tests and review checkpoints. Native still costs two platforms; it is simply no longer the deciding factor.

Simon Willison's note on the announcement makes the same point more bluntly: the post gives full credit to React Native for the six years Shopify used it. Nobody is claiming the framework broke.

Twelve weeks, and the precondition nobody mentions

Shopify chose a greenfield rebuild over a gradual brownfield migration — the reverse of what it did moving to React Native — because agents are good at building a feature in Swift or Kotlin with the React Native version in front of them. The Shop app went from proof of concept to a fully rebuilt native app published in the app stores in twelve weeks. The Shopify app itself, with more than 300 screens plus widgets, an Apple Watch app, complications and Siri Shortcuts, is underway and due to ship later this year.

Twelve weeks is the number everyone will repeat. It is also the number most likely to be misread, because it is the output of a system, not of pointing a model at a repository. Shopify says one-shotting the migration does not work and produces a large quantity of unmaintainable code that cannot be shipped.

The precondition sits in the section on feedback loops, and it is an architecture decision rather than a tooling one. Agentic control of simulators was the bottleneck: agents change code in seconds but take minutes to test it, because reading app state means the accessibility tree or screenshots. Shopify's answer is that business logic must be completely decoupled from the UI and runnable headlessly on a desktop, exposed to agents through a CLI so they can iterate in milliseconds without touching a simulator. That is what lets an agent work autonomously for hours.

Most mobile codebases we are handed do not meet that bar. Business rules live in screen components, network calls are fired from view models that cannot be constructed outside a running app, and there is no way to drive a user journey except by tapping. A team in that position does not get a twelve-week rewrite. It gets the slop Shopify warns about.

Helix is the transferable part

The system Shopify built to prevent that is called Helix, and it is a review architecture rather than a code generator. A developer points it at a screen. Helix reads the React Native implementation and proposes a sequence of checkpoints — small, ordered slices reviewable in minutes. Then each checkpoint has to prove its behaviour with tests, match the running app under visual review, survive two adversarial code reviewers, and get a human's approval before it is committed and the next one begins. Feedback from every review is remembered, so the loop needs less supervision as the migration proceeds.

Read that as a general pattern and the framework question fades. Helix is an admission that the constraint in agent-assisted work is not generation, it is verification — the same conclusion we reached writing about how AI coding agent productivity moves the bottleneck to review. Shopify's response is to make the unit of review small enough that a human can actually do it, and to spend model capacity on adversarial review rather than on more generation.

Two adversarial reviewers is the detail worth stealing. A model asked to review code will usually approve it. A model briefed to find what is wrong with it behaves differently, and running two of them independently is cheap next to the cost of a bad screen reaching production.

What it costs the React Native ecosystem

Shopify maintained three of the most widely used libraries in the ecosystem, and the post is specific about each. React Native Skia stays sponsored through the end of 2026, after which William Candillon will fork it and publish under a new name, with the original repository archived once the transition completes. FlashList, at roughly two million downloads a week, keeps getting critical compatibility fixes while Shopify talks to companies about long-term stewardship. Restyle is being archived: kept working through the end of 2026, then unmaintained.

If any of those three are in your package.json, that is a dependency decision with a date attached, not industry news. It is the same shape of event as CodePush being retired, which we covered when teams had to find a new route for React Native OTA updates. Nothing breaks on a Monday. You simply stop getting fixes, and you find out at the next platform upgrade.

React Native vs native 2026: what we tell clients

Shopify's reasoning is sound and almost entirely non-transferable at mid-market scale. It holds when four things are true at once: the duplicated work is large enough to dominate your costs, you employ people who can review Swift and Kotlin properly, you have the review capacity and tooling to run something like Helix, and your business logic is already testable without a simulator. Shopify has all four. A company shipping a thirty-screen field-service app has none.

Notice which of those is the binding constraint. It is not the model. It is review. If every agent-written screen needs a senior engineer to read it line by line, two codebases cost two reviews, and the 2020 arithmetic returns unchanged. Shopify's advantage is that it built the checkpoint machinery first.

So our advice for a React Native app build has not moved: for a single product team shipping to both platforms, one codebase is still the cheaper way to reach a working app, and the framework's performance was never the reason to avoid it. What has changed is the honest ceiling. If an app is heading towards deep platform integration — widgets, watch apps, system-level extensions — the cross-platform layer is now a cost you are choosing rather than a cost you are avoiding, and it is reasonable to plan a native path earlier than you would have last year. The React Native versus Flutter comparison is unaffected by any of this; both sit on the same side of the line Shopify just crossed.

Three questions before you copy it

If the announcement has landed on your desk with a suggestion attached, these are the questions that decide it, in order.

• Can an agent exercise your business logic without a simulator? If not, nothing else in the Shopify post applies to you yet, and fixing that is worth doing whichever framework you keep.
• Do you have a review gate that scales past one senior engineer? Tests, visual comparison, adversarial review, then a human. Without it, more generated code makes things worse.
• Can you staff two platforms for the next five years? Shopify can. Hiring for Swift and Kotlin in most markets is harder and costlier than hiring for TypeScript, and that gap does not close because a model can write both.

Answer no to any of them and the 2020 arithmetic still describes your situation, whatever Shopify has done. Answer yes to all three and you are already running the kind of engineering organisation where the decision is worth revisiting on its merits.

The part we would act on immediately, independent of framework, is the headless architecture. Decoupling business logic from the UI and making it runnable from a command line is good practice that predates agents by twenty years, and it is now the thing that determines whether agents are useful to you at all. That is worth doing this quarter. If you want a second opinion on where your mobile app architecture sits against that bar, we are happy to look.