React Native After Shopify's Move

React Native after Shopify's move is still a defensible choice, but the reason to pick it has shifted. Shopify says AI coding agents now make building Shop in Swift and Kotlin cost roughly what building it once in React Native cost, so it is rebuilding natively. The framework's remaining edge is over-the-air updates, Expo tooling, and a deep bench of native bindings, not multiplatform code sharing.

React Native after Shopify's move: what actually changed

React Native after Shopify's move is best understood as a changed cost equation, not a framework failure. In 2020 Shopify went all-in on React Native, Meta's framework for building iOS and Android apps with React, and says the bet saved years of writing features twice. By late 2025 the company concluded that AI coding agents had cut the cost of maintaining separate Swift and Kotlin apps enough to reverse the decision.

Shopify renamed its native strategy openly: “Native is now the future of mobile at Shopify,” with a subtitle claiming coding agents “change what it costs to build mobile apps twice.” The company is not claiming React Native got slower. It is claiming the specific advantage it bought — one implementation instead of two — stopped being the deciding factor, because agents can translate, test, and review across platforms.

The framing matters because it separates two questions that get merged in the reaction. Whether React Native is technically capable is one question; whether sharing one implementation is still cheaper than two native implementations is another. Shopify answered the second one for its own apps, in 2026, with a specific workflow behind it.

Where AI agents changed the build cost

AI agents changed the build cost by absorbing the translation work between platforms, not by making native code cheap. Shopify says it has used large language models to build software since 2021, a year before ChatGPT launched, starting with feature implementation and bug fixes and later trusting them with reviews and larger changes. By late 2025 the company describes agents as capable enough to implement a feature on Android using the iOS version as reference, and the reverse.

That claim comes from a vendor describing its own program, so treat it as first-party evidence. It is still the strongest available account of how a large commerce company restructured mobile work around agents, and it lines up with what individual developers report about porting existing implementations. The mechanic is straightforward: when a working reference implementation exists, an agent is pattern-matching rather than designing.

The cost of maintaining parity now partly moves into specs, tests, and review checkpoints shared across platforms. Shopify's write-up lists those as the mechanism that makes native viable again, alongside shared specifications. React Native's alternative — one implementation, one review — loses some of its edge against that workflow, though it does not disappear.

Over-the-air updates are still the strongest argument

Over-the-air updates remain the strongest argument for React Native because they decouple bug fixes from app store review. React Native renders native components through a JavaScript layer, so shipping a new JavaScript bundle changes behavior without a new binary. Apple and Google both expect new features to go through review; fixes, feature flags, and small corrections are the well-established use case. Expo provides the tooling that makes this practical for most teams.

The failure mode this prevents is mundane and expensive. If half your installed base sits two or more versions behind, a bug you fix in an hour generates support tickets for months because store rollouts are gradual. A JavaScript bundle that already shipped can be replaced the same day, and a holiday background image can be turned on and off without a release train.

This is the one advantage Shopify's write-up mentions and moves past rather than rebuts. Its own post cites over-the-air updating as a major React Native win and does not explain what replaces it natively, which is why the trade-off is worth stating plainly: a pure native stack gives up that escape hatch unless you build your own update path.

Expo, dev clients and the loop Shopify skipped

Expo is often the difference between React Native being tolerable and being good, and Shopify's migration write-up reads as a company that was not using it. Expo handles builds, over-the-air updates, and dev clients; a dev build only needs one engineer to clear Apple's signing requirements before the rest of the team scans a QR code. Expo also compiles the app for web, which lets agents iterate on logic without a simulator.

Shopify's own account supports that reading. It describes agents that could not reliably build, test, and iterate, simulator control that was slow because it relied on accessibility trees or screenshots, and a custom CLI built so agents could inspect app state and act without touching the UI. Teams on Expo get a large part of that loop from the framework, including web rendering and better simulator support.

The practical lesson is unglamorous. React Native's hidden dependency is the surrounding tooling, and evaluating the framework without Expo measures a different system than the one most greenfield projects ship. A team that rebuilds Expo piece by piece pays the cost twice and gets fewer of the benefits.

New Architecture, version upgrades and dependency churn

React Native's New Architecture, the rewrite of the bridge between JavaScript and native code, is now the default and is not the stack Shopify benchmarked against. Earlier bridging passed data through layers; the New Architecture makes references to native components effectively native, speeds up layout synchronization, and removed the manual onLayout calls that used to be routine. Shopify's comparison of startup times measured an older architecture against native, which makes the gap look wider than a 2026 comparison would.

The honest counterweight is upgrade pain. Major version bumps have repeatedly required deleting lockfiles, reinstalling, and sometimes rewriting. Native modules written against an older architecture need rework to interface with the newer one, and that burden falls hardest on apps with the most custom native code — exactly the shape Shopify has.

This is a real cost that the New Architecture reduced but did not remove. It matters most for apps with long-lived native extensions and least for apps that stay inside the framework's supported surface.

What moving off React Native looks like in practice

Moving off React Native is more mechanical than it was in 2020, but the mechanical part is rarely the hard part. Shopify rebuilt several core parts of its biggest apps in Swift and Kotlin as a prototype, then chose greenfield rewrites over incremental migration, reasoning that agents and the chance to start clean outweighed the risk. It reports going from proof of concept to a rebuilt app on the App Store in about 12 weeks for the Shop app, which it says spans around 300 screens plus widgets and watch complications.

Independent developer accounts match the mechanism more than the speed. Agents given an existing implementation, a simulator, and clear correction feedback frequently produce close ports on the first or second attempt. The failure mode reported by Shopify — agents that build unmaintainable code unless the work is broken into reviewed checkpoints — is a process problem, not a language problem, and it is why Shopify built a checkpoint system rather than pointing an agent at the old codebase.

The gap between those two accounts is the most interesting unresolved question in this story. Individual developers using current models on smaller apps finish ports in hours; a company with dedicated engineers built a custom harness to do it safely. Both can be true, and the difference likely sits in app size, review requirements, and how much custom native code already exists.

The Shopify libraries: what happens to Skia, FlashList and Restyle

Shopify's React Native libraries are being handed off rather than abandoned, and the details differ by library. The company says the transition should be clean and without surprises for the ecosystem, and that it will keep contributing to the framework even as it rebuilds its own apps natively.

React Native Skia

Shopify says React Native Skia, which exposes the Skia graphics engine so screens can draw layered graphics without native views, will be forked in the coming months and published under a new name, with the existing repository archived once the transition completes. Contributions are expected to route through sponsorship of the maintainer, which keeps the library alive without Shopify holding it. Libraries like this carry real weight for animated, image-layered screens that would otherwise need native drawing.

FlashList

FlashList is described as close to a default for long lists in React Native, and Shopify only commits to fixing critical compatibility issues while holding discussions with other companies about long-term stewardship. For teams depending on it, the responsible move is tracking those discussions rather than assuming maintenance continues at the same pace. Alternatives exist, and list behavior is one of the few places where switching libraries meaningfully changes perceived app quality.

Restyle

Restyle, the smallest of the three by usage, is being archived. That is the least consequential part of this story, because its scope is narrow enough that teams can replace or vendor it.

Has React Native's own investment slowed at Meta?

Meta's investment in React Native has changed shape, and the change is harder to measure than a rocketing star count. The New Architecture shipped as a major rework of the framework's internals, and the people who built it have moved on to other companies and projects over the same period, which partly reflects the tech industry's broader reallocation toward AI work.

What that means for the framework is investment at a different level rather than a shutdown. React Native still powers production apps at Meta, still has maintainers, and still receives releases. The community claim that React Native's engineering bench was unusually strong is credible: exposing entire platform surfaces in one codebase is harder than binding a browser DOM, and that work took years and significant money.

Anyone choosing the framework in 2026 should price in the possibility that the pace of breakthrough work slows while the pool of teams able to match native code quality grows because of agents. Community forks and independent maintainers matter more in that scenario, which is why the library handoffs above are worth tracking.

When React Native is still the right call

React Native is still the right call when over-the-air updates, Expo's build and dev loop, or fast iteration across two platforms outweigh proximity to Apple and Google APIs. It is a weaker choice when your bottleneck was never writing the same feature twice, or when your app already carries substantial custom native code that each architecture change forces you to revisit.

The comparison below separates the two stacks on the dimensions that actually change decisions. Neither column is uniformly better, and the correct answer depends on which row is your constraining problem.

Dimension	React Native with Expo	Native Swift and Kotlin
Code sharing	One implementation, two platforms	Two implementations, shared specs and tests
Over-the-air updates	Supported through Expo updates	Not available; requires store review
Platform API access	Via maintained bindings; new APIs can lag	Immediate on release
Long lists and animation	Mature libraries, now partly hand-maintained	Platform list views, mixed quality
Upgrade risk	Architecture changes rework native modules	Language and SDK churn per OS release
Dev environment setup	One dev build, then QR-code reloads	Signing and provisioning per machine

The last row is the one people underestimate. Apple's signing requirements make a fresh native dev build painful to set up per developer, which is a shared cost that React Native plus Expo amortizes across the team. Teams that skip Expo rediscover that cost on their own.

FAQ

• Did Shopify really leave React Native? Yes. Shopify published a mobile strategy update stating that native is the future of its mobile apps and that it is rebuilding in Swift and Kotlin, citing AI coding agents as the reason the cost of building twice no longer decides the question. It also says it will keep contributing to the framework and hand off its libraries.

• Is React Native dead in 2026? No. React Native still powers production apps, still receives releases, and its New Architecture is now the default, which materially improves bridging performance over older versions. Shopify's decision reflects its own cost equation, not a framework shutdown, and the ecosystem still depends on it for over-the-air updates.

• What is an over-the-air update in React Native? It is shipping a new JavaScript bundle to an installed app so behavior changes without a new binary and a fresh app store review. Expo provides the tooling most teams use. Apple and Google expect new features to go through review, so the accepted use is fixes, flags, and small changes rather than full releases.

• Does React Native make apps bigger than native? Usually not by much, and the difference is often attributable to the rewrite rather than the framework. Shopify reportedly saved roughly a megabyte moving Shop to native, which is negligible against asset and localization bloat. A default Expo app sits in the tens of megabytes, and media assets dominate real size differences.

• Should I use Expo with React Native? Yes for most teams. Shopify's migration write-up describes rebuilding functionality that Expo already provides, including build handling, dev clients, simulator support, and web compilation for faster iteration. Skipping Expo means paying for that tooling yourself, which is why the framework's reputation depends heavily on it.

• Can AI agents port a React Native app to Swift or Kotlin? They can port existing implementations with a working reference, and developers report finishing smaller ports in hours with current models. Scaling that to a large app with custom native code and formal review requires process: Shopify built a checkpoint system with tests, adversarial reviews, and human sign-off before committing changes.

Turning long videos into articles people can actually read

The Shopify story works because someone took a dense, multi-layered decision and separated the assumptions from the evidence, which is exactly what a 63-minute video does badly and an article does well. If you already explain things like this on YouTube, Skalablog turns a video URL into a structured, readable draft you can edit and publish.

Paste the link, let Skalablog transcribe the video, and you get an article draft built from what you actually said. If you have an interview, a technical walkthrough, or a strong opinion sitting inside a video that few people will watch to the end, that is the material worth converting. Thanks to Gustavo Dev Doido for the example of how much explanation can hide inside a recording.

None of this replaces your judgment. Use the draft as a starting point, keep your specific claims intact, and publish a document only when its core argument holds up on its own.

Source video