• Maintain dual codebases but use automated review checkpoints (CI pipelines that run LLM-generated diff analysis) to catch regressions early, ensuring consistency between iOS and Android releases.

Shopify’s mobile strategy just shifted gears. After years of relying on React Native, the company is rebuilding its flagship apps using Swift and Kotlin. This is not a retreat from cross-platform ideals, but a strategic pivot driven by the evolution of AI. Here is the history, the technical reasoning, and the migration methodology powering the change.

Background and Initial Adoption of React Native

We decided to go all-in on React Native back in 2020, and that bet has been extremely successful.

The wins were immediate.

We saved a ton of time building features just once, enabled developers with no mobile background to contribute to our apps, and freed ourselves from constantly chasing feature parity.

In January 2025, I wrote that the future of React Native was bright and that Shopify planned to keep investing in it.

That was true based on what we knew then.

React Native was working well for us, and it remains an excellent framework.

But the cost of development changed.

But since then, coding models have gotten dramatically better, and for our apps and our team, building the same feature in Swift and Kotlin no longer carries the cost it used to.

Original motivations for React Native

Stop building the same features twice Allow developers to work across the stack Spend less time chasing feature parity and more time shipping value

Early successes and trade-offs

The framework hit its marks.

React Native consistently delivered these benefits.

We found ourselves spending a significant amount of time and resources on optimizing performance, improving key foundational areas in React Native, and keeping up with framework updates and external dependencies, but these were acceptable tradeoffs.

The benefits of using React Native far outweighed the investments we had to make in these areas.

Why Shopify Is Switching Back to Native

Shopify didn't just adopt LLMs; they integrated them early.

Shopify has been using LLMs to build software since 2021 (one year before ChatGPT!).

Initially, we used them to implement features, investigate and fix bugs, and review code.

As the models improved, so did the complexity of the work we trusted them to take on.

By late 2025, they were no longer just helping us write code faster.

They were capable of making us question whether building software twice still meant doing twice the work.

The team prototyped this theory by rebuilding core app components in Swift and Kotlin. The results were surprising.

We rebuilt several core parts of our biggest apps in Swift and Kotlin using LLMs and were surprised by how well it worked.

AI agents now handle the heavy lifting of translation:

Could implement a feature on Android using the iOS version as a reference, and vice versa

Helped developers ramp up and contribute effectively outside their primary stack

Dramatically reduced the cost of maintaining parity between platforms through shared specifications, tests, and review checkpoints

Does this mean the cost of two codebases disappeared? No.

Native still means building and maintaining software on two platforms, that cost has not disappeared.

But the bottleneck shifted. Agents now shoulder the implementation, translation, and review work.

What changed is that agents can now do enough of the implementation, translation, testing, and review work that it’s no longer the deciding factor it was in 2020.

Performance was the final nudge.

React Native apps can be fast.

Ours are.

Yet, removing the framework layer offers a level of precision that no bridge can match.

We are making this change because agents have reduced the advantages of sharing implementation, while the advantages of building for each platform remain.

Native keeps us closer to platform capabilities and first-party tooling, with fewer framework and dependency layers between our code and the platform.

Internal shifts often leave external communities wondering about the tools they rely on.

Status of Shopify’s React Native Open-Source Libraries

Shopify is exiting React Native internally, but it isn't abandoning the ecosystem.

React Native Skia – continued sponsorship and fork

Shopify will continue sponsoring this through the end of 2026, and William Candillon will continue working on it beyond that.

He will fork the repo in the coming months and start publishing the library under a new name.

The original repo will be archived when this transition is complete.

We’ll post updates along the way so that everyone has ample time to migrate.

If your app relies on this library, please consider sponsoring it.

FlashList is too big to simply archive.

This library gets ~2M downloads/week and has become the default way to render high-performance lists in React Native.

Given how important it is for the ecosystem, Shopify will continue to fix critical issues that break compatibility.

We’re currently in discussions with several companies about taking on long-term stewardship of FlashList.

If you’re interested, reach out to me here.

Restyle – archiving timeline and community hand-off

Restyle has a smaller user base than our other libraries, so we're archiving this repo.

We'll keep it working through the end of 2026, then stop maintaining it.

Anyone is welcome to fork it and take it forward, and we'll help with the handover if a team wants to pick it up.

With the libraries settled, the focus turns to the actual migration. How do you move a massive production app without breaking it?

Migration Strategy – Greenfield vs Brownfield

We debated between gradually migrating to native (brownfield) versus rebuilding them from scratch (greenfield).

In the past, brownfield was the only viable option.

In the past when we migrated to React Native, we picked the brownfield approach for some of our biggest apps, as it’d take years to rewrite them and we’d have to stop shipping new features while the rewrite was in progress.

This time, the math changed. Greenfield won.

However, this time greenfield emerged as a clear winner for the following reasons:

LLMs are good at building features in Swift and Kotlin using the React Native version as reference

It gives us a clean slate to rebuild in the best way possible without any of the previous constraints

Our prototypes showed that we could rebuild these apps substantially faster than was possible before coding agents

Decision criteria for greenfield approach

Early greenfield migration: The Shop app case study

The Shop app served as the pilot.

The Shop app, which is regularly at the top of the list in the shopping category in the app stores, is the first to be migrated.

The speed was staggering.

Assisted by AI, the team was able to go from a proof of concept to a fully rebuilt native app published in the app stores in just 12 weeks.

We’ve written about this migration in depth here.

Ongoing greenfield migration: Shopify app and future plans

The biggest challenge is next.

The migration of the Shopify app (our biggest with 300+ screens, home & lockscreen widgets, Apple Watch app, complications, Siri Shortcuts, etc.), is also underway and will ship later this year.

The rest of our apps will be migrated soon.

But raw AI generation is messy. To ensure quality, Shopify built a governing system.

The Helix System for Controlled Migration

AI can hallucinate. To prevent this, Shopify created Helix—a checkpoint-driven workflow.

To solve this problem, we built a system called Helix that takes a more gradual approach.

It doesn't expect the first output to be correct, and builds a loop where an imperfect attempt simply cannot move forward until it becomes a good result.

The workflow is surgical:

The developer points Helix at a screen.

Helix reads the React Native code and proposes a sequence of checkpoints (small, ordered slices of the work) that can be reviewed in minutes.

Each slice must pass a gauntlet:

Then, checkpoint by checkpoint, it builds: each one must prove its behavior with tests, match the running app in a visual review, survive two adversarial code reviewers, and get a human's nod before it's committed and the next one starts.

The system learns.

Feedback from every review is remembered, so the loop gets more autonomous as the migration progresses.

This approach has been working extremely well and is allowing us to rebuild our apps in a fraction of the time.

Even with Helix, a major bottleneck remained: the simulator.

Improving Feedback Loops for Agent-Driven Development

Agents are fast; simulators are slow.

Agentic control of simulators has been a bottleneck.

We found ourselves constantly babysitting them as they couldn’t reliably build, test, and iterate.

We built tooling to allow agents to reproduce bugs, fix them, and verify the fix autonomously but it was slow and brittle.

React Native's hot-reload helped, but it didn't solve the core issue.

React Native’s hot module reload helps the situation but it doesn’t solve it, due to simulator control being slow.

This is primarily due to reliance on the accessibility tree, or screenshots to get the state of the app, take actions, and verify results.

The disparity is jarring. An agent changes code in seconds but waits minutes to see the result.

Agents can make code changes in seconds, but it takes them several minutes to test the output.

This makes iterating extremely slow and manual.

It doesn’t matter how good the model is if it can’t test its work quickly, which is especially difficult on mobile.

The solution? Architecture that treats agents as first-class citizens.

We’re fixing this by designing our app architecture to work for both humans and agents.

The rule is simple: decouple business logic from the UI.

The core principle here is that business logic should be completely decoupled from the UI and be able to run headlessly on desktop.

Now, agents use a CLI to iterate in milliseconds.

We then make it available to agents via a CLI that allows them to iterate on it in milliseconds instead of minutes without involving simulators.

The CLI allows agents to inspect the state of the app, navigate between different sections, and perform actions all without needing to touch the UI.

When a visual check is mandatory, the CLI drives the simulator remotely.

When simulator interaction is needed, the CLI can connect to them via a remote mode and drive the UI via commands without having to inspect the layout or the accessibility tree.

This enables blazing-fast performance and E2E tests.

Looking Ahead

The goal is a total transition to native, powered by AI.

We are going to migrate all our mobile apps to Swift and Kotlin using AI throughout the process.

Shop has already shipped as a fully native app, the Shopify app is underway, and the rest will follow soon.

Speed does not justify sloppiness.

We’re moving quickly, but not by lowering the bar.

Every rebuild must meet or exceed the performance, stability, accessibility, and product quality people expect today.

This isn’t just the same apps rewritten in different languages.

We’re rebuilding them so both humans and agents can understand, test, and change them quickly.

The migration is a means to an end, not the destination.

The migration isn’t the finish line.

Success means our teams can deliver better experiences for merchants and buyers faster than before.

We’ll measure that through product velocity, app quality, and how much work agents can complete autonomously.

Shopify will continue to share the technical blueprints of this transition.

We’ll share what we learn along the way, including deeper dives into Helix, our agent-addressable architecture, and how we’re building mobile apps with agents.

We were open about what we learned from React Native, and we intend to be just as open about this transition.