Why Shopify is moving from React Native to native apps

Shopify’s move from React Native back to Swift and Kotlin starts with a cost question. In its 10 September 2026 announcement, the company says coding agents made building the same feature twice less expensive for its team. Shared implementation no longer carried the same weight in the decision.

That is a reason to revisit an estimate. It is not a general instruction to rewrite a working app.

What the Shop team shipped

The migration account describes a week-long iOS prototype built by one engineer with coding agents. It was not production-ready. A core team of six engineers then built the foundations and main journeys, with feature teams joining later. Shopify reports twelve weeks from proof of concept to the native Shop app in the stores.

These are Shopify’s own before-and-after measurements, rather than a framework benchmark.

The same account reports about a 75% reduction in Android release build time, similar iOS build time and session stability above 99.95%, against a historical 99.5% or more. Its Pixel recording reaches 120 FPS. None of those figures predicts another team’s return on a rewrite.

The existing option also required investment

Shop was approaching a migration to React Native’s New Architecture. The decision compared two substantial pieces of work, rather than a native rebuild against keeping everything unchanged for free.

A shared layer saves implementation work but creates dependencies and upgrade work of its own. If the cost of implementation falls, the balance may move. It can also remain in favour of the framework. Our Next.js and htmx discussion looks at a different set of product constraints.

The agents had a reference and a review process

An existing app gave the team behaviour to compare against. The migration workflow built around Pi separates source inspection, behaviour documentation, planning, implementation and parity review. Human acceptance is tied to the plan’s contents, so changing the plan invalidates approval.

Shopify also describes Helix and headless business logic. Agents can reach that logic through a CLI instead of relying on simulator interaction for every check. Tardis provides structured events, logs and live state, as explained in the Shop migration article. These tools make feedback part of the workflow rather than leaving a person to inspect all generated code at the end.

Native expertise still matters

Generated code could introduce duplication, architectural drift and performance problems. Review and native platform knowledge remained necessary. Keeping separate apps functionally aligned also requires ongoing coordination. A shared codebase had reduced that work, without ever making the compiler a guarantee of identical behaviour.

The September announcement described the merchant app, with more than 300 screens, as still in migration. Its scale and dedicated tooling make it a poor direct estimate for a smaller company. Whether a mobile app earns its budget is a separate decision.

Recalculate before committing to a rewrite

Price the current layer against an alternative that includes tests, releases and maintenance on both platforms. We use the same approach when comparing low-code and packaged systems.

For an agent-assisted trial, choose a bounded task with an existing reference and a result you can check. An integration against a documented API or a report compared with an old output may fit. In custom software work, that trial gives a better basis for estimating the larger migration than somebody else’s delivery schedule.