Shopify is moving from React Native back to Swift and Kotlin

Numbers from GPT Astra - Shopify has 3000 engineers as of 2026

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

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.

That Shopify employs 3,000 engineers is astounding.

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 agree w/ advising people to move off React Native, though I think the story that "LLM enabled an otherwise too-expensive migration to consider" is not correct.

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.

As an iOS Engineer that has been fighting the battle against every C-level type who brings up the subject of a shared codebase my whole career, I feel very validated.

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.

It seems like Shopify has fallen into a trap thinking that more complexity costs nothing because of AI. In the age of AI we have to embrace the same principle as before that complexity needs to be tamed, not multiplied. Even as humans struggled with complexity, from what I see now AI struggles very much the same. Hence I don't think this will age well.

React Native and Flutter as cross platform frameworks are best for Startups which can't handle 2 mobile developers. They can create MVPs in short time then start to looking for investors.

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

Models have gotten a lot better at generating native iOS apps. The main appeal of RN was being able to leverage your web devs for mobile dev. that's what I did at my last company. And it's fine for a startup, but eventually you want dedicated native engineers bc each platform really deserves its own technical masters who can optimize for it.

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.

I first learned about the shopify app when I saw a purple "shop" checkout button. Next, I got an email saying that if I wanted to track my package I needed to download an app. No thank you. I don't want your app on my phone. I don't want to browse other stores in the shop app. I want to see my package and its status without enjoying a new "social shopping experience" or whatever.

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

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.

And I'm just sitting here looking at the Codex desktop mac app wondering why a list, a chat window and textbox require a 579 MB download (compressed) and 4 GB of RAM.

My 2 cents on this as a fellow RN dev & contributor. - The performance gains in native compared to RN (new architecture) are minimal for normal UIs (except games) - The most valuable feature which RN have is OTA updates, this has been a game changer for us and many fast moving companies. Ability to release and iterate at light speed. On native you are on the mercy of the app stores for review. - Silos of bugs on native > When you go native you might encounter bugs which appear only on either platform. - The project management of native teams is not always in sync - The teams often drift apart bevy iOS team might need 2 weeks just to make the app compatible with the new iPhone Fold (Duo) or Android team might encountered a blocker. Keeping them in sync for new features is really hard.

I was just recently thinking about how we have built a lot of abstractions that makes it easier for a human to do useful stuff but they usually come with their own set of trade-offs.

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.

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

A multi-billon dollar company dropping quarters (performance/ux) to pick up pennies (development savings from not maintaining a native app) never made mathematical sense to me.

[ 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 ]

So, instead of paying humans twice for the same thing, Shopify will pay corporations to burn the planet a little bit more, waste water and energy - to build the same thing twice. Just because. There's no tech reason to do it. "LLMS are better now". There's no low level optimisations, no blockers, no app shortcomings, it's a shopping app for Christ sake. Instead of optimising, creating more with less, they will create the same with more. Yeah, that's smart. Super smart.

I'm sitting here at my desk overlooking Cordova Street. The street that Apache Cordova is named after. I've seen this debate for almost two decades now.

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.

Before I even opened the article I knew the reason was because LLMs don't need abstractions. React Native was always about making app construction easier for people who don't want to learn ObjC or Swift. If you're not writing or even reviewing the code yourself, this is unneeded overhead.

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.

Sorry not sorry RN was always the wrong choice, and I've made my money shipping React since 2013. Every RN project I've had to join has been a junk show and there is no way they operate more efficiently than 2 native teams. Don't even start me on Expo. Kotlin and Swift are nice, and ObjC/Java are still approachable IDK why people act like native is a big ask. I see people are in their feels already but I'm so glad so see Shopify stop carrying the RN banner, this makes giving the right advice to my clients easier.

I was excited to hear some details about how LLMs are changing big companies' workflows. This is a fairly straightforward problem and good on them for discussing it. My first gut reaction is that there is no way I would let LLMs write a significant amount of my codebase. And then I remembered that not invented here (NIH) is a problem I have. If I let it decide what code I ship, I am making the same mistake as writing all my code from scratch. When I find myself worrying about alignment, that is what rigorous computer security policy is for. If it's not catching serious bugs written by LLMs it's not catching bugs written by people. Treating my own code as if it was written by someone else is just another part of computer programming.

Bragging about "using agents to code pre-GPT" is quite the corporate flex... weren't they notoriously bad back then? Might as well say, "We've been doing spreadsheets with quantum computing since 2016"

And they still has zero job openings for Android/iOS devs

AI dramatically reduces the cost of writing code (especially when you have a reference), so the scale between native and cross-platform is going to tilt more towards native now compared to before.

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

I use Shopify app every day, multiple times a day to run my business and it has always been buggy and inconsistent for me on Android, and I don't expect this will make it any better, especially with more AI in the mix, but we shall see.

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

I'm not totally following the part about the simulator(s), probably because I haven't actually done mobile development before.

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

And so the mobile app development wheel turns. All of this has happened before, and all of this will happen again.

I remember their blog post claiming how much of a win it was to move over to react native and maintain high performance. They even listed their performance metrics. At that time I was a mobile developer for an e-commerce business and the metrics they were proud to share were unacceptable on our native apps. Here they are coming full circle

Not mentioned but this also gets them away from what now seems monthly npm supply chain attacks.

Big win for security

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

It's interesting that they don't mention Kotlin Multiplatform or any sort of shared core logic between their iOS and Android apps. Seems like maybe the apps are fully independent codebases but with shared specifications and tests? They say that agents:

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

This thread is very depressing. Web dev bootcamps and product managers have done untold damage to the field of software engineering. And it's our own faults. We had it so good for so long. There was a period of time when programmers were the new "rockstars" (for better or worse). We should have used that respect and those resources to unionise and build some kind of institution responsible for teaching, mentoring, standards, etc - a software engineering guild of some sorts.

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?

Debugging crashes across JS, C++, and native threads costs more than maintaining two codebases.

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.

Vibe-based architectural changes undoubtedly destined for "extreme" success until the next turn of the churn

Yesterday, just before bedtime, I pointed Astra at our Electron Desktop app, and asked it to write me a native Swift app for iOS. The electron app has 750 unit tests and 50 something integration tests. It also had access to the electron app via mcp and could click around and inspect it. I also gave Astra read only access to the backend code.

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

Truth is the Shopify app is simple enough to get right by a model. Lots of things hare simpler to get right in native code, so it is to be reiterated - a lot of interpreter code/libs is going down the drain, along with the devs that write it. These are not needed anymore.

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.

The most interesting part to me here was the whole helix thing + how they split business logic and UI just so AI agents could drive/test state via a CLI. I hope they do a deeper blog post on just that. I’m surprised they are making “decouple state from UI” sound like something groundbreaking when that’s kind of been the foundation for any sane/testable app for a LONG time.

https://shopify.engineering/shop-app-migration

follow up with some more technical details and benchmarks

I agree with this but not just React, React-Native. There's many libraries I no longer have a need for. I've made several JS 3d apps just asking the LLM to write the 3D code from scratch. AFAICT they usually shed 2meg of library and run 1.5x to 3x faster as the LLM will do the optimal thing for the situation.

In the age of LLMs, I get why you would dump portablity in favour of close-to-the-metal Swift and Javascript codebases. However I don't really understand the need for Kotlin- surely thats just an unnecessary complication and performance hit?

The promise of React Native was easing development burden from the web app to the native app. It makes sense if they are just using coding agents to cut out the framework and just go native.

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.

The one topic that is almost not addressed in this post is: what happens to the React Native developer team?

Technologies are never the issue. The people is.

React native isn't a terrible idea, its fundamental issue is that Apple does not allow for JIT compilation on iOS. So that means your app's js logic will be an order of magnitude slower than what you would get in the browser.

Yep. First time I "wrote" a native iPhone or Mac app in about 9 years was recently. I've written plenty of C, C++, Rust, etc code but always found Swift and ObjC to be uniquely bad, and Apple's UI frameworks and tooling are terrible. So one way or another wanted it to mostly not be my problem. First that was RN's job, now it's Claude's job.

I'm an user; I have zero or near zero development and programming knowledge, so this take of mine might be complete nonsense.

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.

is there still no way to compile / execute ios apps on a linux machine ?

I wonder why not Kotlin Multiplatform. I’ve been using LLMs to build with KMP for about 10 months and it’s a delight and you can use native Swift UI when you want to. It seems to be the best of all worlds.

I made this argument at my previous company a year ago and was shouted down by most of the mobile engineers. I have since departed, but knowing how much Shopify's engineering blog is worshipped there they will now say this is the future.