Native Mobile Apps Are Back — and React Native Isn't the Way Forward

On September 10, 2026, Shopify published Back to Native: after six years on React Native, it is rebuilding its mobile apps — Shop, Shopify, Point of Sale, and Inbox — natively in Swift and Kotlin.

This isn’t a hot take from someone who never shipped with the framework. Shopify was React Native’s most visible corporate patron. It ran some of the largest React Native apps in the world, employed people who maintained the ecosystem’s load-bearing libraries, and as recently as January 2025 published a post arguing the framework’s future was bright. The same author wrote the reversal.

When the company that maintained your dependencies starts rewriting its apps without them, that’s not a trend piece. That’s a signal.

What actually changed (it isn’t that React Native got worse)

Shopify’s argument is economic, not technical. The 2020 case for React Native was never “this produces better apps than Swift.” It was that building the same product twice cost roughly twice as much — two teams, two implementations, two sets of bugs, and a permanent tax on keeping features at parity.

By late 2025, coding agents were good enough that the premise stopped holding. Agents can carry a feature across two codebases, translate an implementation from one language to another, write the tests, and review the diff. The duplicated work that cross-platform frameworks existed to eliminate is now the cheapest work in the building.

What’s left when you remove that advantage is the bill cross-platform always quietly charged:

• A layer between your code and the platform. Every framework and dependency in that stack has to be learned, updated, debugged, and reconciled with the OS underneath.
• Waiting for the ecosystem. Apple ships a new framework in June; your app gets it when a package exposes it — if a package exposes it.
• Escape hatches everywhere. The “single codebase” ends up as a shared core wrapped in native modules, platform conditionals, and performance fixes that bypass the abstraction.

We wrote the long version of this argument in AI Makes Native Apps Affordable Again back in July. Shopify just ran the experiment at a scale nobody else can: their Shop app went from proof of concept to published on the App Store in twelve weeks. The Shopify app — 300+ screens, home and lock screen widgets, an Apple Watch app with complications, Siri Shortcuts — is in progress.

The part everyone will skip: the bottleneck was testing, not typing

The most useful detail in Shopify’s post has nothing to do with React Native.

Their agents could write code in seconds but needed minutes to see whether it worked, because verifying a change meant driving a simulator — slow, brittle, and prone to needing a human to unstick it. So they restructured the apps to run headlessly and gave agents a CLI to inspect state, navigate, and perform actions directly. Iteration went to, in their words, “milliseconds instead of minutes.”

That’s the real lesson of the post, and it generalizes past Shopify: native development with agents is only as good as the loop that tells the agent it was wrong. Code generation is commodity. Verification is the product.

It’s the problem we’ve spent most of our engineering time on. When Cabano builds your app, it compiles a real Xcode project, boots a real iOS simulator dedicated to your project, and watches what happens. Build errors go back into the loop and get fixed without you seeing them. You get a live, interactive simulator in the browser — tap it, type in it, rotate it — not a phone-shaped <div> rendering a website.

Different scale, same conclusion: the reason native was expensive was never Swift. It was the feedback loop around it.

The dependency signal underneath the announcement

Read the maintenance section of Shopify’s post carefully, because it’s the part that affects you even if you never touch a Shopify app:

• React Native Skia is moving to a fork under its original author; the existing repo gets archived.
• Restyle is archived — maintenance stops after the end of 2026.
• FlashList, at roughly two million downloads a week, is looking for a long-term stewardship partner.

Shopify is being unusually responsible about the handoff. But the direction is clear: a major sponsor of the React Native ecosystem is stepping back from maintaining it. If your app depends on those packages, the risk that used to sit on Shopify’s roadmap now sits on yours.

Native frameworks have a different failure mode. SwiftUI is maintained by the company that also ships the operating system, the compiler, the IDE, and the store. It does not get archived.

If you’re not Shopify, the math is even more lopsided

Here’s the thing about the cross-platform trade: it was always a compromise made by companies choosing between one mobile team and two.

If you’re a solo founder, an indie developer, or a small business with an idea, you don’t have two mobile teams. You have zero. “Which single codebase covers both platforms?” was never really your question — it was inherited from companies with a hiring budget and a parity problem. Your question is simpler: what should I put in front of the users I actually have?

For most people reading this, that’s iPhone. It’s where the paying customers are, where in-app purchases convert, and where users have spent nineteen years learning precisely how an app is supposed to feel. They can’t name what’s wrong with a wrapped web view or a bridged component — but their thumb knows. (We went through the tells in Native SwiftUI vs Web Wrappers.)

Building that properly used to mean hiring an iOS developer at $120k+ or learning Swift yourself. That’s the constraint that broke, and it broke in the same direction as Shopify’s.

What Cabano generates

Cabano has been native-first since before this was a trend, for exactly the reasons Shopify enumerated. When you describe an app in chat, you get:

• A real Swift and SwiftUI Xcode project — Apple’s frameworks called directly, no JavaScript bridge, no WebView, no runtime shipped inside your bundle.
• Current iOS design language — iOS 26 materials, sheets, and transitions, because SwiftUI gets them the day Apple ships them rather than when a package catches up.
• Games on Metal 3 — a real GPU renderer, not an HTML canvas pretending.
• The rest of a shipped app — in-app purchases via RevenueCat, push notifications, a backend when you need one, and publishing to TestFlight and the App Store under your own developer account.
• The source code, pushed to a GitHub repo you own. Any iOS developer can open it in Xcode. That’s the honest test of whether a builder generates native code — ask any tool you’re evaluating whether you can download the Xcode project, and watch what happens.

When cross-platform is still the right call

We’re not going to pretend the answer is always native, and neither did Shopify.

React Native and Flutter still make sense when you need iOS and Android on day one with one budget and one team; when you already have a healthy React Native codebase and a team fluent in it (a rewrite is a cost, not a virtue); or when your app is genuinely a view onto a web product and always will be. Shopify didn’t say React Native was a mistake — they said the assumption that made it the obvious default stopped being true. Those are different claims, and the second one is the important one.

If cross-platform is your lane, we’ve written a straight comparison with Rork, which builds React Native apps. We’d rather you pick the right tool than pick ours.

The bottom line

For six years, the default answer to “how do I build a mobile app?” was “write it once in React Native.” That default existed because writing it properly for each platform was too expensive.

It isn’t anymore. Shopify has the engineers and the data to know that, and they’re acting on it at the scale of apps used by millions of merchants and buyers. The same shift is what makes a native iPhone app reachable for one person with an idea and no Swift experience.

Native isn’t back because the industry got nostalgic. It’s back because the reason we left stopped being true.

Describe your app and see what compiled Swift feels like on your own phone.