Did AI Kill React Native? Starting with Shopify's Abandonment

Shopify's Pivot: From React Native Back to Native

Shopify, once the most prominent enterprise advocate for React Native, has announced it's dropping the cross-platform framework and returning to native development with Swift and Kotlin. The news sent shockwaves through the developer community.

Looking back, Shopify went all-in on React Native in 2020 and reaped real benefits: write once and reuse across platforms, enable developers without mobile backgrounds to contribute code, and escape the constant burden of chasing feature parity. Shopify engineer Mustafa Ali even wrote in a retrospective that React Native's future looked bright and the company would continue investing.

Then came the turning point. Shopify's official reasoning centers on one thing: coding models (LLMs) have gotten dramatically better. In their own words, "building the same features in Swift and Kotlin is no longer the decisive cost factor it was in 2020." When a core assumption changes, they were willing to re-evaluate their entire mobile stack from first principles.

They rebuilt portions of several core apps to validate the approach, and the results were striking: AI agents could implement Android features by referencing the iOS version and vice versa; they helped developers quickly get up to speed in their non-primary tech stack; and they dramatically reduced the cost of cross-platform feature parity through shared specs, tests, and review checkpoints. The Shop app was the first to complete migration — from proof of concept to App Store submission, the team did it in just 12 weeks with AI assistance.

The Three Letters Everyone Is Ignoring: OTA

Theo, the video creator and a longtime React Native advocate, argues that Shopify's narrative is overly fixated on "cross-platform reuse" — which was never React Native's greatest advantage to begin with. What's truly hard to give up is three letters: OTA (Over The Air updates).

The key is understanding what React Native actually is. It's not a web app, and it's not a replacement for native — it's "an instruction layer that controls how native elements render." Theo uses a kitchen analogy: native code is the skilled chef in the kitchen, and React Native's JavaScript layer is the person telling the chef what to cook. The App Store won't let you swap out the chef, but you can change the person giving orders at any time — that's the magic of OTA.

Why does OTA matter so much? Theo shared real data he saw at Twitch: at any given moment, more than half of users are running a version of the app that isn't the latest. He demonstrated live that his own phone had 54 apps with pending updates. This means you don't just have one iOS app or one Android app — you effectively have every version ever installed by users who haven't yet churned. Ship a bug, and even if you fix it an hour later, crash reports will keep rolling in for months or even years.

With native development, your only option is to resubmit and wait for Apple's review. With React Native and Expo, you can push a new JavaScript bundle to fix the issue, bypassing the lengthy review process entirely. Theo specifically notes that Shopify never heavily used Expo, which meant they missed out on a huge portion of the React Native ecosystem's dividends — as Jamin from Infinite Red put it: "If you use React Native without Expo, you end up rebuilding Expo."

---

The technical mechanics of OTA updates are worth unpacking. React Native apps run their business logic on a JavaScript engine (Hermes or JavaScriptCore), which operates independently from the native binary. App store review rules prohibit replacing compiled native binaries, but they do allow loading remote JavaScript bundles at runtime — and React Native's architecture fits that requirement perfectly. Expo's EAS Update (formerly expo-updates) and Microsoft's CodePush both exploit this mechanism to push new JS bundles to installed apps transparently, without going through App Store or Google Play review. This means a critical production bug can be fixed and pushed to all users within minutes, whereas an emergency native fix typically requires hours or even days of review before it reaches users. For high-frequency consumer apps, this hot-update capability directly impacts user retention and revenue — often delivering far more value than the engineering efficiency gains from "write once, run anywhere."

---

Where React Native Actually Falls Short

Theo doesn't shy away from listing React Native's real pain points — but the order is telling. Performance and bundle size, the most commonly cited complaints, don't actually make the core list.

On bundle size, there's an interesting data point: after Shopify migrated from React Native to native, the app got 1MB larger. The React Native runtime isn't bloated — a default Expo app sits around 20–30MB. What really inflates app size is localization files and large media assets; a handful of PNGs can double the size.

Theo identifies a few genuine pain points. First is library bloat, though he pins most of that on the chaos of CocoaPods packaging in Xcode rather than JavaScript itself. Second is the abundance of foot guns — he even states bluntly that "the average React Native developer is worse than the average native developer," because native is harder, React Native has a lower barrier to entry, and it's become the default choice for beginners, making those foot guns more visible. Third is the chaos of React Native as a moving target, where version upgrades are frequently painful. Fourth is the dependency on Meta — when Apple ships a new feature, you have to wait for Meta to support it or write a shim yourself.

The Meta Team Exodus: The Signal Actually Worth Worrying About

The deepest insight in the piece concerns the state of the React Native team itself. Theo poses a question: at Meta's peak, how many engineers were on the React core team versus the React Native team? The answer: fewer than 30 on the React/web side, but React Native once had over 300 — a near 10:1 ratio.

The reason makes sense: React Native has to expose nearly all of iOS and Android's native capabilities to a JavaScript layer through a single codebase, which is an order of magnitude harder than React's job of just handling the DOM. And the team was stacked with elite native developers — precisely because they cared so deeply about native quality that they didn't want a junior JavaScript developer from the ads team wrecking a production app, so they built the best native bindings possible.

But things have changed. Meta has been systematically disbanding its React and React Native teams, with talent like Lauren — a core engineer on the React Compiler — heading to companies like Cursor. A shrinking team with reduced investment means the extraordinary engineering quality we've relied on is quietly receding. The New Architecture is arguably the team's swan song delivered amid the turbulence, and now that it's the default option, it significantly improves bridging performance between the native and JavaScript layers.

---

React Native's "New Architecture" is important context for understanding the current ecosystem's health. The old architecture used an asynchronous JSON serialization bridge to pass messages between the JavaScript thread and the native thread — a design that made frequent cross-thread communication a performance bottleneck and made certain synchronous operations (like gesture handling and layout measurement) difficult to implement. The New Architecture's core innovation is replacing that bridge with JSI (JavaScript Interface), which lets JavaScript hold direct C++ references to native objects and call them synchronously, eliminating serialization overhead entirely. The accompanying Fabric renderer and TurboModules overhaul UI tree management and native module loading respectively. Starting with React Native 0.76, the New Architecture is enabled by default. This overhaul took the Meta team years to deliver and is widely seen as their magnum opus before the team began to shrink — leaving the community with a more performant and extensible foundation. Whether subsequent iteration can maintain that momentum depends on whether the open-source community and Expo can fill the vacuum left by Meta's retreat.

---

AI Has Collapsed the Barrier to Native Development

Theo's central thesis comes into focus: in the past, you had to use React Native in part because the native engineers Meta employed were simply better than what most teams could hire, and piggybacking on their work made your app better. But now, agents like Codex and others are equally capable on native code — the skills gap has been dramatically narrowed.

He backs this up with personal experience: he ported his React Native T3 Code app to both a UIKit version and a SwiftUI version using AI (primarily the Sol model), each build taking under three hours with an agent running in a loop. He admits he "didn't read a single line of the code," but the apps work great and are the tools he uses every day to write code.

This makes Shopify's "stumbling" confusing to him — he suspects they may have over-relied on OpenAI's models or immature computer use tooling. He also criticizes Shopify's migration system called Helix as over-engineered, arguing that making an app's data layer headless for agent testing is roundabout — Expo could have solved most of their problems directly.

That said, Theo acknowledges that even with AI narrowing the skills gap, he'll still miss OTA updates, still miss truly good list components, and will still have to endure the misery of Apple's development process. He even recounts a SwiftUI native navigation pitfall: the official navigation stack only supports swipe-back from the far left edge of the screen, while many users swipe from the middle — Apple's own Settings and iMessage don't use the official navigation stack for exactly this reason. It's another reminder that "the reliable native solution" can sometimes be the one that frustrates users most.

---

UIKit and SwiftUI represent two eras of iOS native development, and understanding the difference helps judge the difficulty of AI-assisted porting. UIKit is Apple's imperative framework from 2008, where developers explicitly manipulate view object properties and hierarchies to describe the UI. SwiftUI, introduced in 2019, is a declarative framework whose syntax closely resembles React — state-driven views, component composition — which is why developers with a React background often find SwiftUI easier to pick up. However, SwiftUI still has maturity issues: some complex layout behaviors don't match the documentation, older OS version support is limited, and as the navigation gesture example in the article shows, achieving certain "truly native" experiences still requires mixing in UIKit. AI generates SwiftUI code more reliably partly because SwiftUI's declarative patterns are structurally similar to the React/HTML code that dominates training data — which helps explain why Theo could complete his porting experiments with such a low barrier to entry.

---

Closing Thoughts: A Bet Worth Respecting

Theo ultimately views Shopify's decision as a valuable experiment. React Native itself was a bet — a group of brilliant people saw React's success on the web and boldly asked "what if we reinvented mobile development with it?" and it worked.

Shopify's current bet follows the same logic: if agents are so good at porting software, why not use them to migrate apps back to native? Theo emphasizes that he never considered "cross-platform" to be React Native's core value proposition, and doesn't believe native is inherently superior. React Native's essence was never "write once, run anywhere" — it was always "learn once, understand anywhere." Master React, understand how mobile apps should feel, and you can build great apps.

Whether you choose React Native or native, what truly determines app quality is whether anyone is willing to seriously test on both iOS and Android. Theo half-jokingly concludes that the best approach isn't which framework you pick — it's forcing someone on your team to actually use an Android phone as their daily driver.