Shopify Left React Native. The CLI Is the Reusable Part.

Shopify is rebuilding all four of its major mobile apps, Shopify, Shop, Point of Sale and Inbox, in Swift and Kotlin. Mustafa Ali, the director of engineering who announced it, does not say React Native was too slow. He says coding agents changed what it costs to build the same app twice.

The announcement landed on September 10 in two engineering posts published the same day. The one everyone read is Ali's, headlined "Native is now the future of mobile at Shopify". The one most of the coverage skipped, a companion post on the Shop app migration by Max Da Silva, Jason Kim and Quique Fagoaga, carries the numbers.

This is not a routine stack decision, because Shopify was the most-cited enterprise proof that React Native scales. In January 2025 the same Mustafa Ali published "Five years of React Native at Shopify", reported sub-500ms P75 screen loads, committed to co-captaining React Native releases and sponsoring React Native Skia and Reanimated, and signed off with: "If you haven't tried using RN in a while, now would be a good time to revisit it."

Twenty months later he is migrating off it. The 2026 post does not dodge that. "In January 2025, I wrote that the future of React Native was bright and that Shopify planned to keep investing in it," Ali writes. "That was true based on what we knew then."

Two arguments sit inside that post, and they are not equally supported. One is about how to structure a codebase so agents can work on it quickly, and Shopify gives away enough detail to copy it. The other is about money, and it rests on a single twelve-week migration.

Shopify's own post says React Native is fine

The framing that spread fastest over the weekend was that React Native is finished. The post itself says the opposite, in a sentence that is hard to misread:

"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."

Elsewhere in the same post, React Native "was working well for us, and it remains an excellent framework," and Ali thanks Meta's React Native team "for being excellent stewards of the framework."

The project's own activity agrees. Checked on September 13, React Native's repository (now `react/react-native`, redirected from the old `facebook` org) had been pushed to that same day, with v0.88.0-rc.0 tagged on September 8 and stable releases running roughly every two months through 2026 (0.84 in February, 0.85 in April, 0.86 in June, 0.87 on August 11). React Native Reanimated, maintained by Software Mansion rather than Shopify, pulled 6,251,151 npm downloads in the week of September 5 to 11. Neither reactnative.dev/blog nor expo.dev/blog has published any response to Shopify at all as of September 13.

What the departure removes is the best sales argument React Native had in one specific conversation, the one where a platform team has to convince a skeptical VP that a serious company ships a serious app this way. That is a genuine loss for React Native. It is not a technical verdict on the framework, and Shopify went out of its way to say so.

Agents write code in seconds, then wait minutes to find out if it worked

Ali's diagnosis of the problem has nothing to do with Swift:

"Agentic control of simulators has been a bottleneck. We found ourselves constantly babysitting them as they couldn't reliably build, test, and iterate. We built tooling to allow agents to reproduce bugs, fix them, and verify the fix autonomously but it was slow and brittle. React Native's hot module reload helps the situation but it doesn't solve it, due to simulator control being slow. This is primarily due to reliance on the accessibility tree, or screenshots to get the state of the app, take actions, and verify results. Agents can make code changes in seconds, but it takes them several minutes to test the output."

The bottleneck is verification latency. An agent loop runs at the speed of its slowest step, and on mobile that step is asking a simulator what the app currently looks like, either by scraping an accessibility tree or by reading pixels off a screenshot.

Shopify's fix is architectural: "business logic should be completely decoupled from the UI and be able to run headlessly on desktop. We then make it available to agents via a CLI that allows them to iterate on it in milliseconds instead of minutes without involving simulators." The CLI, per the post, lets agents "inspect the state of the app, navigate between different sections, and perform actions all without needing to touch the UI," which "allows agents to work autonomously for hours at a time." When a simulator genuinely is needed, the CLI drives it by command rather than by reading its layout.

None of that is language-specific, and Shopify all but says so: hot module reload was not the missing piece, because compile time was never the problem. A React Native team can build the same thing today. Push the business logic into plain TypeScript modules with no React or React Native imports, run them under Node behind a thin CLI, and let the agent drive state transitions headlessly. It is arguably easier to do in React Native than in Swift, since the logic already lives in a language with a fast headless runtime and nothing resembling a simulator in the path.

It is also a restatement of something much older. Decoupled business logic, headless execution, deterministic state inspection and a machine-drivable interface are what people have called testable design for about thirty years. The payoff changed. The prize used to be that CI finished sooner; now it is that an agent can run thousands of unattended iterations overnight. Agent-friendly architecture and testable architecture turn out to be close to the same thing, which is the cheapest piece of good news in the announcement.

Every checkpoint needs tests, two adversarial reviewers and a human

Shopify is blunt about what happens if you skip the review machinery:

"It's tempting to just point an LLM to the React Native codebase and try to one-shot the same features in native, but it doesn't work. Even if you ask it to gather as much information as it can up front, freeze that into specs, task files, and then implement it, you end up with a huge amount of unmaintainable code that can't be shipped."

So they built Helix, which breaks a screen into ordered checkpoints. Per the post, each checkpoint "must prove its behavior with tests, match the running app in a visual review, survive two adversarial code reviewers, and get a human's nod before it's committed and the next one starts." The Shop app team added a detail worth stealing outright: "Plan acceptance was tied to a hash of its contents: changing a plan invalidated its previous acceptance." They also built Tardis, a debugging tool giving agents structured access to live app events, logs and state.

The CLI makes generation cheap. Helix exists because cheap generation produces work that cannot be shipped. The cost did not disappear, it moved from writing code to reviewing code, and Shopify pays for the loop in human review capacity. The migration post concedes this directly: "Native expertise remained essential. Generated code could satisfy feature requirements while still introducing duplication, architectural drift, or performance problems."

Helix, Tardis and the CLI are all internal and unreleased. Shopify promises deeper dives; none exist yet. The reproducible part of this story is the principle, not the toolchain.

Twelve weeks from proof of concept to the App Store

The economics claim is the one being repeated everywhere, usually in a harder form than Shopify stated it:

"Native still means building and maintaining software on two platforms, that cost has not disappeared. What changed is that agents can now do enough of the implementation, translation, testing, and review work that it's no longer the deciding factor it was in 2020."

Note the hedge. Shopify does not say the duplication cost is gone, only that it is no longer decisive. Coverage rendering this as "AI killed cross-platform" is overreading the source.

The evidence is one app. A single engineer spent a week with coding agents proving a feature-for-feature SwiftUI migration was possible, then six core engineers built the native foundations and main journeys, with feature teams joining midway. Twelve weeks from proof of concept to a shipped App Store release.

Shopify did publish real measurements, so anyone claiming there are no numbers has not read the second post. This is the full table from the Shop app migration:

Android carries the announcement. On iOS the app got 1 MB bigger, the release build time did not move, and 2,466 ms from tap to first home feed content is not a fast cold start by any standard. Android's 293 MB React Native release build is also unusually large, which raises a question about how optimised the baseline was that Shopify does not answer.

The stability line needs the same care. Going from a 0.5% crash rate to a 0.05% crash rate is indeed a 10x reduction, but both figures are stated with a plus sign, so the true improvement could be considerably smaller. There is a wrinkle underneath it too: the January 2025 post described Shopify's apps as ">99.9% crash-free sessions" while the 2026 post puts Shop's historical stability at "99.5%+". These may well be different metrics on different apps, and Shopify does not define either. It is a question about metric consistency, not a caught contradiction.

The comparison is confounded as well, by Shopify's own admission. From the migration post: "we also used the migration to simplify the app, deliberately retiring some screens and streamlining others." A native app with fewer screens that starts faster and ships smaller than the React Native app it replaced is not a clean language-to-language measurement. The simplification is disclosed; its scale is not.

What is genuinely absent is the other half of the ledger. No defect, regression or parity-failure counts. No cost figures of any kind: no engineer-weeks beyond "six," no inference or compute spend, no review hours. And no counterfactual, which is the one that matters most. The Shop team's trigger was that they were about to adopt React Native's New Architecture anyway, work that "would have required us to revisit native module integrations, rendering, and the boundaries between shared and platform-specific code." They never say what that alternative investment would have cost. Without it, "agents absorb the duplication cost" is an anecdote rather than an economic claim. (TechCurrent analysis: since New Architecture adoption is framed as the work they chose not to do, the React Native side of that comparison table is almost certainly pre-New-Architecture. Shopify does not state the baseline.)

Shopify is honest that the proof is not in yet. "We'll measure that through product velocity, app quality, and how much work agents can complete autonomously." Future tense. Every metric that would actually test the economics claim does not exist.

The accurate criticism is not that Shopify published no numbers. It published output numbers and no cost numbers. Everything in the two posts describes what the rebuilt app does; nothing describes what the rebuild took. Twelve weeks tells you how long something ran, and nothing about what it cost when the inputs are six senior engineers, an unreleased agent harness and a company that has been shipping LLM-written software since 2021.

Shopify is handing off Skia, FlashList and Restyle

This is the part with immediate consequences for other people's apps, and the terms differ for each library.

React Native Skia gets the softest ones. Shopify sponsors it through the end of 2026, William Candillon will keep working on it, and he "will fork the repo in the coming months and start publishing the library under a new name. The original repo will be archived when this transition is complete." Shopify adds: "If your app relies on this library, please consider sponsoring it."

FlashList is in limbo. Shopify "will continue to fix critical issues that break compatibility" and is "currently in discussions with several companies about taking on long-term stewardship."

Restyle is finished: "we're archiving this repo. We'll keep it working through the end of 2026, then stop maintaining it."

A TechCurrent check of the repositories and the npm registry on September 13, three days after the announcement, found none of that reflected anywhere a developer would see it. None of the three repos is archived. No README on any of them mentions archival, forking, stewardship or the end of maintenance. None of the three npm packages carries a deprecation flag. None has a `funding` field in its npm metadata. And there is no GitHub Sponsors profile at github.com/sponsors/wcandillon, so the sponsorship call to action currently has nowhere to land.

Run `npm install @shopify/restyle` today and you get a package whose README still promises to help you "build a consistent, themed UI in minutes," with no signal that maintenance stops at the end of the year. Shopify wrote that it is "committed to making sure this is a smooth transition with no surprises," and it is very early, and the post promised updates "along the way." But as of now the announcement lives in a blog post and not in the dependency graph, which is the only place most developers will ever look.

The Skia fork is also further behind than the reaction suggests. wcandillon/react-native-skia exists and was pushed on September 13, and Candillon also has a `react-native-skia-binaries` repo for prebuilt binaries that was pushed the same day. Neither is new: the fork was created in October 2022 and the binaries repo in February 2026, both well before the announcement, so their existence is not evidence that the handover has started. The rename has not happened, and Shopify's repo is still where the work lands: Candillon committed the Skia m154 upgrade there on September 13, three days after the post. Anyone writing "Skia has forked" in the past tense is ahead of the facts.

Restyle deserves the opposite correction. Calling its archival fallout overstates what happened. Its last release, v2.4.5, shipped on March 19, 2025, eighteen months before Shopify announced the archival. Its last substantive commit to the default branch was a README link fix in August 2025. And issue #311, "Is This Project Still Maintained?", opened on February 7, 2025, is still open, with two replies, neither from anyone affiliated with the repo. The archival is a death certificate. It is also the first thing Shopify has said publicly to Restyle's roughly 90,000 weekly installs since that last release in March 2025.

Which library is actually at risk is the reverse of the panic, and you can read it off the contributor graphs. Skia is effectively two people, with Candillon at roughly 2,080 commits across two accounts and the second contributor, `chrfalch`, at 1,313, and the person doing most of the work is the one taking it with him. FlashList is the exposed one: 1,440,841 downloads in the week of September 5 to 11, a single dominant human contributor at 435 commits, and a second-largest contributor that is Dependabot at 229. That is exactly why Shopify is shopping it to companies rather than handing it to a person.

Reanimated is the counter-example. Software Mansion is a consultancy whose business is React Native, so its incentive to maintain the library does not evaporate when a product decision somewhere else changes. Skia and FlashList were maintained because Shopify shipped apps that used them. That difference, rather than download counts or stars, is what decides whether a library outlives its sponsor.

The practical read for a team shipping on these right now, with npm figures for the week of September 5 to 11, 2026:

Nothing breaks on Shopify's calendar. These libraries keep working on the React Native version you are on today. The risk is the next React Native upgrade, when an unmaintained library stops compiling and nobody's job description includes fixing it. That clock is set by React Native's release cadence, roughly every two months, with 0.88 already in release candidate. It is the same bind as any deprecation clock somebody else sets: someone else picks the date and you do the work.

One more thing the coverage missed: `Shopify/react-native-performance` is already archived on GitHub, and its last push was November 25, 2025, nearly ten months before this announcement. (GitHub does not expose the date a repository was archived, so the last push is the closest marker available.) The 2026 post does not mention it. Tophat, named in the January 2025 post as one of Shopify's contributions, is not mentioned either, and its status is unstated.

Shopify bought Tailwind, then divested three libraries a day later

The day before the native announcement, Adam Wathan announced that Tailwind Labs is joining Shopify, to give Tailwind "a stable long-term home where it will be actively maintained for the millions of people who depend on it." His stated reason for the fit: "Tailwind is a load-bearing very important part of the stack at Shopify." Everything stays MIT-licensed; on the commercial side, existing Tailwind Plus and ui.sh customers keep access while new signups close. Terms were not disclosed.

Twenty-four hours later the company began handing off three libraries that are no longer load-bearing at Shopify. Both decisions turn on the same question: does Shopify still run this in production. None of that makes Shopify a bad open source citizen. It behaved better than most, giving notice, funding Skia to the end of 2026, actively shopping FlashList for a steward and offering handover help on Restyle. The problem is structural. Stars, download counts, a responsive maintainer and a corporate logo tell you nothing about whether the sponsor still depends on the code, and from outside the sponsor that dependency is invisible.

54% of surveyed React Native users work at companies of 50 or fewer

Cross-platform was never mainly a performance pitch. It let one team ship two platforms, which matters most to the people who cannot staff two mobile platforms in the first place.

That is a large share of the users. In the State of React Native 2025 survey, the company size question has a base of 906 respondents, and 879 of them picked a size bracket. By TechCurrent's count of those 879: 359, or 40.8%, work at companies of 20 people or fewer, and 476, or 54.2%, at 50 or fewer. A majority of the surveyed React Native population works somewhere smaller than the Shop app's core migration team plus the feature teams that joined it. The same survey's residence question shows how thin the tail gets outside the usual centres: the United States leads with 103 respondents, then India at 78, Poland 75 and France 63, with Brazil at 32, China at 10 and Nigeria at 9. The survey is self-selected and English-language, which systematically undercounts exactly those markets, so treat it as a floor rather than a measurement.

Shopify's answer to "you now have to build twice" is that agents will do enough of the second build. Its own preconditions are worth reading closely. Helix requires per-checkpoint tests, a visual review against the running app, two adversarial code reviewers and a human approval, and the migration post says plainly that native expertise remained essential because generated code introduced architectural drift and performance problems. That means reviewers who can tell whether the Swift is any good, which is the expensive part and the part that does not parallelise. A team with those people on both platforms probably would not have chosen cross-platform to begin with. Then there is the tooling: infrastructure Shopify built and has not released, plus Macs and Xcode for everyone who touches the iOS app. And there is inference spend for agents running "autonomously for hours at a time," a line item Shopify publishes no figure for, and the largest unstated variable in the economics claim. A team paying per token in a market where engineer salaries are low and API prices are not is working with a completely different ratio, as our cost math on agent loops laid out earlier this month.

For a small team the duplication cost did not go away. It turned into review and verification capacity, which is harder to buy than engineering hours. The other half of Shopify's post costs that team nothing: putting business logic behind a CLI that runs headlessly is a weekend of refactoring, it works fine in React Native, and it buys the same loop speed Shopify describes. Both things are in the same blog post. The coverage picked up the expensive one.

One line from the January 2025 post reads differently now. Listing React Native's downsides, Ali wrote that the framework "is not as comprehensive compared to native, so you end up having to use more 3rd party libraries," which "adds the overhead of keeping them up to date on an ongoing basis and increases the surface area of supply chain attacks." That surface is not theoretical: the npm worm that ran in August travelled through ordinary dependencies and persisted through AI coding agent hooks. He was describing a risk Shopify has now handed to everybody else.

Shop was the smaller app. The harder test is the Shopify app: 300 or more screens, home and lock screen widgets, an Apple Watch app, complications and Siri Shortcuts. Shopify says that migration is "underway and will ship later this year." Nothing has been published about it yet.

“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.”

Reporting by TechCurrent Staff · TechCurrent