Hacker News

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.

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.

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

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.

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.

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.

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.

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

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?

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.

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.

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.

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"

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.

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.

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

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.

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

follow up with some more technical details and benchmarks

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

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.

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.

> Shopify has been using LLMs to build software since 2021

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

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.

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.

Most of the costs of switching have yet to be borne: user issues with untested code, maintenance issues with code few understand, and the strategic dependency on coding LLM's, which will change in character after providers go public and need revenue to fit reasonable stock multiples. All only get worse with time unless they're addressed proactively.

I forsook RN years ago. I am not a huge fan of the JavaScript ecosystem in the first place, and the UX of RN apps is not the best. Instead, I adopted Kotlin Multiplatform (shortly after their memory management overhaul). I haven't been disappointed. As coding agents have come along, they are really good at writing both Swift and Kotlin, and I get to write all the business logic once. UI can either be shared with CMP, which is quite good, or platform-specific.

An Android developer since 2010 here.

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.

Surely the decision comes down to whether they have the expertise to build native apps.

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.

I think in the end, we should just be writing some prototyping language, then let AI translate into target/native development language of the said platform.

Code and optimization is going to be a niche moving forward

I think the most interesting part of this story is actually the Playwright-style “driver” that they built into their new apps to support faster verification by the agents.

Hopefully they will write more about that in the future.

Maybe cross platform devkits would not be choosed only becauseof development cost.

If they play this right, they can do much more than just ecom and move into agentic templates and start selling slack and jira templates

Native is the new React?! I could never drink the React Native cool aid due to background in performance optimization. Agents gave us the way to go native with less effort. Compilation is a good feedback loop for the agentic workflow as well.

They don't say anything in the post. But hotwire native supports pushing ui elements to ios and android. I imagine that might be part of the reason. I haven't built anything substantial with hotwire native though so I am not sure on all of the edge cases.

We made the same change for our patient app last month, took 2 months to rewrite from react-native to two mobile apps, but we had the PoC in under a week.

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

Yea, I have started using c++ for some of the stuffs previously used python for. When agents is doing the grunt work, better to go even closer to machine.

As things get more complicated and you need to worry about performance, where every millisecond counts, it makes sense to go to native: React Native and Flutter. These kinds of technologies are really good in terms of building faster and building one app which can work across. Where that deep performance might not be of a bigger concern, or you need to go build components natively and then expose them through React Native. I think, with AI, now building even a native app is faster, so moving back to native can make sense if you have a team which can understand how things work.

This is exactly the decision we have made (though we didn't start with native). It just makes a lot more sense to make native apps and customize to take advantage of different native capabilities. AI essentially makes this a lot easier, and the end result just feels a lot nicer.

Few of the biggest reasons for "migration" to the likes of React Native, and web-views et cetera, were "lack of talent", and not getting that talent fast, and for cheap, et cetera, while of course terming that as innovation, embracing the future, and "that's where the game is at" et cetera. Now with the LLMs that is mostly sorted. So if anything I'd be able to see the eradication of the Electron infestation in my lifetime. But then I see the very tools these LLMs are accessed with i.e harnesses (and of course mostly made by the LLM houses) are made of Electron or similar things (sometimes a Frankenstein like mix). And even today Claude Code shows up as `2.x.yyy` for process name ffs! So if anything, this is getting worse.

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.

I'm still laughing.

The rendering layer and APIs differ significantly between iOS and Android. Agents currently do not know how to test the UI, at least in my experience. I would be scared to do that migration right now.

Technology historians will pin 2026 as the year frameworks died.

There's Kotlin Multiplatform too, you can either have the UI for IOS also done in Kotlin, or just have the logic shared in Kotlin and make the IOS UI in Swift.

It is the "why use python" for mobile.

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

When companies can afford to build a native app but instead use a WOSE (write once suck everywhere) toolkit, it’s because they don’t care about the user experience.

With latest AI models, we will most likely see shift back to just fully Native apps even for smaller teams. This is type of stuff that AI models do really well, if you get a particular feature or even a bigger app change done in one platform, you can just tell Opus or Fable to replicate to the other platforms and in almost all cases it will just do it as well as most human teams would have done it.

In my limited experience, in h2 this year, LLMs were kind of shit at building Mobile apps. I had to switch TO react native because the flutter app it built me was a horrible buggy mess and I couldn't debug it myself because I don't speak dart. At least with react native I can kind of get in the weeds if needed

when you are large enough to allocate sufficient resource, you should go native, if not, go flutter/react native etc. Its very simple decisions I guess.

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

The underlying problem is that it's difficult to make a principled decision. So, it's ripe for SEO mining and such fuzzy takes happen.

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.

In the history books, this'll be the post indicating the end of writing code as a professional occupation.

The shared specs and tests seem like a big part of making this work. I'd be interested in a follow-up after a few months of shipping new features on both platforms. Does keeping behaviour consistent still take much coordination, or have the agents reduced that work too?

A companies with thousands of engineers should simply go native.

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 had one feature in RN and the rest properly native. The day I realized agents were good, I ported that RN to native. Monkey-off-back moment.

I have not coded any mobile apps, I understand the downsides of using react native/electron due to them being web apps but what about things like Kotlin multi platform or flutter? Aren't this frameworks supposed to allow your to have 1 codebase and the apps be truly native instead of web apps?

How long until LLMs just write machine code?

wow, what about electron.js the bloated cross-desktop GUI, can LLM either totally modernize wxWidgets(to avoid Qt's license mess), or create some light-weight cross platform GUI widgets to make GUI easy on windows/macos/linux that is not resource heavy?

This is obvious in hindsight. I expect most companies that move fast and care about performance to abandon React Native. Code is cheap now, and the tradeoff of having a single codebase and only hiring React devs basically isn't there anymore.

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

Missing out on flawless App Intents integration could be business risk for Shopify once people get used to doing everything from a central chat interface, including shopping. I guess it's the real reason for the switch.

What I want to know is if the agents are so good that they can convert React Native code to native with amazing efficiencies along the way, what's stopping them from improving React Native itself?

I suspected we would start seeing these types of blog posts. Code is becoming low level, where people do not care what language, it is written in anymore. The cost of moving from one to another is becoming low.

I've been out of FE dev from awhile, is React still leading? I feel like Vue might be taking over?

Hey what about Flutter

this motivates me to rewrite my Flutter app in Swift. I gave up on deploying the app to Android because of their 20 testers requirement at that time (not sure if its still true).

As the builder of a post-AI, cross-platform native app building framework like React Native, I 100% believe this to be a backwards move.

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

The wheel of fashion turns once more.

Finally some common sense. Time to put electron to rest.

What I find interesting is how AI has changed the cost of maintaining two native apps enough that a decision that made no sense a few years ago is worth revisiting now

This is what happens when you have too much cash on hand. You start wasting it and doing dumb things. Like rewriting entire apps in two different languages.

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

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

if native became easier to tackle with coding agents, react native would have been even more easier to scale. this decision doesn't sit well with me.

Why not flutter?

Would be nice if Spotify and Notion did the same.

Lol, they bought Tailwind CSS, freaked out, and decided not to touch it at all.

Most large tech companies are just job programmes, i've seen so much effort, time, cost go into things that are truly unimportant.

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

This article makes more sense if you remove the self congratulatory verbiage from it, and the cost rationale which I believe is zero.

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.

Isn't it silly that this even needs to be a conversation? Shouldn't we be able to write in any language we want and have the bindings for it to work cross platform? And shouldn't AI aid in building those cross-platform tools?

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

Shopify always comes up but I do t know much about it. Do I interact with Shopify sites without knowing they are Shopify?

Does that mean no more react native skia sponsoring?

The move to native makes sense.

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

I develop iOS and Android apps and all the apps I have in App/Play Store are native. I did try React Native a few years ago but I just didn’t like how much extra bloat I had to include as third party dependencies.

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

They are admitting React was a shtty choice for a mobile app if they have a choice.

The article failed to provide reasons on they why move back to native.

I mean it sounds nice but they never say _why_. "AI removes a lot of the burden" is not a _why_. I was hoping to read about some of the shortcomings of React Native, but it seems like they're doing it just because they can. I remember Airbnb had a post about switching off of React Native years ago that actually had some solid reasoning behind it.

If you build with electron in the age of LLMs, you should change career

Makes sense in the LLM age.

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.

This is probably one of the things that excites me most about AI.

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

Thanks to coding agents, there is no reason not to

Its interesting that the move is back to native and not towards a technology better suited to delivering the same experience on multiple devices from one codebase.

Native. Metal. Remove the abatraction layers

Web based mobile made sense pre AI. It is just simpler now to use different languages and have AI implement features across the board.

im not a fan of react native per se , but this reasoning does not add up.

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.

May be a good decision.

While Meta's Whatsapp just dropped native Windows client for Electron

Lack of vision?

i think many ppl don't understand this news

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

I'm certain that small startup Shopify could not afford to build native applications before AI became a thing. Thank god Sam Altman stole all the information in the world so that small family companies like this can finally have software too.

Can’t wait for the blog post mentioning move back to react native or other cross platform framework.

Let’s see their app size (and heap)

I guess expect no new features on mobile until their token budget gets through all the screens?

I don’t understand why building an app twice is a big deal in the first place if that’s a core part of your business

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

Who could have guessed it!

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

oh fuck my life, we're back to this circa 2000 default of having incompatible binary UIs frameworks across various different platforms, with different OEMs shitting the bed at various different times and Apple free to arbitrarily force its hardware and OS into CI. I felt we were so close to unification in 2011.

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

… from React “Native”

Cool story but what's the token spend?

"native" shouldn't be capitalized in the title

The article itself comes from AI ? It says twice why they switched from Native to React Native in two distinct paragraphs at the beginning. The rest sounds also AI slop jargon.

Why on earth is Shopify not just a web wrapped in an app like most apps? I mean, they implement most of that stuff for the desktop anyway.

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

So... local maxima?

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.

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

Agreed, the whole of the Javascript / TypeScript ecosystem has caused a slop hellscape of workarounds, half-backed fixes and have exposed short-comings in the ecosystem.

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.

I wish more companies would just focus on webapps. It's infuriating how many services try to push an app on you when it's completely unnecessary. The other day I went to a restaurant that had an app. Not a fast food chain, a nice full-service place. No, I'm not going to download an app to order dinner.

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

Too late. My kids called the app Stop-ify because it was so unreliable. Switched to Apple music and won't go back. On Android!

this AI stuff is goin crazy

Out of curiosity why not look at Flutter? I know you don't get native look-and-feel, but most apps are branded who cares?

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.

expected

That also means that ruby becomes less important in their (rails) stack since they move to Swift and Kotlin specifically. Quite interesting considering problem-man DHH ("why are people upset at me shooting at wolves and comparing this it to Roma and Sinti" - and even aside from the connection on his blog to humans, I don't think everyone agrees at gunning down wolves in the first place) is part of the Shopify bromance team.

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

"Native is now the future of mobile at Shopify" is a rather unfortunate title for a writeup of why you're leaving a product with "Native" in the name.

Reminder that Shopify's CEO and COO are both literally Nazis and they host websites for literal Nazis.

Good one

It's not surprising. Code is cheap nowadays because of AI. I reckon more companies will follow suit.

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