Shopify is moving from React Native back to Swift and Kotlin
TL;DR
Shopify is rewriting all its mobile apps from React Native in Swift and Kotlin. It went all-in on React Native six years ago. Shopify says coding agents now do enough of the porting, testing and review. So building every feature twice no longer costs what it did in 2020.
The article
- Shopify adopted React Native in 2020 to stop building features twice, let developers work across the stack and stop chasing parity. It says the framework delivered all three. Its React Native apps are fast. Speed is not the reason for leaving.
- Prototypes in late 2025 showed agents could build an Android feature from the iOS version, and the reverse. Agents could also keep the platforms in step through shared specs, tests and review checkpoints. Native still means two codebases. But that cost no longer decides the question.
- Shopify chose full rewrites over gradual migration. The Shop app went from proof of concept to a native release in 12 weeks. The main Shopify app, with more than 300 screens, widgets and an Apple Watch app, ships later this year.
- Pointing an LLM at the React Native code and one-shotting the port produced code Shopify could not ship. Its in-house tool, Helix, instead splits each screen into small checkpoints. Each checkpoint must pass tests, a visual comparison with the running app, two adversarial AI reviewers and a human sign-off.
- Agents took minutes to test each change through simulators. So the new apps keep business logic apart from the UI. That logic runs headlessly on desktop, behind a CLI that agents can drive in milliseconds.
- Shopify will sponsor React Native Skia through 2026. Its creator will fork it under a new name in the coming months. Shopify is looking for a company to take over FlashList. It will keep Restyle working through 2026, then stop maintaining it.
Why it matters
Mobile leads weighing their own cross-platform stack should read the original, along with the linked Shop app migration post. The summary drops the full plans for each open-source library and the demo clips of Helix and the agent CLI. It also drops the acknowledgements, which show how much Shopify put into React Native.
The discussion
A huge, split thread. Developers who had already ported apps with agents mostly cheered. Mobile veterans asked who will understand and maintain two generated codebases, and many pointed out that the post gives no cost or quality numbers. The top thread went off topic on whether Shopify needs 3,000 engineers at all.
Ports that worked, and code nobody can vouch for
Several commenters had made the same move, one porting a 15 to 20 screen app overnight with Codex. One company shipped a planned nine-month port in three months with a fifth of the staff, and a patient app took two months. Skeptics said you can't judge agent code in Swift or Kotlin without knowing them, and tapping through the app misses race conditions and silent bugs. A professional Android developer gave the sharpest example of agent code that works but shouldn't exist.
In case of my company, the port was planned for this year, with a 9 month timeline and about 10 FTE team. It ended up being done in 3 months, with 2 engineers.
Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.
Parity is a long-run cost, and the post has no numbers
The most-cited critique said Shopify had proven only that rewrites got cheaper. Keeping two apps in sync costs more each year, and the post offers no data on hours, defects or agent spend. Others asked why agents couldn't improve the React Native code instead, since the CLI and headless logic would help there too. Defenders replied that agents can work on both codebases at once, and that Android and iOS users expect different navigation and design anyway.
Feature parity isn't an implementation cost. It's a divergence cost.
I'd expect it to be considerably easier for a few people to use the AI to improve React Native with whatever matters, than for every company in the world to permanently maintain two apps.
The React Native tax was the real reason
Many read the move as escaping painful upgrades, flaky libraries and the forced switch to React Native's New Architecture. Commenters cited the linked Shop app post as the missing evidence: startup 23% faster on iOS and 50% on Android, and ten times fewer crashes. A longtime mobile developer said cross-platform frameworks never cut headcount but only change what engineers work on. Some native iOS developers called it vindication, while a side debate pushed Kotlin Multiplatform or Rust for shared logic under native UIs.
The continued React Native tax of unnecessarily difficult upgrades, impedance mismatch w/ underlying core frameworks, and incredibly uneven library quality just cause your business to really spend a lot of time shepherding the tech over the finish line.
What ends up happening is that teams start as 20 iOS engineers & 20 Android engineers. They adopt something like React Native. Then you end up with a team of 20 product engineers and 20 tooling and framework engineers.
Losing over-the-air updates
React Native users said the post skips its biggest practical advantage, which is pushing JavaScript fixes to users without waiting for App Store review. One developer who manages about 20 apps logged review times climbing to several days. Others noted Apple's guidelines technically forbid downloading code that changes features, and native developers said slow releases push teams toward more careful testing. Some pointed to OTA tools for native code, such as Cash App's Zipline.
Nobody is talking about the real advantage of RN: Being able to release to the App Store without having to go through a review. That's so massive.
I just ran an analysis of my apps and the fastest was 8hrs (June 20th) but since then it's been trending upwards with my last 3 updates coming in at 40hrs, 67hrs, and 98hrs.
Does Shopify need 3,000 engineers?
The top comment, citing chatbot numbers, said Shopify had overcomplicated a simple app, setting its 3,000 engineers against Chrome's 60 at launch. Replies noted that Chrome 1.0 was Windows-only and missing basics, and that most Shopify engineers work on payments, tax and compliance, not the app. A smaller camp agreed big companies grow headcount for political reasons, and the thread wandered into complaints about Spotify.
When Chrome 1.0 came out in 2008, it only ran on Windows, and it couldn't do basic things like print or export to PDF, didn't have any accessibility, didn't work in RTL languages, and didn't have any graphics acceleration, among other limitations.
I suspect the vast majority of Shopify engineers never touch the core Shopify experience, but work on the long tail of invisible things that are nevertheless considered important.
Consensus
Native apps give a better user experience when a company can afford them. Agents have made that cost much lower, at least for a company with Shopify's resources. For startups and small teams, most agreed, React Native, Flutter or a web app still make sense.
Dissent
A large minority thinks the case is unproven. Shopify shows no cost or defect data. Two agent-written codebases will drift apart and pile up bugs nobody understands. And the same agents could have improved the existing React Native apps instead.