Shopify is moving from React Native back to Swift and Kotlin

- Google Chrome when released in 2008 conservatively had ~ 60 engineers.

- GTA 5 in its credits had 150 software engineers. Surprising even to me who has had many an experience of being in a bloated FAANG team, this 150 includes GTA Online!

In a sane society, Shopify’s opinion on anything engineering related would be thrown into rubbish because they seem to have managed to complicate a simple app into requiring thousands of engineers and now maybe millions in cloud spending to Frontier labs. This is unfortunately not an isolated case, Spotify for one has the same issue, idk what “engineering” Spotify is doing, it’s the worst app I’ve used in my life.

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.

I was rejected after a fairly basic ML interview at Shopify and when I asked for feedback I was told someday I could become a machine learning engineer.

I don’t think the interviewer read my resume or understood my responses as this was after working for several years in ML roles - staff applied ML and scientist.

So maybe that tells you something.

I say this because I was part of a migration from a mid-size React Native app to a Swift/Kotlin native app redo. I did the majority of the technical work on it. The majority of the work occurred before January 2026 and without LLM code assistance, though later features in the app definitely used some.

For anyone considering this, I'd say that the migration is definitely worth considering without even taking LLM assistance into consideration. The continued React Native tax of unnecessarily difficult upgrades, impedance mismatch w/ underlying core frameworks, and incredibly uneven library quality just cause your business to really spend a lot of time shepherding the tech over the finish line. It's pretty wonderful to be back in the world of "build, compile, ship, be sure". One thing as a fundamental principle that I think the Shopify article 'gets' at, is the importance of the feedback cycle - investing time in our integration test story very early on both helped w/ my cycle times, and later in providing guardrails for LLM assistance.

All to say that this decision is worth considering without even taking LLM assistance into account.

What we found led us back to native.

But now that all code is generated, there's little upside to having an RN app... just start native. Your devs are barely going to be writing code anyway.

After the app mature enough company should decide to move native.

I now avoid buying things from anyone who use the dreaded purple "shop" button.

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.

I am still mourning pre-React GitHub. Maybe rose-tinted glasses, but it was so pleasant to use

And now in the LLM era, there's is less and less justification for using those very high level abstractions, and we'll see many of them die out in the upcoming years. React (native or not) is not exception.

[ aside: Meta founded the development of RN and they don't even strictly use it; plus, any troubles/hacks they need, they can make to the Framework itself ]

Teams jump on the latest cross-platform framework assuming that it will reduce headcount cost at the expense of having a lowest-common denominator app on each platform.

The latter is true but the former is false.

What ends up happening is that teams start as 20 iOS engineers & 20 Android engineers. They adopt something like React Native. Then you end up with a team of 20 product engineers and 20 tooling and framework engineers.

I've seen that countless times in the last two decades.

For a while I've been wondering why people are even bothering with high level languages if you aren't even gonna read the code.

But I'm curious what their update will be in a year or two. Because these costs don't reduce as dramatically with AI (unless you fully give up control and vibe code it):

1. Reading code

2. Manually testing code

Who wants to bet there still won't be a dark mode?

> When simulator interaction is needed, the CLI can connect to them via a remote mode and drive the UI via commands without having to inspect the layout or the accessibility tree. This enables blazing-fast performance and E2E tests.

I think I'm not following. Don't you still need to test the accessibility tree and layout in the actual layer the user will interact with?

Big win for security

> Dramatically reduced the cost of maintaining parity between platforms through shared specifications, tests, and review checkpoints

I've used Kotlin Multiplatform on a mobile project built back before AI coding took off, and it was super nice to have shared core logic between the apps and there weren't really any downsides on the Android side, but on the iOS side it was definitely an extra layer that didn't feel fully 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.

Quality is, was and always will be job one. There's obviously a place for AI tools (providing the economy doesn't melt), but can we please just slow down for a second and think about what we're actually doing?

It worked for 3 hours and delivered a nearly feature complete port. Today, I found in manual testing 3 bugs and 1 performance issue, all of which it fixed afterwards. To fix the performance issue , it made several different builds and profiled them with Xcode.

At around 12:30 I had a full native app port of our product on my iPhone and iPad and could show it to my crew. It even did portrait and landscape correctl!

Needless to say, that I was flabbergasted. On one hand, I love it , I can build now all those cool stuff, but on the other hand, its a complete devaluation of my craft. I kinda tell myself that I was still the one setting up a proper env for it and that not everyone can do it. but thats coping. Freaking coping… and I know it

And, in all honesty, the difficult part with many projects is the bootstrap, the scaffolding, not the continuous dev. Agentic dev. made this a piece of cake.

follow up with some more technical details and benchmarks

That was my thought when I saw the headline and then reading the article confirms this is the inflection point per their own words. Very interesting.

Technologies are never the issue. The people is.

But I think this is perhaps one of the first AI developments I actually like. Transitioning an app from React Native or any web technology to native code has the distinct advantage that the native version should be much more economical in its use of resources.

I'm tired of hearing about RAM and other components hiking their prices while at the same time RAM sizes of ~8 GB are considered too small because things like Electron apps are wasteful in their consumption of resources. Now, with more native apps, we might get full circle: leaner apps thanks to agentic development. Maybe someday 8 GB of RAM could be considered enough once again. Truly interesting.

I've always been wary of React Native, because my impression is that it hides nuances of the underlying framework. You may be fine implementing 90% of your app but then need that last 10% and may get stuck.

But then I'm also wary of the recent trend by Google to create higher level frameworks on top of native Android APIs. It seems that these days for every Android API family, there is a Google framework that gives you a higher level API. I don't really understand it - is Google admitting that the quality of native Android APIs has eroded? Do they think developers are too inexperienced to deal with native Android APIs?

I'm also not sure I understand the how reasonably large companies consider two native apps to be too expensive. A startup may have a hard time funding both and may need to choose, but an established business should consider not only costs but also the better quality of user experience that native apps provide - that has to count for something.

I know JS and I know models still write a lot of garbage JS. I don’t know Swift so a model writing Swift all LTGM. Garbage is still there, I just can’t see it.

The solve isn’t another agentic harness. I need to learn more.

Lots of faster/cheaper justifications. I believe that part. If the quality bar is “web devs prompt models” then that’s a worry.

Code and optimization is going to be a niche moving forward

Hopefully they will write more about that in the future.

Odd banter. So did anybody using GitHub copilot which was in technical preview back then?

Interestingly Apple approved it very quickly, which I was afraid of given such a huge rewrite.

Then they say:

> We decided to switch from native to React Native in 2020 for three reasons:

> Stop building the same features twice

> Allow developers to work across the stack

> Spend less time chasing feature parity and more time shipping value

Totally!

Is there some kind of shame in just saying:

- we didn't want to hire more people

- we didn't want to pay those salaries

- we fired a lot of engineers with move to react native/hybrid in mind

- we could reuse the frontend devs (aka "full stack" folks) with or without some extra whippings ensuring they grok the bare minimum they'd need to build for mobile and test in on mobile.

The native apps will definitely be better in terms of performance and UX. However, having 2 codebases means twice the tokens.

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

The meta point of the article, I agree with though. The line is moving and AI makes having multiple platforms with code specific to them faster. Getting them right is still difficult.

Write once, deploy everywhere like React Native mainly benefits small teams and startups who are okay with building 90/10 solutions.

At the shopify's scale, they would want to go advance for every corner of the apps and use cases, and only native allows that.

I've written up a load of thoughts about that here[1], but in summary for the Shopify case, they're basically going to be spending a ton more than they have to by switching back to multiple apps and I'd predict another swing back to better cross-platform tooling in the coming years.

[1]: https://nativephp.com/blog/why-not-write-it-twice

“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.

React Native gives you (with asterisks) - one "source" for things to go wrong (as it sits on top of the native implementations of the UI + Native APIs). You are writing at that source level, and that filters down to the native builds. I am WELL aware to do certain things on each platform you need to get your hands dirty, but most apps are just serialising JSON from a database and displaying it.

AI writes very buggy, sloppy code.

They've decided - instead of containing that code to 1 surface, they would now have 2 surfaces they throw slop on top of.

I look forward to the 2027 version of this where they've gone back

Most orgs used REACT native becuase they simply didnt have the interest or talent to build mobile apps using native tech. Many many companies outsource the entire thing for the same reason.

So NOW that its been many years, and LLMs are there to help them they arent simply AFRAID to build a native mobile app anymore.

Thats the entire article. The rest is utter nonsense and bullshit.

Maybe React Native isn't the right choice - but two tech stacks for virtually identical interfaces is dumb. Three stacks if you include browsers.

Also, human developers and AI make different types of mistakes, and take different approaches to debugging. I'm not saying they shouldn't have done that, it's just that a more human-involved approach with AI filling the gaps would probably be a saner bet than 90% AI with some human interference.

Here's an example of why:

https://blog.coredump.cx/p/recursion-into-madness

Plus now with iPhone Duo which has so much variation in layout, I don’t think React Native would work well for it.

With cheap/fast code, it's easy to support multiple software stacks since most of the abstract engineering problems are already solved.

Code - especially straightforward low-level code - is so cheap and easy to write now that some people are building their own version control systems, game engines, and other low-level tooling.

Thus, some of the most demanding, human-centric work in software dev right now - where we now spend more time than coding - is in technical PM, UI/UX, devops, and overall architecture. The decision-making and design aspects of the job.

Exciting times.

Companies can now just afford to maintain a hundred different native apps, rather than settle for a write once, run anywhere approach.

they are going to "delete an app" because they got some LLM to slop out 2 apps?

The architect who wrote that is batshit and will be unemployed after this blows up in his face.

Lack of vision?

IMHO...

if you have a large org, a large app, lots of revenue and $$$ and resources...

it makes sense to do fully native now.

if you're a startup, you don't have the resources and $$$, you stick to RN

you can obviously have AI maintain both, but that is a cost. double maintenance = more $$$ on tokens

so many people are being doomer about this, but most people are also not Shopify

Like wouldn’t you want to invest in platform specific expertise long term?

It’s not like this is a small company or it’s just a dinky side project off of the main business

And that's not even discussing the heresy of app stores. Curse smartphones for ever happening.

So... local maxima?

> 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.

Perhaps these languages do not work well as they are not designed to run efficiently on mobile devices. Now that we have libraries such as SwiftUI and Jetpack Compose, React Native no longer makes sense to use.

Now we should also move away from Electron to better alternatives such as Kotlin Multi-Platform or fully native libraries on each platform; because of LLMs.

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.

In hindsight that also explains why they laid off so many ruby devs in the last two years. Now if only someone could have told the ruby core team that companies pursue their own interests ... perhaps then they would not have led to the fiasco about a year or so ago. (And prior to that, the silly 100k downloads restriction at rubygems, aka "after that point we no longer allow you to remove your own code", whereas Microsoft github has no such restrictions in place. What are these people smoking?)