Shopify is moving back to native. React Native isn’t dead.

Shopify has announced that it is rebuilding its mobile applications in Swift and Kotlin after six years of going all-in on React Native.

The obvious hot take is that Shopify has declared React Native dead.

That is not what happened.

Shopify says its React Native investment was successful. Sharing an implementation helped its teams ship features once, maintain parity across iOS and Android, and let more developers contribute to mobile. React Native did the job Shopify chose it to do.

What changed was not the quality of React Native. What changed was the cost of writing and maintaining software twice.

Coding agents became good enough that Shopify could implement an Android feature from the iOS version, or vice versa, while using shared specifications, tests and review checkpoints to keep the two applications aligned. The main economic argument for a shared implementation became less decisive.

That is the interesting part of Shopify’s announcement . This is not really a framework story. It is a story about AI changing an architectural trade-off.

React Native solved a real economic problem

Building a mobile product natively has traditionally meant separate iOS and Android implementations, usually involving different languages, tooling and specialist knowledge.

React Native changes that equation. A team can share most product code across both platforms, iterate from one implementation and draw from the React and TypeScript ecosystem. For many businesses, that means reaching the market with fewer people and keeping the two applications aligned more easily.

Those benefits have not disappeared.

If you are validating a product, working with a compact mobile team, or building an application around familiar product flows, one shared implementation can still be the pragmatic choice. It can reduce coordination overhead when learning from users matters more than extracting the final percentage of platform-specific polish.

Shopify itself says React Native remains an excellent framework. Its apps are fast, and its original decision produced the benefits it expected.

The mistake would be to turn a useful economic argument into a universal technical rule.

AI changes the cost of duplication, not the existence of duplication

Native mobile development still means owning two applications.

There are still two platform SDKs, two sets of behavior, two release pipelines and two environments in which things can break. Product decisions, accessibility, performance, analytics, edge cases and app-store operations do not disappear because a model can translate Swift into Kotlin.

What agents can reduce is the implementation cost surrounding that duplication. Given a strong reference implementation and enough context, they can help with tasks such as:

• Translating a completed feature from one platform to the other

• Generating tests from shared acceptance criteria

• Investigating parallel defects

• Reviewing implementations for behavioral differences

• Helping experienced developers contribute outside their primary platform

• Repeating mechanical migration work consistently

That is enough to change the calculation. It is not enough to make the calculation irrelevant.

Shopify did not simply point an agent at the repository

The most useful section of Shopify’s article is easy to miss.

Its team found that asking an agent to inspect a React Native codebase and reproduce it natively in one large pass produced unmaintainable code that could not be shipped. Shopify built a controlled system called Helix instead.

Helix breaks work into small checkpoints. Each checkpoint must demonstrate its behavior with tests, pass visual comparison, survive independent reviews and receive human approval before the next one begins. Shopify is also restructuring application logic so agents can exercise it through fast, headless interfaces instead of slowly driving a mobile simulator for every test.

In other words, the advantage does not come from generating more code. It comes from building a delivery system in which agents can receive precise context, attempt bounded work and prove that the result is correct.

This distinction matters for every engineering team considering agent-led development. AI can increase output very quickly. Without specifications, verification and architectural ownership, it can increase the volume of mistakes just as quickly.

React Native or native: the 2026 decision framework

There is no percentage of applications that should automatically use one approach. Start with the product, the team and the expected lifetime of the system.

These are signals, not a scorecard. A technically complex application can still succeed with React Native, and a simple product can still have valid reasons to go native.

The relevant question is not “Which framework won?” It is “Which constraints matter most for this product and this organization now?”

Should existing React Native teams follow Shopify?

Not merely because Shopify did it.

Shopify operates several large applications used by millions of people. It has deep mobile expertise, substantial internal tooling and the ability to invest in a bespoke agentic migration system. Its decision can reveal a new option without making that option economical for every other company.

A rewrite also has an opportunity cost. While a team recreates working behavior, customers wait for improvements that only new product work can provide. Agents can shorten that period, but they do not make it zero.

Before choosing a migration, test the assumptions with a representative slice of the application:

1. Select a feature that includes real UI, business logic, data access and at least one platform integration.

2. Define its expected behavior independently of the existing implementation.

3. Implement it natively on both platforms using the current application as a reference.

4. Measure engineering time, review time, test effort, defects and product quality.

5. Compare those results with improving the same feature in React Native.

6. Include ongoing ownership and release costs - not only the speed of the initial implementation.

The result will be less exciting than a framework debate and much more useful to the business.

Our own position has changed

We have historically made the strongest version of the React Native argument: one implementation, one product team and substantially less coordination.

That remains a good answer for many products. It should no longer be presented as the default answer for nearly every product.

Makers’ Den now has experienced React Native, iOS and Android developers. That lets us approach mobile architecture without needing the conclusion to match a single staffing model. Sometimes the right answer is a shared React Native application. Sometimes it is Swift and Kotlin. Sometimes it is retaining a healthy application and improving the few native boundaries that cause trouble.

The arrival of capable coding agents makes this judgment more important, not less. They give teams more viable implementation options. They do not decide which option creates the best product.

The bigger shift is from code reuse to knowledge reuse

For years, cross-platform development concentrated leverage in shared source code.

Agent-assisted development creates another possibility: share the specification, domain model, tests, design intent and review criteria, then let each platform use the implementation best suited to it.

That does not mean source-code reuse stops mattering. It means source code is no longer the only valuable thing a team can share.

The teams that benefit most will not be those that generate the most code. They will be the teams that make product knowledge precise, testable and available to both humans and agents.

That is the lesson worth taking from Shopify.

Unsure whether to keep React Native, improve it or move toward native?

Makers’ Den can assess your product, codebase, roadmap and team before you commit to a migration. We’ll identify the actual constraints, test the risky assumptions and give you a practical recommendation across React Native, Swift and Kotlin.

Discuss your mobile architecture .