Stop scrubbing through session replays (Sponsored)
Most teams record session replays at a flat sample rate, then spend the next incident scrolling through hundreds of sessions that have nothing to do with the bug.
This hands-on Sentry workshop shows you how to capture the replays that matter:
Sample rates and buffer mode, plus the default we recommend
Custom React hooks to record a specific user segment, a known-bad URL, or a flow you just shipped
Bug reports that arrive with the replay already attached
Filters for rage clicks, dead clicks, and custom tags
Privacy defaults and how to tune them
In 2020, the Shopify engineering team decided to go all in on React Native. It saved them a ton of time and money. By using React Native, the developers didn’t have to implement the same feature in both Kotlin and Swift to make it work on Android and iOS. Sure, the framework came with its requirements. But the idea was very successful at the time.
However, in 2026, AI coding agents have made a huge difference to the economics of building mobile apps. Earlier, if you implemented something with React Native, you could justify the savings that came because of it. But now, AI agents have become so good at coding that building the same feature in Swift and Kotlin is much cheaper.
In this article, we’ll look at how Shopify decided to move out of React Native and how they migrated to native mobile development. Here’s what we’ll cover:
What is native mobile development
Why Shopify chose React Native
What changed in 2025
Shopify’s migration approach
How Shopify ran the migration
The agent feedback loop
The migration results
Disclaimer: This post is based on publicly shared details from various sources. References at the end. Please comment if you notice any inaccuracies.
What is Native Mobile Development
As you might be aware, an iPhone runs Apple’s iOS, and Android phones run Android. Both these OS provide a bunch of facilities to display the UI, handle notifications, and talk to the device hardware.
In native mobile development for a particular OS, you build an application directly using the languages, frameworks, and tools for that platform. This means Swift for iOS and Kotlin for Android. To be clear, a programming language is different from a UI framework. For example, Swift and Kotlin are programming languages. However, Apple’s SwiftUI and Android’s Jetpack Compose are frameworks. These frameworks give developers the tools to create the real UI with various components like text, buttons, lists, layouts, and animations.
To build natively for both platforms, you need to maintain two implementations of the mobile application. One for Android. Another for iOS. Sure, you can share the backend services for both platforms, but the client code will still be separate.
However, React Native lets you share much of that implementation across both iOS and Android. It’s a framework for building mobile apps using React and JavaScript (or TypeScript). The main benefit of React Native is that many components and application code you write using this framework can work with both iOS and Android. You don’t need to implement every screen independently in Swift and Kotlin. This is because React Native sits on top of the native UI components that are backed by their respective platforms. For example, if you make a component in React Native, it can create the appropriate iOS or Android views without the need for developers to write any platform-specific code.
To be clear, sharing code doesn’t mean that every platform difference is completely gone. You would still have some features that might need platform-specific coding. Also, you need to build, test, and release the application for each OS.
[Webinar] How to stop rewriting your agent’s code (Sponsored)
Right now, you’re your agent’s context engine. You write the rules files, maintain the skills, and paste in the Slack thread it missed.
But hand-curated context goes stale. And when there are conflicting answers, your agent can’t tell which is right. You pay for it in higher token bills and longer reviews.
Join us live on Oct 28 (FREE) to see:
The 8-levels of AI maturity and where teams get stuck
How a context engine curates context and resolves conflicts before your agent writes a line of code
Live demo: token savings in the same coding task, and use cases beyond code gen
Bonus: 2 open source tools you can use today.
Why Shopify Went With React Native
The Shopify engineering team went with React Native in 2020. They wanted to solve three problems that were more or less linked.
The first problem was that you had to implement every feature two times with native development. One time for each platform. The second was that you couldn’t share developers between platforms. A developer was confined to their tech stack. An iOS developer couldn’t work on the Android version. Neither could the Android developer work on the iOS version. Not a great way to utilize the developers in a team.
The third problem was that you had to maintain feature parity across both versions. Feature parity is when every version of the app has the same features and capabilities. Let’s say, if you have a cool feature that works on iOS, but it takes another month to be available on Android, you can say that the two versions are out of parity. If you don’t maintain this parity, you risk alienating the user base of the platform that usually runs behind.
Also, when you have two versions of the app, you need to change both versions whenever there’s a change in any requirements. Even if the change is something as small as a text change. As you can see, this is a continuous cost problem that is present throughout the life of the application. You also need to have more coordination between the different platform teams while planning releases, announcements, and so on.
By going with React Native, Shopify reduced the impact of these problems in a big way. No need to implement every feature twice. No need to coordinate changes across multiple platform teams. It also made mobile development easy for developers already familiar with React and TypeScript. This is great because you could easily move people between projects. Plus, you also get to select developers from a much bigger TypeScript or JavaScript talent pool.
What Changed in 2025
As a framework, React Native has a lot of benefits. We have seen that already in the earlier section. But the framework also needs maintenance. This means additional costs.
The Shopify engineering team had to spend effort on optimizing the framework’s performance. They made improvements to the React Native foundations and contributed to framework upgrades. They also had to deal with changes to external dependencies. You can think of a dependency as a piece of software that the application relies on. If there’s a change in the dependency, you need to make changes to the application as well.
Native development is different from using a framework. The application has greater synergy with the platform and first-party tooling. You can use the tools provided by the platform’s own developers. Also, you have fewer dependency layers between the application code and the platform (iOS or Android).
Shopify was already using native code for some features. For example, widgets and watch applications. Also, for some background processing. You could say that React Native and native development coexisted within the application for several years. Of course, the benefit equation tilted more towards React Native.
However, the rise of coding agents made big changes to the equation. As you know, a large language model (LLM) can generate code quite easily. A coding agent combines an LLM with special tools that can read code files, edit code, and run tests. It could also check why things are failing and make changes to handle those failures.
By 2025, these agents had improved so much that Shopify had to take another look at its mobile strategy. To test the waters, the Shopify engineering team rebuilt some core parts of its application in Swift and Kotlin. These prototypes proved that the coding agents could take an implementation on one platform as a reference and write the equivalent code for the other platform.
For example, you can have an iOS feature that provides all the details about the UI elements, actions, and error conditions. An agent can use those details and build an Android equivalent. Sure, developers had to check whether the outcome was good enough and followed the conventions of Android and the overall architecture. However, suddenly, you had developers who could use these agents to code stuff outside their primary stack without a lot of effort.
Of course, with native development, two implementations would still be there. Both will need to be maintained. But Shopify claims that coding agents have reduced the work to such a level that concerns about duplication are no longer as important for making decisions as they were in 2020.
Shopify’s Migration Approach
To carry out the migration to native, Shopify had to choose the best pathway to migrate the existing applications. You have two ways to do so.
First, we have brownfield migration. In this approach, you change an existing application gradually. New and old implementations run together as individual parts are replaced. While the risk is lower, the migration takes more time. Also, you have to manage the integration between the new and old implementations.
Second, we have a greenfield approach. In this approach, you create a fresh implementation. Developers get more freedom to design a new architecture. However, you need to build an almost complete replacement before getting rid of the existing product. There’s no incremental change.
Shopify had used the brownfield approach earlier for some of its large applications. The development methods at the time would have taken too long. However, when they tried the new prototypes, the team found out that a fresh native implementation would be faster. The existing React Native application was a solid reference point for how things should work.
Therefore, Shopify chose the greenfield approach.
They first shipped the Shop app. This app was used by shoppers. The larger Shopify app, which is used by merchants, was migrated later. For reference, the Shopify app has more than 300 screens. Also, many features, such as widgets. And an Apple Watch application.
How Shopify Ran the Migration
When planning the migration, the Shopify engineering team found that if you asked a model to rebuild a large feature in one attempt, you got mediocre results. The output code was difficult to maintain. Also, it was very difficult for developers to properly review big features.
Therefore, Shopify built Helix to support the migration. Helix breaks the migration into small steps that can be reviewed. With Helix, you can have a developer select a screen, and Helix proposes small pieces of migration in the best possible order. Each migration piece has to go through the review process. Only then does it become the foundation for the next piece.
For example, let’s say you have an order detail screen. An initial checkpoint can finalize the structure of the screen and how navigation should work. Later checkpoints will deal with other features such as order summary and customer information. Each checkpoint is small enough that developers can review it properly.
Four types of checks are done to make sure everything works as intended.
First, you have the behavioural tests. You take expected actions on the app and check what happens. Second, you have the visual review. In this, we check how the new UI looks compared with the old reference application.
Next, you have adversarial code reviews. Two reviewers look for problems in the code. They try to find issues that might stay hidden behind a normal workflow. Lastly, we have another developer review where we check the results of the previous tests. If everything meets expectations, things proceed further.
The best part about Helix is that the team gets continuous feedback while the change is still small.
The Agent Feedback Loop
Shopify has a design philosophy that separates app logic from the UI.
For example, you can have a form with rules about valid or invalid inputs. To test them, you don’t need a visible text box. They can receive an input value and return a result.
Shopify’s architectural principle is to keep the business logic independent of the UI. The idea is that the business logic can run headlessly. You can expose the application state and actions through a CLI. This way, the agents can check state, navigate between sections, and perform actions.
While navigating like this without a UI might sound strange, it makes it easy to check how things work. You can have an agent take an action and check the state. There’s no need to make sense of screenshots and find out where a button is located. This is why behavioural checks can be made quite fast.
The Migration Results
The Shop app was live on the app stores as a native application in 12 weeks. There were many interesting stats.
The app startup time on iOS went down from 3200 ms on React Native to approximately 2400 ms on the Native version. The startup time on Android had even greater gains, going from around 4400 ms to 2200 ms. Almost half. The crash-free sessions went up. Also, the app size on Android was down from 293 MB for React Native to 184 MB for the native version.
All in all, these results have been quite encouraging for the Shopify engineering team. Of course, their approach combines a lot of things that make it successful. For starters, you have direct use of platform tech. You also have an existing application, which can act as a strong reference point. Also, the migration process is made smooth with small implementation checkpoints and quality checks.
The main thing we can take away from Shopify’s case is to have a fast feedback loop that can check if the code generated by AI agents is good enough. This is the key to making big migrations like this safe for the users.
References:
The headless CLI is the part I'd steal. Once agents can read app state and trigger actions directly, behavioral checks become assertions on state instead of screenshot parsing, which is much cheaper and less flaky than a computer-use loop. I'm curious how the visual review step worked, though. Was it automated screenshot diffing against the React Native reference, or people comparing by eye? That's the one check the CLI can't cover, and across 300+ screens it seems like where small drift would hide.
Greenfield code still inherits an installed user's data. Alongside Helix's screen checkpoints, I'd keep an upgrade fixture created by the React Native app: saved preferences, an unfinished draft, and a pending background task. Install the native replacement over it and verify those states survive, including an upgrade after the user skipped several releases. A clean-install behavioral pass can miss that boundary completely. This makes the migration's release gate about continuity for existing users, not just parity between two fresh app sessions.