On September 10, Mustafa Ali wrote on the Shopify Engineering blog that Shopify is dropping React Native for its major mobile apps and rebuilding them in Swift and Kotlin. That’s the news. The reasoning is the actual story.
React Native didn’t get worse
Shopify doesn’t claim React Native slipped. They say the math no longer holds: coding models have gotten dramatically better, and for their apps and their team, building the same feature twice — once in Swift, once in Kotlin — no longer carries the cost it used to.
That cost is what the entire cross-platform case rested on. One codebase instead of two, one team instead of two, one feature instead of two. Halve that number and you halve the argument.
Shopify names three things their agents have been able to do since late 2025: implement a feature on one platform using the other as reference. Help developers work outside their own specialty, so the iOS person gets further in the Kotlin code than they would alone. And hold platform parity through shared specifications, tests and review checkpoints rather than through shared code.
The evidence they offer is the Shop app: from concept to the App Store in twelve weeks, with AI assistance. Shop has already shipped native, the Shopify app is underway for a 2026 release, and the rest follow.
Three libraries lose their sponsor
This is the part that reaches past Shopify. They didn’t just use React Native, they paid for large chunks of its ecosystem:
- React Native Skia stays sponsored through the end of 2026. After that the repo gets archived. William Candillon will fork it and republish under a new name.
- FlashList has two million downloads a week. Shopify will fix critical issues only and is looking for someone to take long-term stewardship.
- Restyle is being archived, maintained through the end of 2026, then unsupported.
Two million weekly downloads for a list nobody maintains is the real risk in this announcement. Not for Shopify — for everyone else.
What’s new about this
We’ve read a lot lately about agents writing code, fixing tests and doing reviews. All of that is work inside an architecture that was already decided.
This is different. An architectural decision made ten years ago on cost grounds is being reversed because the costs moved. It’s the first large reversal of this kind I’ve seen, and the logic is uncomfortably clean: when duplicated work gets cheap, every abstraction whose purpose was to avoid duplicated work loses value.
You can follow that thought further, and I’m not sure I like where it lands. Cross-platform frameworks are one case. Shared libraries, monorepos, generic layers built for two situations instead of two concrete solutions — a lot of that exists for the same reason. Take Shopify’s reasoning seriously and you have to ask the question again at every one of those places.
Two caveats belong with it. Shopify has a large mobile team, a lot of users and money for a rebuild like this; the math looks different with three developers and one app. And shared code doesn’t just save typing, it keeps behavior in sync. Specifications and tests can do that too, but someone has to maintain them, and that work doesn’t appear in Shopify’s math.
Sources: Shopify Engineering: Back to Native, Simon Willison