Shopify argues that the core value proposition of React Native — one codebase serving two platforms with one team — depended on a cost ratio between TypeScript and Swift/Kotlin that no longer holds. With coding agents able to mechanically translate and maintain native code, writing two native codebases is no longer the 2x multiplier it was in 2018, eliminating RN's primary economic justification.
The editorial reinforces that RN was always sold on economics rather than quality — the honest pitch was 'good enough, faster, with one team.' Agents don't make Swift/Kotlin easier to learn but roughly double the volume of native code a team can maintain per headcount, which changes the calculus decisively.
Shared a firsthand experience running Codex against a 15-20 screen React Native app: an overnight agent run inventoried every screen and produced native Android and iOS ports, leaving only a few days of polish work. This anecdote supports Shopify's larger-scale claim that agents make the mechanical translation to native tractable.
The editorial emphasizes that this isn't a startup abandoning RN after a bad experience — it's the team that shipped a real business on it, contributed upstream, and gave conference talks defending it. Their departure signals a broader shift in the industry's cost-benefit calculation rather than an idiosyncratic complaint about bridge overhead or gesture jank.
Shopify's mobile engineering org published a post titled *Back to Native* announcing a migration off React Native and back onto Swift and Kotlin for its consumer and merchant apps. The framing is deliberate: this is the same team that spent years as one of the loudest, most credible enterprise references for React Native. They shipped a real business on it. They contributed upstream. They wrote conference talks. Now they're leaving.
The stated reason isn't the usual list of React Native complaints — bridge overhead, gesture jank, native module fragility — it's that coding agents changed the cost curve of maintaining two native codebases twice in eighteen months. The pitch that used to justify RN — *"one codebase, one team, ship to both stores"* — assumed a specific ratio between the cost of writing Swift/Kotlin code and the cost of writing TypeScript-that-compiles-to-both. That ratio has collapsed.
A commenter on Hacker News, sharing their own experience, described running Codex against a 15-20 screen React Native app: an overnight run inventoried every screen, produced native Android and iOS ports, and left a few days of polish work on top. Shopify's post makes a similar argument at a larger scale — that the incremental cost of a second native implementation, when a competent agent is doing the mechanical translation, is no longer the multiplier it was in 2018.
React Native has always been sold on economics, not on quality. The honest pitch was never *"this produces better apps than native"* — it was *"this produces apps that are good enough, faster, with one team instead of two."* That trade was defensible when hiring two senior iOS engineers and two senior Android engineers cost you $1.5M a year and you could get to 80% of the same result with three RN generalists.
Coding agents don't make Swift and Kotlin easier to learn — they make the *volume* of Swift and Kotlin a team can maintain per headcount roughly double what it was. That change hits RN's value proposition in exactly the load-bearing spot. If two native codebases now cost 1.3x what one JS codebase costs, instead of 2.5x, the tradeoff inverts. You get platform-idiomatic UI, first-day support for new OS features, no bridge, no Metro, no Hermes debugging, no `pod install` roulette — for a rounding-error cost premium.
The community reaction on HN split along predictable lines but landed in an unusually consistent place. An iOS engineer wrote *"I feel very validated"* about years of pushing back on shared-codebase pitches from executives. Another commenter, who describes himself as having *"made my money shipping React since 2013,"* said *"RN was always the wrong choice"* and that no RN project he'd joined operated more efficiently than two native teams would have. That's not framework tribalism — that's people who watched the actual staffing math play out and found it didn't add up even before agents existed. Agents just made the argument harder to duck.
The deeper subtext is about org design. Cross-platform frameworks aren't only technical bets — they're organizational bets that a single team structure is cheaper than two. Shopify's move implies that at their scale, with their agent tooling, two focused native teams now outperform one abstraction-layer team. That's a statement about coordination cost, not just compile targets. Notably, HN commenters spent as much time gawking at the fact that Shopify has 3,000 engineers (Chrome shipped with ~60, GTA V credited ~150 software engineers) as they did debating the framework choice. The size of the org is part of the story: at 3,000 engineers, you can afford two platform teams. At 30, you probably still can't.
If you're on React Native today, this is not a sign to panic-migrate. Shopify's move is a signal about where the economics are heading, not a claim that your app is broken. The interesting question is whether the *original reason* you chose cross-platform still holds. If you picked RN, Flutter, or Expo because you couldn't afford two native teams, that constraint is loosening fast — and the framework tax (bridge quirks, native module maintenance, delayed OS feature parity) is the same as it ever was, while the savings shrink.
If you picked cross-platform because your UI is genuinely uniform across platforms and you *want* pixel-identical behavior — say, a design-system-heavy internal tool, or something like a media app with a custom render layer — the calculation is different. You weren't buying it for the headcount savings; you were buying it for the enforced consistency. That value doesn't change.
The practical move for most teams: run the experiment Shopify's post implies. Take one non-critical screen from your RN app, point Codex or Claude Code at it with your existing design tokens and a target of native Swift/Kotlin, and see what falls out overnight. Two years ago that experiment would have produced compilable garbage; today it produces something a senior engineer can polish in a day. That's the data point that decides whether this migration is a Shopify-only story or a broadly rational move.
Budget-wise, the honest ratio for a mid-sized app in 2026 seems to be that a two-native-codebase team is now 1.2-1.5x the cost of a single RN team, not 2x-3x. If your CFO's spreadsheet still has RN penciled in at the old ratio, that number is out of date.
Expect a wave of quiet migrations off cross-platform frameworks over the next twelve months, mostly from companies large enough to have felt the friction and now large enough to fund two platform teams with agent leverage. Flutter will feel it too — same economic argument, same erosion. The frameworks that survive will be the ones that stop competing on "one codebase, less headcount" and start competing on genuine capability the platforms don't offer: hot reload workflows, design-system enforcement, or web-plus-mobile targeting where a native team genuinely can't help. Shopify going public with this migration gives every mobile lead the cover they needed to have the same conversation with their VP. Watch how many take it.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.