Shopify went back to native. Most teams cannot afford to.

Read the post before you pick a side.

Shopify moving its mobile apps from React Native to Swift and Kotlin is not React Native losing. It is not native winning. Anyone framing it that way did not read what Shopify actually wrote.

They did not say React Native was slow. They said the opposite, in the announcement itself:

They called it an excellent framework that delivered exactly what they hired it for since 2020. Their engineering post is unusually honest about this. The framework did its job. The job changed.

What actually changed

The price of building twice.

In 2020, shipping two native apps meant two teams, two backlogs, two release trains and a permanent game of feature-parity catch-up. That cost was real, and React Native was the correct answer to it. Shopify said so at the time and they have not walked it back.

In 2026, coding agents do enough of the implementation, translation, testing and review that one team can carry both platforms. An iOS implementation becomes an Android one. Specs, tests and reviews keep the two aligned. Shopify rebuilt the Shop app natively and shipped it to both stores in twelve weeks.

So the thing that made the decision in 2020 has stopped being the thing that makes the decision. That is the entire argument, and it is a good one.

For Shopify.

The line item nobody is putting in the spreadsheet

Here is what I have not seen in any of the commentary: agents are not free, and the cost is not flat.

Translating an iOS implementation into a working Android one is not a cheap prompt. It is large context, many passes, and then the review and test cycles on top of it. Multiply that by three hundred screens. Then multiply it again by every feature you ship afterwards, forever, because the translation cost does not end at migration. It becomes your permanent cost of having two codebases.

Now look at what that runs into in practice. Claude's subscription plans meter in five-hour sessions with weekly caps on top. Codex has its own ceilings. Teams doing serious agent-assisted work hit these limits, and the answer is either a larger plan, API spend, or waiting.

Shopify can absorb that without a conversation. They have the revenue, the seats and the engineering organisation to make the numbers disappear into a rounding error.

A seed-stage startup cannot. A ten-person company still looking for its next round cannot. A services business running fixed-price projects definitely cannot.

If your team is rationing context because you are three days from the weekly cap, you do not have the mechanism that makes two codebases viable. You have the cost of two codebases and a tool that runs out.

React Native did not stand still either

The other thing missing from the discourse: people are comparing 2026 native against their memory of 2020 React Native.

The New Architecture has landed. The bridge is gone. That work is not new or risky anymore, it is finished, and the interesting signal is what came next. Expo SDK 57 ships React Native 0.86, and the release notes describe it as intentionally non-breaking, focused on stability now that the major architectural changes are behind it.

That is what a mature platform looks like. Not exciting, which is exactly the point. A framework that has stopped rewriting itself is a framework you can build a business on.

The talent argument is the one people undervalue

Most of the web runs on React.

That means a React developer can read, review and ship your mobile app. Your web engineers are not locked out of it. Hiring is a pool, not a search. When someone leaves, the person who picks up their work already speaks the language.

Going native gives that up. You are now hiring Swift people and Kotlin people, or you are asking your React developers to become both, and the agent that helps them write Swift does not give them the judgement to review it. That is a real retraining cost and it is mostly invisible until you are in it.

In my eight years I have watched the team size required to ship a serious mobile product collapse. Work that needed a group of twenty-five in 2020 can be done by five now, in my experience, if they have proper agent tooling. But those five still need to be five people who understand the ecosystem they are working in. The tooling changed the headcount. It did not remove the expertise.

Where native genuinely wins now

One place, and it is a real one: new hardware.

Apple unveiled the foldable iPhone Duo on 9 September. Adaptive layouts for a folding screen will work in SwiftUI before any abstraction above it catches up. That is structural, not a criticism of anyone. First-party frameworks get first-party hardware first, always.

If a new form factor is central to your product, sitting one layer up costs you lead time you cannot buy back.

I would not overstate this. React Native's community is enormous and it has absorbed every previous platform shift, usually within a release or two. But "the community will get there" is a fine answer if you can wait and a terrible one if you cannot.

So who should actually do what

This is the part the framework argument keeps people from asking. It is not about taste. It is about which costs you are carrying.

What I would tell a team asking me

If you are Shopify, or anything close to that size, Mustafa and his team made the right call. When millions of people open your app every day, platform depth stops being a luxury. A frame of jank, a hundred milliseconds of startup time, a scroll that is not quite right, all of it is worth real money at that volume, and sitting one layer above the platform is the difference between fixing it and filing an issue. Their budget absorbs the agent spend and their engineering organisation can staff both platforms properly. Their post is worth reading in full, and the commitment to hand over Skia and FlashList cleanly rather than abandoning them says something about how they operate.

If you are a startup trying to reach the market before your runway ends, React Native is still the answer, and the reasons have barely moved. One codebase. One team. A hiring pool the size of the web. A framework that has stopped breaking underneath you.

And if you are somewhere in the middle, the honest move is not to migrate on principle. Start writing your platform-specific work as proper native modules rather than fighting the abstraction. You get platform depth where it matters, you keep the shared surface where it does not, and if you ever do go native you already own the hard parts.

Shopify did not tell you to rewrite your app. They told you what changed for them, with their numbers.

Go and work out your own.

---

I lead a team of five engineers at VentureDive, shipping React Native and web products for banking, government and enterprise clients. If you are weighing this decision, I am happy to compare notes.