Shopify argues the original justification for React Native was purely economic — avoiding writing every screen twice across iOS and Android. Now that coding agents can port a screen from Swift to Kotlin in an afternoon, the shared-codebase savings no longer offset the costs of a JS runtime, bridge overhead, and an abstraction that fits neither OS well.
The editorial frames React Native as a headcount pitch dressed up as a technology pitch, with everything from Hermes to Fabric existing to make that headcount trade tolerable. Once agent-assisted porting drops the cross-platform tax from a quarter of engineer time to an afternoon, the entire trade-off collapses.
An iOS engineer expresses vindication after years of pushing back against executives who fixated on shared-codebase savings. They read Shopify's reversal as confirmation that the cross-platform pitch was oversold to non-technical leadership and that platform-native development was worth defending all along.
The editorial emphasizes that Shopify was the reference customer framework proponents cited whenever anyone questioned whether React Native could scale — powering the merchant app, POS, Shop, and internal tools. With that reference customer gone, the social proof underpinning enterprise React Native adoption takes a significant hit.
Shopify published a post titled *Back to Native* on its engineering blog, announcing that its mobile apps are moving off React Native and back to Swift on iOS and Kotlin on Android. The framing is unusually candid: the company says coding agents changed the cost structure of mobile development twice — first by making the RN bet look expensive to unwind, and then by making the unwind cheap enough to actually do.
Shopify was, until this week, one of the largest and most visible React Native shops in the industry. It went all-in in 2020, shipped its flagship merchant app, POS, Shop, and internal tools on the framework, and became a reference customer that framework proponents cited every time someone asked whether RN could scale. That reference customer is now gone.
The post doesn't lead with performance complaints or bridge bugs — the usual RN grievances. It leads with an economic argument: the reason to share a codebase across iOS and Android was to avoid writing every screen twice. If an agent can port a screen from Swift to Kotlin in an afternoon, the shared codebase stops paying for itself, and you're left with the costs — a JavaScript runtime on the device, a bridge, and an abstraction that never quite fits either OS.
The React Native pitch has always been a headcount pitch dressed up as a technology pitch. Two platforms, one team, one codebase. Everything else — Hermes, the new architecture, Fabric, TurboModules — was in service of making that headcount trade acceptable. The moment porting between platforms costs an afternoon of agent time instead of a quarter of engineer time, the trade collapses.
Community reaction on Hacker News was blunt. One iOS engineer wrote: *"As an iOS Engineer that has been fighting the battle against every C-level type who brings up the subject of a shared codebase my whole career, I feel very validated."* Another commenter, who describes himself as making his career shipping React since 2013, was harsher: *"Sorry not sorry RN was always the wrong choice… Every RN project I've had to join has been a junk show."* A third reported porting his own smaller RN app to native in a single overnight session with Codex — inventorying every screen from the RN source, generating iOS and Android equivalents, then spending a few days on polish.
The anecdotes matter because they generalize. If a solo developer can port 15–20 screens overnight, a company with real engineering capacity can port a real app in weeks. That's the number that makes Shopify's move rational, and it's the number that should make every VP of Engineering with an RN app on their roadmap re-open the spreadsheet. The strategic question isn't 'is React Native good?' — it's 'is the reason we picked React Native still true?'
There's a second thread running through the discussion that's worth pulling on: team size. One commenter pointed out that Shopify employs roughly 3,000 engineers, versus ~60 for Chrome at launch in 2008 and ~150 for GTA V — including GTA Online. Whatever you think of the comparison, it lands on the same nerve as the RN reversal. Cross-platform frameworks, microservices, and mono-repos are all technologies that scale headcount horizontally. When the marginal cost of a screen, a service, or a port drops toward zero, the org chart that justified them starts looking overbuilt.
The last thing to note: Shopify isn't saying RN was a mistake. It's saying the cost curve changed. That's a more honest framing than most postmortems, and it's the framing worth stealing. The 2020 decision was correct for 2020's costs; the 2026 decision is correct for 2026's costs; the mistake would be treating either as permanent.
If you're running React Native in production, don't panic-migrate. Shopify has 3,000 engineers and a merchant app that hits every native API the OS ships; your calculus is not their calculus. The question to run is whether the *specific* reason you chose RN — headcount efficiency, hire-any-web-dev, single design system — is still binding in a world where an agent can maintain two codebases in parallel. If yes, stay. If no, start planning.
If you're greenfield and about to pick a mobile stack, the honest answer just got messier. RN, Flutter, and Expo all optimize for the shared-codebase economics that agents are eroding. Native + agent-assisted parity is a real option now in a way it wasn't 18 months ago. It's not obviously *better*, but it's no longer obviously *worse*, and that's a big shift for a decision that used to have a default answer.
And if you're on a native team that's been fending off *"why don't we just use React Native"* meetings for five years — congratulations, the meeting is over. Save the blog post.
The interesting frameworks-response question is what Meta does. React Native's roadmap has been aggressive — the new architecture, Hermes improvements, better tooling — but every one of those investments is a bet that developers want a JS runtime on the device. If the market decides it wants two native codebases kept in sync by agents instead, RN's answer has to be more than a faster bridge. Expect the next 12 months of cross-platform framework pitches to lean much harder on *"agents can't do this yet"* — and expect that claim to age quickly.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.