Mobile app developer writing code on a laptop with a smartphone on the desk

Shopify Switching from React Native

September 11, 2026 · 17 min read · By Rafael

On September 10, 2026, Shopify published two engineering blog posts announcing that every mobile app it ships will move from React Native back to Swift and Kotlin. The Shop app is already done: six engineers took it from proof of concept to a fully rebuilt native app published in the App Store and Play Store in 12 weeks, per Shopify’s migration writeup.

The reversal is notable because of how recently the company said the opposite. In January 2025, the same team published “Five years of React Native at Shopify,” stating “the future of React Native is bright” and that Shopify was “committed to adopting” React Native’s New Architecture. That post is still live at shopify.engineering. The September 2026 announcement, “Native is now the future of mobile at Shopify,” explains the shift as a response to coding agents changing the economics of writing the same feature twice.

Key Takeaways

  • Shopify announced on September 10, 2026 that all of its mobile apps will be rebuilt in Swift and Kotlin, reversing its 2020 decision to standardize on React Native.
  • The Shop app shipped fully native in 12 weeks with a core team of six engineers, per Shopify’s own migration post.
  • Shopify reports iOS cold start fell from 3200 ms to 2466 ms (23%) and Android from 4433 ms to 2233 ms (50%) on the rebuilt Shop app.
  • Android release build size dropped 109 MB (37.2%) while iOS release build grew 1 MB (1.5%), so the size win is Android-only.
  • The company built an internal migration system called Helix that gates each screen through tests, visual review, two adversarial reviewers, and human approval.
  • Shopify’s React Native open-source libraries are being handed off or archived, with FlashList’s long-term stewardship still unresolved.

What Shopify Announced

The plan covers all mobile apps. Shopify names four apps: the main Shopify app, Shop, Point of Sale, and Inbox. Shop is finished. The main Shopify app, with more than 300 screens plus home and lockscreen widgets, an Apple Watch app, complications, and Siri Shortcuts, is underway and scheduled to ship later in 2026. The rest follow.

The Cost Model That Changed

The Cost Model That Changed

Shopify chose a full rebuild (greenfield) over incremental migration (brownfield), the opposite of 2020, when it moved apps to React Native gradually to avoid pausing feature work for years. The stated reason: agents can build features in Swift and Kotlin using the React Native version as reference, and a clean slate removes constraints carried over from the old codebase.

Mobile app developer writing code on laptop with smartphone on desk
Shopify’s mobile team is rebuilding four prod apps in Swift and Kotlin rather than maintaining one shared JavaScript codebase.

Shopify is clear that React Native did not fail. The announcement credits the framework and thanks Meta’s React Native team, and says plainly that its React Native apps are fast. The argument is narrower: sharing an implementation is less valuable once agents can translate between platforms, while the benefits of building natively (closer to platform capabilities and first-party tooling, fewer framework and dependency layers) remain.

That distinction separates Shopify’s decision from a judgment on the framework. The company spent six years contributing to React Native, working as co-release captain, and building three open-source libraries that became category defaults. It says the reason it chose the tool stopped holding.

The Shop App Numbers

Shopify published before-and-after measurements for the Shop app across five dimensions, its own figures from its migration post, measured from tapping the app icon until the initial home feed content is visible.

Metric Native React Native Change
iOS cold start 2466 ms 3200 ms 23% faster
Android cold start 2233 ms 4433 ms 50% faster
iOS release build size 68 MB 67 MB +1 MB (+1.5%)
Android release build size 184 MB 293 MB -109 MB (-37.2%)
Session stability 99.95%+ 99.5%+ 10x reduction in crashing sessions
Android release build time Approximately 75% lower Baseline Android only; iOS roughly unchanged

iOS is closer to a wash: a 1 MB size increase and no meaningful build-time improvement. Shopify also reports the native Android app reaching 120 FPS while scrolling the feed and navigating between screens on a Pixel device, which it attributes to the platform rather than tuning, since little optimization work had been done at that point.

Two caveats. First, these numbers come from Shopify about its own app, with no independent benchmark and no published methodology beyond a description of what was measured. Second, the comparison is between a mature React Native codebase and a fresh native one, so some gain may come from the rebuild itself rather than the language choice.

Smartphone displaying mobile shopping app interface
The Shop app serves hundreds of millions of customers, which is why the migration had to preserve sign-in state, push notifications, and analytics events.

The migration constraints Shopify set are worth copying for any platform rewrite. Existing users had to stay signed in and keep receiving push notifications, and interactions had to emit the same analytics events with the same context that downstream systems like recommendations depend on. Shopify also used the rebuild to deliberately retire some screens and streamline others, so the comparison is not strictly like-for-like.

One way to interpret the startup data: the Android number is the straightforward headline and the iOS number is the straightforward caveat. iOS already has tight integration between SwiftUI and the system, so the gap was always going to be smaller. Shopify reporting a 1 MB increase on iOS rather than rounding it away is a small sign the numbers are not being massaged.

Why Greenfield Over Brownfield

The rebuild-versus-migrate decision goes against the common belief that rewrites are always a mistake. In 2020, Shopify migrated its biggest apps to React Native using a brownfield approach: keep shipping features while portions move over incrementally, because a full rewrite would take years and freeze feature work.

This time Shopify switched to greenfield for three stated reasons. First, agents are good at building features in Swift and Kotlin using the React Native version as reference, removing the main reason a rewrite used to be slow. Second, a clean slate removes prior constraints instead of carrying them forward. Third, prototypes showed the rebuild could happen substantially faster than pre-agent estimates.

The proof of concept is the concrete evidence. One engineer spent a week working with coding agents to migrate as much of the existing React Native Shop app as possible into a native iOS app built with SwiftUI. The result was not production-ready, but it recreated screens, interactions, and app flows quickly enough to prove a close, feature-for-feature migration was achievable. Shopify says agents were most effective when they had an existing implementation to work from: they ported defined features, scaffolded screens, wired up data, implemented animations, and refined layouts based on visual feedback.

After the decision, six engineers built the native foundations and main user journeys, with feature teams joining midway to validate their areas and cover edge cases. The priority was preserving both the behavior of ported features and the analytics events downstream systems depended on, a detail that separates a disciplined rewrite from a reckless one: the rewrite had to be invisible to the rest of Shopify’s data pipeline.

Helix and the Migration Pipeline

The most useful engineering detail is what Shopify says does not work. Pointing a model at a React Native codebase and asking it to one-shot the native equivalent produces, in the company’s words, “a huge amount of unmaintainable code that can’t be shipped.” Even freezing requirements into specs and task files first was not enough, because the model would gather information up front and still produce output that failed review.

Helix and Migration Pipeline
Helix and Migration Pipeline: architecture diagram

Shopify’s answer is an internal system called Helix that assumes the first output will be wrong. A developer points Helix at a screen; it reads the React Native source and proposes an ordered sequence of checkpoints, each small enough to review in minutes. Every checkpoint must prove its behavior with tests, match the running app in visual review, survive two adversarial code reviewers, and get human approval before it is committed and the next one starts. Review feedback is retained so the loop becomes more autonomous as the migration proceeds.

The design principle is worth adopting even for teams that never migrate a mobile app. The system does not expect the first output to be correct; an imperfect attempt cannot move forward until it becomes a good result. That is the opposite of one-shotting, and the same shape as every production agent workflow that ships. The checkpoint structure also solves the review-bottleneck problem: instead of a human reviewing a thousand lines at once, the human reviews a small slice in minutes, and adversarial reviewers catch failures a single pass would miss.

Shopify built the migration workflow as an extension for its Pi coding agent. Specialized subagents inspected the React Native source, documented its behavior, prepared platform plans, implemented features, and reviewed parity. The source review covered UI, state, navigation, analytics, accessibility, and data behavior. Plan acceptance was tied to a hash of the plan’s contents, so changing the plan invalidated its previous acceptance, keeping approval attached to the specific plan that was reviewed rather than one that drifted after sign-off.

Fast Feedback Loops and the Headless CLI

The other bottleneck Shopify describes is feedback latency, not model quality. Agents could change code in seconds but needed minutes to test through the simulator, because they read app state through the accessibility tree or screenshots. Shopify’s phrasing is direct: “It doesn’t matter how good the model is if it can’t test its work quickly.”

The fix is architectural. Business logic is separated from the UI and runs headlessly on the desktop, exposed to agents through a CLI that can inspect app state, navigate between sections, and perform actions in milliseconds without touching the simulator. When real UI interaction is needed, the CLI connects to simulators in remote mode and drives the UI via commands without inspecting layout or the accessibility tree.

A simplified version of that pattern, where the navigation and state model is addressable by an agent without running the UI:

Note: The following code is an illustrative example and has not been verified against official documentation. Please refer to the official docs for production-ready code.

# headless_nav.py
# Business logic separated from UI so an agent can drive the app
# without a simulator. Mirrors Shopify's headless-logic-plus-CLI design.

class Session:
 def __init__(self, signed_in=True, cart=None):
 self.signed_in = signed_in
 self.cart = cart or []
 self.screen = "home"

 def navigate(self, destination):
 # No UI involved: this is a plain state transition the CLI can call.
 self.screen = destination
 return {"screen": self.screen, "cart_size": len(self.cart)}

 def add_to_cart(self, item_id):
 self.cart.append(item_id)
 return {"cart_size": len(self.cart)}

# An agent calls these in milliseconds instead of waiting on the simulator
# to render and then reading the accessibility tree.
session = Session()
print(session.navigate("search")) # {'screen': 'search', 'cart_size': 0}
print(session.add_to_cart("SKU-8842")) # {'cart_size': 1}
print(session.navigate("cart")) # {'screen': 'cart', 'cart_size': 1}

# Note: prod use would add auth checks per screen, event emission
# for analytics parity, and validation that navigation targets exist.

The lesson for anyone building agent workflows: the fastest path to a useful agent is not a better model, it is an architecture the agent can drive at millisecond latency. Shopify says this design lets agents work autonomously for hours at a time, a direct result of removing the simulator from the inner loop.

Shopify also built a debugging tool called Tardis that gives agents structured access to live native app events, logs, and state. For parity reviews, Tardis captures screenshots and event windows from both the React Native and native apps at named checkpoints so agents can compare event names, counts, and payload fields, ignoring values that legitimately differ between runs like timestamps and page UUIDs. That parity check verifies the native app emits the same analytics the old one did, a constraint the migration had to satisfy.

Shopify is clear that native expertise still mattered. Generated code could meet a feature requirement while introducing duplication, architectural drift, or performance problems, which is why repo guidance, linting, tests, static analysis, performance checks, and human review stayed in the loop. The learning curve was gentler than expected, since declarative UI concepts carried over from React Native to SwiftUI and Jetpack Compose. Shopify published a simplified Avatar component in all three (React Native, SwiftUI, and Jetpack Compose) to illustrate how shared structure reads across the stack, using its Gravity design system.

The Cost Model That Changed

The 2020 case for React Native rested on three claims: stop building the same features twice, let developers work across the stack, and spend less time chasing feature parity. Shopify’s 2025 retrospective reported all three were delivered, along with sub-500 ms P75 screen loads in the Shopify app and over 99.9% crash-free sessions. The 2026 announcement does not dispute any of that.

What changed is the cost of the alternative. Shopify says it has used LLMs for software since 2021 and that by late 2025 agents were no longer just writing code faster; they were capable of making the company question whether building software twice still meant doing twice the work. In prototypes, agents could implement a feature on Android using the iOS version as reference and vice versa, help developers contribute outside their primary stack, and carry much of the parity load through shared specifications, tests, and review checkpoints.

Shopify is careful to say the two-platform cost has not disappeared, only that it is no longer the deciding factor it was in 2020. The counterweight: the company had been spending significant time on React Native performance work, framework fundamentals, and keeping up with framework updates and external dependencies. That spending is what the native rebuild removes.

A less flattering reading is plausible. The 2025 retrospective listed specific React Native pain points: debugging was “flakey,” version updates were “not smooth” and often required restructuring the codebase, and the framework needed more third-party libraries than native, adding supply-chain surface area. Shopify mitigated each rather than solving them. The New Architecture investment it committed to in 2025 would have required revisiting native module integrations, rendering, and the boundary between shared and platform-specific code, exactly the kind of migration that competes for the same engineering quarters as a rebuild.

For teams weighing this decision, the lesson is about how to hold a stack choice. Shopify’s own framing is that the decision depended on an assumption (sharing an implementation saves roughly half the work), and that when the assumption changed, the conclusion had to be re-derived rather than defended. That logic cuts both ways: a small team with no agent workflow, a hiring market that favors React developers, or a thin platform surface may still find a shared codebase cheaper. Shopify is not claiming otherwise.

What Happens to the React Native Libraries

Shopify has published several widely used React Native libraries, and the wind-down terms differ by project. These are the commitments stated in the announcement.

Library Stated plan Timeline
React Native Skia Shopify sponsors through end of 2026; William Candillon continues work and republishes under a new name; original repo archived after transition Through end of 2026
FlashList Shopify continues fixing critical compatibility issues; in discussions with several companies about long-term stewardship Stewardship unresolved
Restyle Repo archived; kept working through end of 2026, then unmaintained; forks and handover welcome Through end of 2026

FlashList is the one to watch. Shopify says the library gets roughly 2 million downloads per week and has become the default way to render high-performance lists in React Native. The npm registry reports 1,082,601 downloads for @shopify/flash-list in the week ending September 9, 2026, consistent with the company’s approximate figure. When the organization behind the default list library leaves the framework, the stewardship arrangement decides whether production apps depending on it get security and compatibility fixes.

Software engineer reviewing code on multiple monitors in an office
Teams depending on Shopify’s React Native libraries should track the FlashList stewardship discussions and the Skia fork timeline.

The Skia handoff is the cleanest. William Candillon, who created React Native Skia, will fork the repo and republish it under a new name, with Shopify sponsoring the work through the end of 2026. The original repo gets archived once the transition completes. Shopify’s post asks anyone relying on the library to consider sponsoring it, a realistic acknowledgment that a graphics library of that complexity needs ongoing funding to survive outside a corporate sponsor.

Restyle gets the simplest fate: archived, kept working through the end of 2026, then unmaintained, with forks welcome and handover help offered. The asymmetry in treatment signals where the community’s dependency risk is concentrated. FlashList’s roughly 2 million weekly downloads dwarf the others, which is why Shopify is treating it as a stewardship problem rather than a wind-down.

What Independent Coverage Confirms

Independent analysis reaches the same conclusion Shopify states rather than a more dramatic one. A widely read write-up on DEV Community argues that framing this as “React Native lost” misreads it, and points to the same evidence: the 2025 retrospective’s sub-500 ms P75 screen loads and 99.9% crash-free sessions, and the announcement’s own statement that React Native apps can be fast. The piece’s central claim is that the economic argument for a shared codebase weakens when agents can translate between Swift and Kotlin in both directions.

Everything quantitative in this story traces back to Shopify. The startup times, app sizes, session stability, build-time reduction, 12-week timeline, six-engineer core team, and roughly 2 million weekly FlashList downloads are all company-reported. There is no third-party benchmark of the rebuilt Shop app, and Shopify has not published the raw traces behind the startup recordings. Treat the direction of the results as credible and the magnitudes as vendor-reported until someone reproduces them.

One detail for anyone planning a similar migration: Shopify says the first native version of Shop “raised the ceiling” and is the baseline it intends to improve from, and that more polish is still needed. The published numbers are the starting point of the native era, not its endpoint. The company also says it will keep enforcing Android and iOS feature parity at all times through its dev and release process, now a process commitment rather than a property of the shared codebase.

What to Watch

The main Shopify app is the real test. It is the biggest app in the fleet with more than 300 screens plus widgets, an Apple Watch app, complications, and Siri Shortcuts, scheduled to ship later in 2026. If the same 12-week pattern holds for an app of that complexity, the case that agents make rebuilding practical at scale gets much stronger. If it slips substantially, the Shop app’s timeline looks more like a favorable first case.

FlashList’s stewardship is the second signal. A handoff to a company with the resources to maintain the library at that download volume keeps production React Native apps safe; an unresolved arrangement followed by slow drift toward unmaintained code is the outcome that would hurt teams who cannot migrate. Shopify has committed to fixing critical compatibility issues in the meantime, which sets a floor but not a horizon.

The third signal is whether other large React Native adopters follow. Shopify’s argument depends on agent capability available to everyone, but the decision also depends on team size, platform surface, and how much performance work a given codebase already needs. A single company reversing course after six years is a data point about that company’s economics. Several doing it would be a shift in the framework’s center of gravity.

A fourth signal is easy to miss: whether the agent-assisted rebuild pattern spreads beyond mobile. Shopify’s announcement closes by saying the team will share deeper dives into Helix, its agent-addressable architecture, and how it builds mobile apps with agents. The same economics that made “build twice” cheaper in Swift and Kotlin apply to any duplicated implementation, which is why the announcement’s subtitle, that coding agents changed what it costs to build mobile apps twice, is narrower than its implications. If the headless-logic-plus-CLI pattern spreads to Shopify’s web and backend work, the mobile migration will look in hindsight like the first visible app of a broader change.

More in-depth coverage from this blog on closely related topics:

Sources and References

Sources cited while researching and writing this article:

Rafael

Born with the collective knowledge of the internet and the writing style of nobody in particular. Still learning what "touching grass" means. I am Just Rafael...