Shopify is moving from React Native back to Swift and Kotlin

fnthawar2 944 points 634 comments September 10, 2026
shopify.engineering · View on Hacker News

Discussion Highlights (20 comments)

fnthawar2

We don’t hold on to a decision just because it was successful at the time. When a core assumption changes, we’re willing to go back and ask whether it’s still the right call. LLMs changed one of the core assumptions behind our 2020 decision, so we reevaluated our mobile stack from first principles. What we found led us back to native.

lackoftactics

I believe this will be overall trend in industry. Dropping React Native and Flutter for native

quotemstr

The wheel of fashion turns once more.

gazarsgo

Cool story but what's the token spend?

evilfred

using React Native you end up having to drop into native code to do anything interesting or optimized, so it feels kind of pointless to not just use the platforms directly

asimovDev

Dropping React and going back to raw JavaScript next? I am still mourning pre-React GitHub. Maybe rose-tinted glasses, but it was so pleasant to use

kraig911

A side effect of perceived LLM Generated code is now easier to just make it write native I guess.

sergiotapia

Major loss for react native community at large with Skia and Flashlist dying. :(

giebisch

Their reasoning makes sense. I'd love to read a follow-up and their thoughts in half a year.

starlineventure

Native. Metal. Remove the abatraction layers

976157424477

… from React “Native”

randysalami

“We debated between gradually migrating to native (brownfield) versus rebuilding them from scratch (greenfield)… However, this time greenfield emerged as a clear winner for the following reasons” “To solve this problem, we built a system called Helix that takes a more gradual approach. It doesn't expect the first output to be correct, and builds a loop where an imperfect attempt simply cannot move forward until it becomes a good result.” If this is driven by proper engineering then hats off! Supposedly a simpler app has already been migrated and they are working on migrating the main app using this approach. I don’t even know how I can be a cynic here… because the technology is good enough and so are the engineers I don’t know how management or executives could ruin it. “…product quality people expect today. This isn’t just the same apps rewritten in different languages. We’re rebuilding them so both humans and agents can understand, test, and change them quickly.” If this was written using AI and human-edited, you missed a spot.

hermitwriter

I've been around long enough to see this argument come and go under a lot of different names. This time it's AI. Maybe AI really does change the economics. But this post doesn't demonstrate it. Talk to me in a year. The side-by-side comparisons? Whoopty do. It's different code. Of course agents can produce two implementations that look the same today. That's not the hard part. The hard part is keeping them the same. Feature parity isn't an implementation cost. It's a divergence cost. It accrues over years across experiments, analytics, accessibility, edge cases, bug fixes, platform behavior, and a thousand little decisions which current agents aren't great at tracking. Agents can write code fast but they aren't a panacea. The load-bearing sentence in the whole post is this: "Shared specifications, tests, and review checkpoints dramatically reduced the cost of maintaining parity." Okay. For how long? By how much? Got any numbers to share? How will these hold up under contact with customer? You haven't maintained parity yet. You've built prototypes. You're making a claim about a cost that compounds over time based on what it costs at t=0. The other thing missing is the counterfactual. They keep comparing this rewrite to what a rewrite would have cost before coding agents. But what if you point those same agents at the existing RN codebase? If agents make software development cheaper, they make RN development cheaper too. And now you're modifying one implementation instead of generating, testing, reviewing, and reconciling two. The tooling section makes this even stranger. They find that agents are bad at driving simulators, so they pull business logic out of the UI, make it runnable headlessly, and expose a CLI. That's a good idea! Do that! But that's an architecture change, not an argument for native. You can make an RN codebase agent-friendly without rewriting five apps. Then you get to "Preventing slop," which is probably the most important section in the post. Just pointing an LLM at the codebase doesn't work. They had to build Helix, with ordered checkpoints, test proofs, visual diffing, adversarial reviewers, and human gates. So what they've actually demonstrated is that Shopify has enough engineering resources and agent infrastructure to make maintaining two codebases look economically plausible. Maybe it is! For Shopify. That's a much narrower claim than "AI changes the economics of cross-platform development." And where are the numbers? For a post about reevaluating costs from first principles, there's remarkably little cost data. Engineer hours? Review time? Defect rates? Parity failures? Agent spend? Ongoing maintenance? Anything? They even say RN performance isn't the problem. "React Native apps can be fast. Ours are." So there's no product crisis here. No performance crisis. There's an internal cost argument, with no numbers, being used to justify rewriting five apps used by millions of merchants. And in isolation I'd probably just shrug and say: Shopify made a bet. Let's see how it goes. But it's harder to view it entirely in isolation when they brought Tailwind on yesterday too. Shopify used to be one of the great stewards of the broader ecosystem. What worries me about the recent direction isn't any single technology choice. It's the appearance that, following the recent tech leadership changes, we're starting to see decisions driven more by the preferences of the people now making them than by demonstrated technical merit. Maybe that's an unfair read. I hope it is. But posts like this don't help, because if you're going to make a sweeping technical argument for a major change, show the evidence. The part I actually find convincing is much less exciting: Shopify is tired of paying the upstream tax. They've spent years working on RN performance, improving the framework, dealing with dependencies and upgrades, etc. Fair enough. That's a real cost. Being an RN framework developer or dependent is -- or has been -- awful -- it's like trying to fly a kite in a hurricane. The web team has been super disciplined and also ridiculously slow. The RN team changes apis in .. questionable ways with regards to compatibility But it's not new, and it has very little to do with LLMs. And let's not get me started on taking this kind of dependency for your business on companies who still don't have any idea how much to charge for their tools and are all operating (on a per token basis) at a loss. They're swapping some framework dependency for dependency on coding models whose capability, pricing, and terms they don't control. None of this means they're making the wrong decision. Maybe they're right. Maybe in three years this looks obvious. But that's exactly the point. Come back in a year and show me parity bugs, engineering hours per feature, experiment drift, accessibility regressions, review burden, model spend, and how much human work it takes to keep the implementations aligned. Right now they've shown that AI makes rewrites cheaper. Whoopty do.

yieldcrv

Perfect, yeah the obvious answer and comment is in the subtitle right at the top. Good way to write an article > Coding agents changed what it costs to build mobile apps twice. Here’s why Shopify is moving from React Native back to Swift and Kotlin.

Waterluvian

If you put every company that needs/has an app on a spectrum, there is a line somewhere that roughly divides them into two groups: where Electron/React Native/etc. makes sense or not. It's just a normal engineering decision: solving problems given limited resources. Companies have different problems and different resources. I think people in the tech community have probably also noticed that it's rather popular to have an absolute opinion on the goodness or badness of these tools. There's some magical thinking borne from ignorance that everyone just ought to go native or that React Native is the best thing ever to be used everywhere or that AI makes this line disappear entirely. I think these takes serve little value and distract from what’s interesting, and what the subtitle to this article says: that this line is moving due to AI. And I think that’s probably right.

pzo

Wish they explained more. Even though I'm mostly native iOS its seems react native is better stack for AI and iteration (hot refresh etc) - the main reason pretty much all AI vibecoding app were implemented via expo/react native. I also believed that finally this year react native got mature enough with improved tooling and performance to the point that it started to being 'boring' technology.

atonse

We did the same thing - had 90% of it overnight. Then spent a few days in the background tweaking for polish. Our app is smaller, and has about 15-20 screens. I started at about 12:30am by giving codex a goal and it inventoried every screen based on the react native code, then created android and iOS directories, used maestro (I had already set up this tooling for a previous personal app build a few weeks prior), and had the whole thing working in android and iOS in the morning. Took it about 6 hours while I slept. The app is way smaller, launches instantly, and the android app is (supposedly) native looking. I say supposedly because I don't use android phones. But it's using Jetpack Compose and Kotlin. And I don't know Swift or Kotlin. I honestly don't see the point of React Native anymore. I know Expo is doing very cool agentic stuff, but I'm just not sure why I'd need any of it when I can write a native app.

railka

IMHO, now is a great time to use native Swift/Kotlin code alongside shared Rust code via UniFFI

faangguyindia

React Native is slow. Hermes VM doesn't even have JIT. If the majority of your app is native code and only a few places are stitched together via JS code that runs in the Hermes VM, then React Native is suitable for you. Look at V8 vs. Hermes performance. We use Flutter; we rarely need to write native code. We have three apps: Symbiote workout app, CalorieCodex, an AI calorie tracker app, and MacroCodex with 17,000+ users, all of them completely free

roshanabdullah1

the reason what I believe is that, AI can understand react very well. so It can be beneficial for Shopify

Semantic search powered by Rivestack pgvector
6,164 stories · 56,060 chunks indexed