Will AI Kill React Native?

Good morning, Vibe Coders!

I recently read an old article: on September 10, 2026, Shopify announced a return from React Native to Swift and Kotlin.

This is very interesting!

Because in 2020, Shopify decided to fully adopt React Native and considered this choice very successful.

Features only needed to be developed once, saving a lot of time; developers without a mobile development background could participate in app development; no more constantly chasing to fill in features on both platforms.

Even in January 2025, when AI coding was just beginning to show promise, Shopify still believed React Native had a bright future and would continue to invest.

Given the information Shopify had at that time, this judgment was not wrong.

React Native served their needs well, and to this day it is still an excellent framework.

However, since then, the capabilities of the programming model have greatly improved. For Shopify's apps and team, the cost of implementing the same feature separately in Swift and Kotlin is no longer as high as before.

So this year Shopify re-evaluated its mobile tech stack from the most basic questions.

The result of that evaluation was a return to native development.

Why return to native development

In 2020, Shopify moved from native development to React Native, mainly for three reasons:

• Not developing the same feature twice;
• Allowing developers to work across tech stacks;
• Spending less time filling feature gaps between platforms and more time delivering valuable features.

Over these years, React Native has indeed delivered. Although Shopify also spent considerable effort optimizing performance, improving core capabilities, and keeping up with framework and external dependency updates, they said these investments were worthwhile.

So the question arises: the same feature still has to be written twice, how did the cost change?

A feature previously written once in React Native, now written separately in Kotlin and Swift, why do they think it's worth it?

One thing you may not know: Shopify has been using LLMs for software development since 2021, a year earlier than ChatGPT!

Initially used mainly for implementing features, debugging and fixing bugs, and reviewing code. As models improved, more complex work was delegated to them.

By the end of 2025, Shopify began rethinking a question: does developing software twice still mean twice the work?

So they used LLMs to rebuild some core parts of several large apps in Swift and Kotlin to verify the actual effect. They found that agents could already reference the iOS version to implement Android features, and vice versa.

Developers can also use agents to become familiar with work outside their primary tech stack more quickly. Combined with shared specifications, tests, and review checkpoints, the cost of maintaining consistency between the two platforms dropped.

Of course, this doesn't mean native development suddenly only has one codebase to maintain. The two platforms still have to be developed and maintained separately. It's just that agents now bear enough of the implementation, code conversion, testing, and review work that this cost is no longer the decisive factor in choosing technology that it was in 2020.

But native development still has a big advantage: more direct use of platform capabilities and official tools, reducing the burden of framework adaptation and dependency maintenance.

In other words, even if runtime speed hasn't improved significantly (though, that said, which cross-platform framework can match native performance now?), the development and maintenance gains may make Shopify think the switch is worth it. Think about the process of adapting new APIs: if a cross-platform framework doesn't support a new API, you have to write your own bridge layer or find a third-party library to do it!

Of course, React Native apps can be fast, and Shopify's apps are. Their adjustment this time is mainly because the cost advantage of shared implementation has shrunk; runtime performance was not the deciding factor.

What about Shopify's open source libraries?

Shopify has moved to native; what about developers using their open source libraries?

Below is the arrangement given in the original article when it was published in September 2026.

React Native Skia

Shopify will continue to sponsor it until the end of 2026, after which William Candillon will continue development. He plans to fork the repository in the coming months, release the library under a new name, and then archive the original repository after the transition.

Shopify says it will keep publishing progress, leaving users time to migrate, and also calls on teams that depend on this library to consider sponsoring it.

FlashList

FlashList has about 2 million weekly downloads and has become a common choice for high-performance lists in React Native. Shopify will continue to fix critical compatibility issues while discussing long-term maintenance with other companies.

Teams interested in taking over can contact the article's author, Mustafa Ali.

Restyle

Restyle has a relatively small user base. Shopify's plan is to archive the repository, keep it working until the end of 2026, then stop maintenance. If a team is willing to fork and take over, they will assist with the handover.

Rebuilding a native app in 12 weeks

How exactly does Shopify migrate? If your team intends to migrate, you can refer to their approach.

Shopify doesn't have just one app: Shopify, Shop, Point of Sale, and Inbox are used by millions of merchants and buyers worldwide every day.

They discussed two approaches: gradual migration within existing apps, i.e., brownfield; or rebuilding from scratch, i.e., greenfield.

When they moved to React Native last time, the largest apps chose progressive migration. Because rewriting from scratch would take years and require stopping delivery of new features during the rewrite, which was too costly.

But this time, they chose to rebuild from scratch.

Readers can probably guess why: LLMs can already reference the React Native version to implement features in Swift and Kotlin; starting from scratch can escape existing constraints; initial prototypes showed that rebuild speed is much faster than before programming agents existed.

The first to complete the migration was Shop, the app that often tops the shopping category in app stores. According to Shopify, with AI, the team took only 12 weeks to go from proof of concept to a fully rebuilt native app published on the app store.

Note: This "12 weeks" refers to Shop, not all Shopify apps.

At the time the article was published, the Shopify app was still being migrated, with a planned release later in 2026. It is their largest app, with more than 300 pages, home screen and lock screen widgets, an Apple Watch app, watch face complications, Siri shortcuts, and more. The remaining apps are also in the migration plan.

How to avoid generating a pile of low-quality code

At this point, you might think: since there's existing React Native code, just have AI rewrite it, right?

Shopify's conclusion from testing is that this doesn't work.

Even if you have the model gather as much information as possible, organize specifications and task files, then implement at once, you'll still end up with a pile of unmaintainable, undeliverable code.

They built a system called Helix for this. The approach is to break work into small pieces, and verify each piece after completion. The first output can be wrong, but if it's not fixed, you can't move on.

If you've used Matt Pocock's skill set, you'll know /to-spec and /to-tickets; it looks similar, right?

Specifically, the developer first specifies a page, Helix reads the corresponding React Native code, then proposes a sequence of checkpoints. The workload of each piece must be kept small enough to review in minutes.

Then, implementation proceeds checkpoint by checkpoint. Each piece requires:

• Tests proving correct behavior;
• Visual review confirming consistency with the running app;
• Adversarial code review from two reviewers;
• Finally, a human approval before committing code and moving to the next piece.

Helix is rebuilding a page of the Shopify mobile app in Swift and Kotlin

Feedback from each review is retained. As the migration progresses, subsequent work can reference this feedback and gradually reduce manual intervention.

According to Shopify, this approach has worked very well, shortening the time to rebuild apps to a fraction of what it was.

Changing code takes seconds, verification takes minutes

Breaking tasks into small pieces isn't enough; verification itself must also be fast.

Another problem Shopify encountered was that agents weren't reliable enough to control the simulator; building, testing, and iterating often required human supervision. They also developed tools for agents to autonomously reproduce bugs, fix them, and verify, but the whole process was still slow and not stable.

Why?

Because agents usually need to obtain the app state via screenshots or accessibility trees, then perform actions and check results. Code changes take seconds, but verification takes minutes, so iteration naturally can't be fast. React Native's module hot reload can alleviate part of the problem, but it can't solve the fundamental slowness of simulator control.

Shopify's approach was to adjust the app architecture: fully decouple business logic from the UI so it can run headless directly in the desktop environment, and expose these capabilities to agents via a CLI.

This way, checking state, navigating between sections, and performing actions doesn't require starting the simulator and manipulating the UI every time. According to the original article, this part of the iteration can be shortened from minute-level to millisecond-level, and allows agents to work autonomously for hours.

Of course, when UI verification is needed, the simulator is still used. In that case, the CLI can connect to the simulator in remote mode, driving the UI directly with commands, avoiding the need to rely on layout or accessibility trees to determine actions, and can also be used for fast end-to-end (E2E) tests.

To be clear: business logic can run quickly independent of the UI, but that doesn't mean the visual effects and interactions of the entire app don't need verification. The visual review and human approval in the Helix process earlier are still retained.

Next steps

According to the plan in the original article, Shopify will migrate all mobile apps to Swift and Kotlin, using AI throughout the process.

They also explicitly state that every rebuild must meet or exceed existing performance, stability, accessibility, and product quality requirements. After the migration, they will also look at whether product iteration is faster, whether app quality is better, and how much work agents can do autonomously.

In the future, they plan to continue sharing Helix, the agent-operable app architecture, and experience in developing mobile apps with agents.

At the end of the article, Shopify still affirmed the React Native practice of the past six years and thanked the teams and community involved. Native development is their current choice, and React Native was the right choice for their situation in 2020.

A side story

Actually, earlier this year, my colleague asked me: what is the best cross-platform development framework right now?

Me: What platforms are you planning to support?

Colleague: Mobile, web, mini-programs.

I said: Why don't you try Uni App.

I know many developers, including myself, must think Uni App is a garbage dump framework, but it is undeniable that once you have to do cross-platform development that supports mini-programs, Uni App is almost the only choice. I know there's also Taro, but its market share in China is small, so it's almost never considered.

Later I asked him: It's 2026 now, why do you want to use a cross-platform framework?

His answer was consistent with Shopify's early considerations: few people, want to reduce costs.

I said: Do you know how much it costs to maintain cross-platform bugs?

I had already given a conclusion at that point: the first thing large models will kill is cross-platform.

Of course, that's a bit absolute. Looking back, maybe a more accurate statement is: in the era of large models, cross-platform is no longer the first choice for development!

Some thoughts

How does AI change the cost considerations in technology selection?

In the past, "not having to write the same feature twice" was very attractive; now, if the cost of developing the two platforms separately drops, using platform capabilities more directly, and dealing with fewer framework adaptations and dependency issues, may make maintaining an extra codebase worthwhile.

It's worth noting: Shopify didn't throw the entire codebase at AI and wait for it to deliver. They broke tasks into small pieces, retained tests, visual review, and human confirmation, and even specifically adjusted the architecture to let agents verify code faster. It looks like even after models become stronger, teams still have to put effort into making them usable and fast to verify.