Is React Native Dead? What Shopify's Move to Native Actually Means

Shopify just announced that they're moving all of their mobile apps from React Native back to Swift and Kotlin.

If you build with React Native, that is a pretty big headline to wake up to.

Shopify has contributed to the React Native ecosystem for years, including packages like React Native Skia, FlashList, and Restyle. So this announcement carries weight.

Personally, it reminds me of Airbnb moving away from React Native in 2018.

Even when I was working at Expo in 2025, I still heard people cite that decision as a reason they wouldn't give React Native a shot.

Seven years later.

I hope we don't repeat that this time. React Native has come a long way, and Shopify is making this decision under very different circumstances.

In his September 10 announcement, Shopify's Mustafa Ali says its Shop app already made the transition, going from proof of concept to native apps in the stores in 12 weeks.

If you've worked at a big company, you know that 12 weeks is pretty damn good!

The Shopify app's migration is underway, with the rest to follow.

So, is React Native dead?

I don't think so. I still see a lot of value in building with React Native. I also want to be honest about where mobile development is going.

I've been experimenting with newer models, including GPT-6 Astra. In my own tests, they've become much better at working through multiple steps and checking their work. That makes building in an unfamiliar stack feel more approachable.

So my first reaction was that this makes sense. If an agent can help you build the Android equivalent of an iOS feature, the old argument about doing everything twice deserves another look.

After digging into Shopify's two articles, I think there is a solid argument here. Let's look at the details before deciding what it means for our own apps.

React Native worked for Shopify

Start with Shopify's own account: its move to React Native in 2020 was successful. Sharing code saved time, made it easier for engineers to contribute across platforms, and reduced the work of keeping features aligned. Mustafa's January 2025 retrospective was still positive about the framework.

The new announcement says agents have reduced the cost of separate Swift and Kotlin implementations enough to change Shopify's decision. Direct access to platform APIs and tools now carries more weight. It also acknowledges that maintaining two platforms still takes work.

For Shop specifically, this happened as the team was evaluating the work required to adopt React Native's New Architecture. That gave them a concrete choice about where to spend engineering time. Shop migration case study.

That context matters if your app is already running well on a current React Native stack. You may be facing a very different decision.

What actually happened in those 12 weeks?

The Shop case study describes a one-week iOS prototype by one engineer, followed by a production effort involving six core engineers and feature teams joining midway. Some screens were retired or simplified. The team worked to preserve sign-in, push notifications, and analytics behavior.

They were also rebuilding an existing product, with working implementations and established behavior to guide the agents.

Here are selected results Shopify reports:

Shopify measures the cold starts shown from tapping the icon until the first content appears in the home feed. It says iOS build times stayed roughly the same and session stability improved from 99.5%+ to 99.95%+. These are Shopify's measurements of its own apps. The size figures refer to release builds, which can differ from store download sizes. Source and comparison recordings.

Those results are worth taking seriously. I also like that the article includes the less exciting results. The iOS binary got slightly bigger. The iOS build did not suddenly become four times faster.

But this comparison changes several things at once: language, architecture, dependencies, and parts of the product. It cannot tell us how much of the improvement came from each change.

We also don't get an equally rebuilt React Native version using the New Architecture as a comparison. The article leaves questions about which devices were measured, over what period, and how much the results varied. I wouldn't treat these numbers as a general React Native benchmark.

And 12 calendar weeks tells us little about the full cost of the effort or what maintaining both apps will look like a year from now.

I would read this as a strong example of what this team achieved. I would measure my own app before expecting the same gains.

The workflow behind the agents matters

The detail that stood out to me is Shopify's warning about asking an agent to rewrite the whole app in one go. Its strategy article says those attempts produced code it could not maintain or ship.

Its Helix workflow breaks the work into small checkpoints. Each one needs tests, a visual comparison with the running app, two code reviewers looking for problems, and human approval. Shopify also separates business logic from the UI so agents can test it quickly from the command line.

The Shop team's account describes its own Pi-based migration workflow and Tardis debugging tools, and says native expertise remained essential.

My takeaway is that AI makes working across stacks more approachable. You still need a way to describe correct behavior, inspect the result, and catch the cases the agent missed.

The faster agents can write code, the more useful it is to give them a reliable way to check it.

AI can also raise the expectations

There's another side of this that I think is easy to miss: AI can also increase what's expected of an engineer.

If you've been building in React Native, a move like this can mean learning enough about both iOS and Android to review and maintain the native apps. If you specialize in iOS, you may now be asked to contribute on Android too, because an agent can help you get there.

The Shop team says native expertise remained essential. That's the part I keep coming back to. An agent can write the code, but someone still needs to understand whether it behaves correctly and take responsibility when it doesn't.

So I can see how AI expands the job, even when individual tasks get faster. Time saved on implementation can become time spent learning another platform, reviewing more code, or taking on another part of the product.

That doesn't tell us whether Shopify's engineers are working longer hours. My point is that the scope of the job can grow. AI making something possible can quickly become a reason to expect you to do it.

That's worth noticing when we talk about AI saving developers time.

What about Expo and the companies around React Native?

Several companies around React Native also offer tools for native development. Looking at their current products helps us understand what that means.

Expo's homepage lists Swift, Kotlin, and Jetpack Compose alongside Expo and React Native in its infrastructure offering. Software Mansion's Enriched Markdown supports React Native as well as standalone Swift and Kotlin SDKs.

That tells me these companies see an opportunity to serve mobile developers across stacks. Offering native tools doesn't mean they're leaving React Native.

The timeline is especially useful here. Codemagic announced native iOS, Android, and React Native project support in July 2020. Bitrise's own report on 2018 describes iOS and Android as its largest app categories going back to 2016. Native support has been part of their businesses for years.

Meanwhile, Expo UI lets you use SwiftUI and Jetpack Compose components from React. Expo also introduced inline native modules in SDK 56, making it easier to place Swift and Kotlin code alongside a React Native app.

So there is another path worth considering: keep the shared parts of your app and use more native code where it helps.

That is especially relevant to the AI argument. My read is that agents could also make custom native integrations easier to build inside a React Native app. The benefits of better agents can apply to both approaches.

The iPhone Duo shows why platform integration matters

Apple announced the iPhone Duo on September 9. A foldable iPhone is a good example of why being close to the platform can be valuable.

Apple's design guidance says apps using standard system components and already designed for resizing can adapt with little adjustment. The operating system can handle parts of that transition for you.

That is a real benefit of using the platform's components. But the conditions matter. Apple still asks developers to check layouts and custom UI. Its preparation talk distinguishes existing app compatibility from the behavior enabled by rebuilding with the new SDK.

React Native already documents changing window dimensions on foldable devices, and it supports custom native modules and components for APIs that are not exposed yet. You can wait for a library, contribute to one, or implement the integration yourself.

Handling a changing window size doesn't tell us whether every new iPhone Duo feature works. As of September 10, Apple's developer portal lists Xcode 27.1 beta as coming later this month. I haven't tested React Native or Flutter against that SDK, so I would wait for actual results before making a compatibility claim.

Shopify's decision tells us very little about Flutter's future, either. Flutter has documented large-screen and foldable support and ongoing releases. That still leaves specific new Apple APIs to evaluate, just as we would for other frameworks.

The useful question is how much platform integration work your product requires, and who is going to own it.

What happens to Skia, FlashList, and Restyle?

Shopify's open-source plans deserve attention even if you have no interest in rewriting your app.

According to its September 10 announcement:

• React Native Skia: Shopify sponsorship continues through 2026. William Candillon plans to continue through a fork and a new package name, with the original repository archived after the transition.
• FlashList: Shopify will fix critical compatibility issues while discussing long-term maintenance with other companies. A successor is not named in the article.
• Restyle: Shopify plans to archive the repository, keep it working through 2026, then end maintenance. A handover remains possible.

If you depend on these packages, follow the actual migration notices. There is no announced replacement package name in that article to switch to today.

My honest conclusion

So if you made it this far, here's my take: I don't think React Native is dead, and this doesn't change the value I see in learning and building with it.

Shopify gives us a serious example of what agents can help a team do. It also gives us a reason to revisit the assumption that two native apps are automatically too expensive to maintain.

I understand the appeal. Use the platform's tools directly, get help with unfamiliar syntax, and spend more time on the experience you want to build.

At the same time, React Native still gives you a shared application layer across iOS and Android. If you know React and that shared code helps you ship and maintain your app, that's a real advantage. I wouldn't dismiss it because another company made a different decision.

You can also keep React Native and add native code for the parts that need it. There is a cost here: a custom native module can mean maintaining Swift code, Kotlin code, and the interface that connects them to your React Native app. That interface adds work, but it isn't a third full implementation. The rest of your app may still be shared.

The same goes for new platform APIs. Sometimes you need an updated library or an integration of your own. That can be a small job or a real maintenance burden, depending on your app. Using native components through tools like Expo UI can also bring you closer to the platform while keeping React.

For an app whose main value depends on deep platform integration, I'd give Swift and Kotlin a closer look. For a team that benefits from sharing code, React Native still makes a lot of sense. Better agents can help with both.

If you already have a working app, start with the problem you want to solve. Slow startup? A missing platform feature? Too much upgrade work? Measure that problem before committing to a rewrite.

That's what I want people to take from this. Get comfortable enough with the platform to evaluate these choices yourself. That knowledge makes you a better React Native developer too.

The skill I want to keep building is the ability to ship and maintain a good mobile app, wherever the implementation lives.

If you want to stay in the loop on React Native, Expo, and building apps with AI, join my newsletter. I share practical breakdowns like this there.