When Shopify Dropped React Native for Native
In September 2026 Shopify said it's rebuilding Shopify, Shop, Point of Sale and Inbox in Swift and Kotlin. Dropping React Native paid off because coding agents made building twice cheaper than sharing one codebase, a reason most teams can't borrow yet.
Dropping React Native only makes sense when the cost of maintaining two native codebases drops below the cost of the cross-platform layer, and for most teams it hasn’t. Shopify announced on 10 September 2026 that it’s doing exactly that, rebuilding Shopify, Shop, Point of Sale and Inbox in Swift and Kotlin, six years after going all-in on React Native in 2020. The reason is worth reading closely, because it’s narrower than the headline suggests.
The trigger wasn’t that React Native got worse. Shopify’s own post says it didn’t. What changed is that coding agents got good enough to implement a feature on Android using the iOS version as a reference, and back the other way, so the duplicate-work cost that justified one shared codebase in 2020 mostly evaporated. Simon Willison made the same point: native still means building twice, that cost didn’t disappear, agents just absorbed enough of it that it stopped being the deciding factor.
What Shopify actually got for it
The numbers are real and they’re good. For the rebuilt Shop app, Android startup time roughly halved, from 4433ms to 2233ms, while iOS dropped about 23%. The Android app came out 109MB smaller, a 37% cut, though iOS grew by about 1MB. Session stability climbed to 99.95%+, which Shopify frames as a 10x reduction in sessions that crash. The team went from proof of concept to a published native app in 12 weeks, assisted by agents.
That’s a strong result. It’s also a result you get when you have Shopify’s engineering depth, Shopify’s agent tooling, and Shopify’s reason to care about a 100MB download on a merchant’s phone. Copy the decision without copying those and you’ve cargo-culted a headline.
A checklist for dropping React Native
Before you reach for the same move, run the actual questions. Take a side on each, don’t hedge.
Team size and shape. Two or three engineers holding a cross-platform app is the exact case React Native was built for, and dropping it doubles your surface area overnight. Shopify has hundreds of mobile engineers and agents to backfill the parity work. You probably don’t.
Native-feature pressure. If you’re constantly fighting the bridge to reach a widget, a Watch app, Siri shortcuts, or the newest platform API on day one, that friction is a real signal. Shopify called out widgets and lockscreen features specifically. If your app is forms and lists, the bridge is fine.
Performance that users feel. Startup time, scroll jank, app size on a cheap Android phone. If these show up in your reviews and your funnel, native buys something measurable. If they don’t, you’re optimising a number nobody complained about.
Hiring and maintenance. Two codebases need people who can own Swift and people who can own Kotlin, forever, plus the agent workflow that keeps them in parity. That’s an ongoing tax, not a one-off migration. Be honest about whether you can staff it after the exciting rebuild is done.
My actual take
Shopify made the right call for Shopify, and it’s a genuinely interesting signal that agents are shifting the build-versus-share maths. But the lesson isn’t “React Native is over.” The lesson is that the tradeoff moved, and you should re-run it for your own team instead of borrowing Shopify’s answer. For a small team without a fleet of coding agents, React Native still pays its rent every month. Shopify just found a tenant that pays more.