▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=oPZLPUtmROo
• Original title :: Did AI kill React Native?

Shopify announced it is moving its mobile apps from React Native back to Swift and Kotlin, arguing that coding agents have erased the main reason it went cross-platform in 2020 - not building every feature twice. Theo, a long-time React Native defender who once publicly dismantled Airbnb's departure article, works through Shopify's post, agrees with the core premise, and then spends most of the video on what he thinks the announcement got wrong, what is genuinely weird about Shopify's situation, and why the more consequential story is Meta dismantling the React and React Native teams.

What Shopify said

The 2020 bet on React Native was successful: features built once, devs without mobile background contributing, no constant chase for platform parity. The cost was real too - significant effort on performance optimization, shoring up foundations in React Native itself, and keeping up with framework and dependency upgrades - but worth it. Shopify has used LLMs since 2021, and by late 2025 the models were good enough to question whether building software twice still meant twice the work. They prototyped core screens of their biggest apps in Swift and Kotlin with agents, found that agents could implement an Android feature using the iOS version as reference and vice versa, ramp devs up outside their primary stack, and hold parity cheaply through shared specs, tests, and review checkpoints. Native still means two platforms and that cost has not vanished - it just stopped being the deciding factor.

Open source fallout: React Native Skia gets forked and republished under a new name by William, its Shopify-employed maintainer, with the original repo archived after the transition. Flash List, now the default list in most React Native projects, keeps critical compatibility fixes while Shopify negotiates long-term stewardship with other companies. Restyle is archived outright.

They chose greenfield rewrites over the brownfield approach they used going into React Native, because agents make a clean-slate rewrite affordable. The Shop app went from proof of concept to a published App Store build in twelve weeks; the Shopify app, with 300 screens, widgets, an Apple Watch app, complications and Siri Shortcuts, ships later this year.

To keep the output shippable they built Helix, which refuses the one-shot spec-then-implement approach. Helix reads the React Native code for a screen, proposes checkpoints reviewable in minutes, and each checkpoint must prove its behaviour with tests matching the running app, pass a visual review, survive two adversarial code reviews, and get a human nod before the next begins. They also rearchitected around business logic fully decoupled from UI and runnable headlessly on desktop, exposed to agents via a CLI, because simulator control via accessibility tree and screenshots was too slow and brittle for agent loops.

Theo's objections

Two things he says Shopify's framing undersells. First, over-the-air updates, which he calls the three letters that make React Native hard to give up. Ship a bug and go native and your options are all bad: revert, eat the support cost, or wait on Apple review while a slow staged rollout trickles out. At Twitch he saw half or more of users sitting on a version at least two releases old; his own phone claimed zero updates available and then revealed 54 on a pull-to-refresh. Native means you do not have one app per platform, you have every version anyone has installed. His analogy: React Native is not an alternative kitchen, it is a recipe distribution system - same native chef, same native components, with a JavaScript layer telling it what to render. OTA swaps the recipes without touching the kitchen, which is what makes holiday-day-only features and same-hour bug fixes possible.

Second, Expo. Shopify was not using it heavily, and Jamon Holmgren's point is that if you run React Native without Expo you end up rebuilding Expo. Expo handles builds, OTA delivery, and - critically - dev clients: one dev suffers Apple's signing process once, everyone else scans a QR code. Theo is currently maintaining two native build configs for his own app and has a dev build missing features because Apple gates entitlements per machine. Expo also has good simulator and web support, which means the headless-CLI machinery Shopify built to let agents iterate is largely solving a problem Expo already solved - "wait till you have the whole app compiled for web". He calls Helix codebase worship and the CLI architecture criminally over-engineered for what are ultimately CRUD apps.

He is blunt about the real negatives, and performance is not among them. Library bloat is mostly the misery of Xcode packaging, CocoaPods, and native linking, not JavaScript. App size is a myth: Shopify's native rewrite shaved one whole megabyte, and a default Expo app sits at 20-30 MB - bloat comes from localizations and assets. The genuine problems are footguns (one bad useEffect hurts more on mobile, and React Native's accessibility to less experienced devs means "the average React Native dev is worse than the average native dev" - a consequence of winning, not of being bad), React Native as a moving target with rearchitectures and upgrades he now handles by deleting the lockfile and hoping, and dependency on Meta for exposing new platform features.

Why Shopify is a weird data point

Their native exploration coincided with React Native's New Architecture, which dramatically reduces bridging cost and is now the default. Shopify faced a choice between porting their substantial existing native code to the New Architecture or rewriting natively - which means their startup-time comparisons are against pre-New-Architecture React Native and are less informative than they look.

There is also Tobi Lütke. Theo repeats the claim that decisions like this get made unilaterally over a weekend and forced on the company - citing a two-week company-wide mandate to migrate React to Rails, reversed once Tobi learned about server components. Tobi replied, saying the real case was internal tools stuck in a self-inflicted headless-Rails-plus-GraphQL-plus-SPA architecture for about fifty users - "cosplaying an enterprise production app" - where plain Rails was the right answer. He acknowledges making calls like this routinely, usually because someone on the team asks him to be the bad guy, saving enormous change-management overhead ("founder mode as a service"), and notes he ran a decade-long internal podcast revisiting such decisions so people could learn to make them without him. Theo, who uses the same "tell me what to send and I'll send it" pattern with his own team, says the reply flipped him.

Theo's own ports, and what actually works

He has done this migration himself, three times, on T3 Code's mobile app. With leftover early-access tokens he told Soul to build a Swift version; it finished in about two hours and worked. A later attempt with Ultra plus Soul and Codex computer-use on a Mac Mini drifted into SwiftUI instead of UIKit, so he ended up with UIKit and SwiftUI ports alongside the React Native original. Each build took under three hours in an autonomous loop. The SwiftUI version is what he now uses daily for coding, roughly 95% Soul and the rest Astra, built in a single thread, maintained by watching his colleague's React Native commits and reporting them - he has not read a line of its code, and about a thousand people are on its TestFlight. His prompts are unremarkable: "any other changes on main worth pulling in?" produced an hour of autonomous work, several compactions, simulator testing, and a merged port. His read on Shopify's difficulty: old models, or Anthropic models, or fighting computer-use - if one part-time engineer can do this in a loop, a dedicated team should manage.

The ports were not free of pain, and the pain was native's. SwiftUI lists are terrible. Its NavigationStack supports the back gesture only from the leftmost quarter of the screen, with a non-configurable gutter - so users who swipe from the middle (which he confirmed by handing the app to an Android user at DEF CON, after wrongly concluding a colleague was the outlier) simply fail to go back. Apple's own Settings app does not use the native stack, because it wants to support every way of going back. He had to rebuild the navigation layer to match what users expect.

The real story: the React Native team

The performance case for React Native rests on the quality of the people who built it. Theo's estimate: React core, web, and everything else was under thirty engineers at Meta, while React Native had over three hundred - because exposing all of iOS, Android, and Quest's native surface to JavaScript is a far harder problem than giving you better DOM updates. That is why there is no good Svelte Native: you cannot replicate hundreds of millions of dollars of native binding work. And those were not JavaScript devs - they were the best native engineers he has met, people who loved the platform enough to make sure the worst new hire on the ads team could not make the native app worse. The question when choosing a stack was always: do you have better native devs than Meta? Now agents narrow that gap, and that is the argument he finds hardest to answer. Jay, author of Legend State and Legend List - whose JS-only virtualizer is fast enough that it ported to web, unlike the native-backed alternatives - maintains that React Native benchmarks faster than native, and that claim rests on the same foundation.

Which is why the team news matters more than Shopify's. Meta has been disbanding the React and React Native teams; people like the React compiler lead have left for places like Cursor and become industry-famous within months. The New Architecture landed as a swan song. React Native is not going anywhere - too much depends on it - but maintenance shifts toward agents, moving slower and less thoroughly, and the people who remain are demoralized watching decade-long colleagues vanish. Theo is explicit that this is not the team getting worse; it is that they are heartbroken and the work will no longer be revolutionary.

Takeaway

He is glad Shopify is making the bet - React Native itself was exactly this kind of bet, and big companies need to test whether agents can port real software. But he never claims multiplatform was the point, and rejects the idea that native is simply better. React Native's promise was never write once run everywhere, it was learn once understand everywhere: you did not need a new language, you needed to understand mobile. And whichever stack you pick, someone on your team has to daily-drive Android - or, if they already do, daily-drive an iPhone first so they learn how a phone is supposed to feel, then go back and fix your app.