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.
When Chrome 1.0 came out in 2008, it only ran on Windows, and it couldn't do basic things like print or export to PDF, didn't have any accessibility, didn't work in RTL languages, and didn't have any graphics acceleration, among other limitations. Don't get me wrong, it was a marvelous piece of engineering - but it was extremely incomplete. By the time it was what we think of as a modern, complete browser, they had many hundreds of engineers working on it.
Also, you're comparing the number of engineers working on one product, to the number of engineers working at Shopify across their entire company today, which includes far more than just one app.
You're entitled to your opinion that Shopify is a poor app or that it's overengineered, but clearly it's not simple. That's just a fact. If it looks like a simple app to you, that's because you're not seeing most of it.
It's like looking at the YouTube mobile app as someone who watches videos and saying that the app frontend looks simple. You're only seeing 5% of the app. The other 95% is for video creators and advertisers, and it is decidedly NOT simple. I think that's the same here.
I agree with what you're saying that it's not exactly what we're seeing which makes it not as simple.
However, I've seen this play out in many a big companies where there's a big mess going on. Answer is always similar pointing to -> "clearly it's not simple" and that's kind of the whole point. They made it not simple. 3k ENGINEERS, my sweet dude. THREE THOUSAND. By any and all account that's half as much as current chrome team or in total if you account for open source contributors as well. If robot is to believed that's also a headcount of windows and macos core teams. What is even going on, I don't even..
Taxes, compliance, regulatory bodies, logistics multiplied by X countries X products has an amazing way to bog you down. If you have money and problems money solves (eg you could hire more people to do something) you do not have a problem (except for people on the internet making arguments from personal inexperience)
I think there is something like Parkinson's Law: "Work expands so as to fill the time available for its completion."
This is more like the engineering team scales to match your budget.
It is why successful companies, when starting out and getting to their defining project completion state have significantly less engineers then 10 years later when they are massively more successful.
The cost of having the engineers is nothing compared to the profits, so why not hire more so you can defend your position. Are 80% of them needed to keep the system going, I think Elon showed that you can prune most of them away and the system will keep humming along (ignoring some initial problems). The trouble is bureaucracy, lack of technical knowledge at the top, and the hazy difficulty of identifying what is needed is really difficult, and if you mess it up, you could ruin a billion dollar business to save a hundred million dollars in salaries.
That is the crux of it. You can't know who to cut, and even if you are really good at it, you will still create problems and create ill will. Elon was pretty successful, but it did have some momentary problems. If his negative cult of personality didn't get in the way, it would have been better off.
I certainly wouldn’t go anywhere near Twitter these days, but the question is how much of that is to do with engineering failures and how much is to do with the overall change of culture and moderation practices that Musk has introduced.
I get that, I truly do since I see it all and every day. We're talking engineering hands here though. Presumably programmers and infrastructure and SRE.
> If you have money and problems money solves (eg you could hire more people to do something) you do not have a problem
If you have money there's a greater chance that someone in that X by X matrix might see you as a juicy target to go after so your expensive handling of every item in that matrix needed to be better still.
Very much this. If you have 3000 engineers (and all the associated non-engineering roles that inevitably come with that) then you have guaranteed that no problem will ever be easy to solve. Possibly you might be able to solve some extremely difficult problems that you couldn’t solve with fewer engineers.
> When Chrome 1.0 came out in 2008, it only ran on Windows, and it couldn't do basic things like print or export to PDF, didn't have any accessibility, didn't work in RTL languages, and didn't have any graphics acceleration, among other limitations.
It also was reusing the WebKit browser engine, work on which started in the 20th century (as KHTML)
As to Shopify needing zillion of engineers: does their backend query seller APIs? If so, I expect many of their engineers work on keeping that working.
And Chrome doesn't even need to support millions (billions) of users on a single, coherent "system". There's no scaling, it's just people running it on their computers and phones.
I suspect the vast majority of Shopify engineers never touch the core Shopify experience, but work on the long tail of invisible things that are nevertheless considered important. I'm talking along the lines of "direct integration with bank X for UPI in India to save 0.3% on payment costs in scenario Y."
Most of the modern software tooling you have today wasn't available back then, from great IDE's to popular libraries, writing software in 2008 was a different beast compared to today.
Tja, besides LLMs I can't really see the major improvement todays IDEs and language combination brings over Eclipse+Java. Great docs, good autocomplete, good compiler feedback.
When Visual Studio (not VSCode) incorporated a time travel debugger, that felt like a major advance in an IDE. I don’t remember exactly when that was, but I think it was around 2013.
I am still a little stunned by the rapid adoption of VSCode over IntelliJ and the original Visual Studio. Maybe being free was the important part, but I still chafe at the idea that we should configure our tools using JSON instead of just, you know, buttons and checkboxes.
Of course, VSCode and its ilk are jam packed with AI stuff I don’t not want, so it is mostly back to a fancy text editor for me.
DevOps and infrastructure, Security. Internal tools is correct, but speed, video quality as well as sound seems so easy. Google is responsible for many compression algorithms and standards - byproducts so to say. And they are top notch.
I have insights into the matters, and a lot goes into behind the scene optimization. Some specialists in the pre-AI phase were tasked to do nothing else but optimize build tools but in the sense of tweaking every millisecond out of it. This guy saved Google Billions over the years.
Others work in compiler building etc.
There are a couple of hints in the books by Google engineers but I am regularily blown away during meetings what really highly inspiring things are there to discover as well as presented.
Another factor: Google is spread around the globe. Regulation, law. Believe me, having over a billion users per app is mindblowing.
And it is 24/7/365. And support. And research.
Google is a company I admire. Technical provess at its finest.
Rubbish. Most of the stuff you’re listing is handled by OS and frameworks themselves, you don’t need hundreds of SE to handle RTL or a11y. I work in one of those companies, most people just regurgitate existing shit into another form of shit and collect salary (not complaining, as I’m one of them, but let’s be honest).
The original Edge had to switch over to Chromium because it was hard to build a compliant accessible browser from scratch and this is Microsoft we are talking about.
More seriously, it not just about building a compliant web browser engine, it is about tracking the dominant browser engine which introduces their own "standards" along the way too.
Microsoft could have easily continued to invest in maintaining their browser engine, but it would have to be comparable to what Google is doing, and yet they'd always be perceived as "behind" due to non-dominant position they have.
I'd say strategically they do not want to invest in tech that's not winning (in marketshare), so when they are not dominant, they'll instead adopt and extend (not just web browsers, look at WSL too).
We live in a time now where libraries are free and plentiful and pretty good. It is easy to forget that this was not the case for the vast majority of time that computers have existed.
Chrome’s original design definitely predates our current rich ecosystem. Plus, V8 and Chrome’s performance profile are demanding enough that there would be a pretty high bar for those dependencies anyway.
Chrome was invented in 2008. Abseil[1] didn't exist publicly until 2017, derived partly from Chromium.
HarfBuzz wasn't ported to C++ until 2010. I don't know the entire constellation of libs Chrome would use if it was designed in C++ today, but I bet a lot of them didn't exist before Chrome or were even created partly as a downstream byproduct of Chromium.
In other ecosystems: if Chrome were designed in Rust in 2008, there would be no crates.io to pull from. There would be no NPM, since Node followed V8/Chrome's invention in 2009. Maven Central had ~50K packages in 2009[2], which was a lot back then. In 2026, Maven Central hosts over 3 million.
I think you've come from an npm world because c++ still doesn't have a great library ecosystem if thats what you mean.
> In other ecosystems: if Chrome were designed in Rust in 2008, there would be no crates.io to pull from. There would be no NPM, since Node followed V8/Chrome's invention in 2009. Maven Central had ~50K packages in 2009[2], which was a lot back then. In 2026, Maven Central hosts over 3 million.
Yeah, this is all web development stuff.... Doesn't apply to c++
A browser isn't drawing its content using OS frameworks, so A11Y is a major undertaking. Much more so because A11Y for web content specifically is a bit of a different beast than native widgets, and the amount of stuff you have on the web these days means that you have to pay a lot more attention to performance.
This is plain wrong. For a browser, a11y doesn't just get handled by the OS automatically. In general, claiming a11y is easy or will be done by someone else is bordering on evil.
Spotify has progressively gotten much worse over the last 15 years, all while the size of their engineering team has ballooned.
I am very unsurprised by this outcome.
People wonder why good software becomes bad, and it’s because the people who were good at engineering are often outmaneuvered by corporate-politics savvy people in a growing company. One of the best political moves in a company is to have a lot of people under you.
A couple years ago, an engineer I know who has always been a very poor performer and lacks initiative, but is friendly and non-confrontational, was hired by GitHub. It would not have been hard for GitHub to find a much better engineer, but this person would be an easy person to keep under a manager on a team who wouldn’t leave or make waves. That can be more important to some managers than skills.
> One of the best political moves in a company is to have a lot of people under you.
This is why I’m sceptical of “AI will kill corporate jobs”. A big company has no profit sharing for successful departments. Everyone is trying to get budget to hire because it makes them feel important.
Sometimes I wonder what the tech ecosystem would look like without the ZIRP era.
I look back over 15 years and with the exception of increased smart phone usage, everything else still looks mostly familiar. Maybe a bit more slick, but also slower and buggier despite having much better hardware.
There hasn't been a qualitative leap in software (as was in the 90s). Just larger SaaS companies. Without ZIRP would it have been any different?
Things have become measurably worse as open standards have been dropped.
An example is messaging apps. Today, if I want to remain in touch with my friends and family I have to juggle between Facebook messenger (thank the heavens for this app which means I rarely need to open Facebook itself), Whatsapp, Signal, etc.
In the early 2000s, even though I was on more services, Yahoo, MSN, ICQ, AIM, a single app such as trillian or Adium was enough to communicate on all of them.
While today we have to go to a whole slew of walled gardens to read posts from folks, such as substack, medium, twitter, etc. earlier, the heavy use of RSS meant that a single RSS news client covered everything.
From a socio-political standpoint, “canceling” also wasn’t a thing, since you could trivially self host a blog and discovery would be no different.
Even better, discovery was through human recommendations rather than algorithms designed to keep you hooked on the platform.
> Even better, discovery was through human recommendations rather than algorithms designed to keep you hooked on the platform.
Yeah, that's one thing that is definitely noticeable. Online social services basically became data-driven psychology research companies, with the goal being to improve engagement. Every page refresh became an A/B test designed to keep you hooked.
That and venture investment has become bane of good.
When a company can run for years, hell, decade+ on the red thanks to investments, that means every competitor now have to compete with company that sells their goods or services below production value. It just kills competition and innovation, which only becomes possible if other company also attracts investors
I don't need an audit log for my audio. What I do need however is to remove something so it doesn't influence the algorithm. I may not remember every time I play music for a kid to turn on the right mode.
I have the impression that for hiring this is fundamentally the most important aspect: Finding a prospect that is just skilled enough for the position without being a risk to the person who is hiring them.
When it comes to number of engineers, always keep in mind that it costs more engineers to maintain (and understand) software than the initial development push.
I’d add on to that lifecycle demands: a development project with no users has a tight cheap feedback loop with high quality bug reports with relatively obvious bug sources, once issues start working through layers of QA and customers the per-issue costs raise by several factors (50x to 200x are numbers I’ve seen from research, YMMV).
I would feel very confident slapping something onto Chrome ‘back then’ with only internal users. Today, with millions of users and CEO-level attention to screwups, I’d use a lot more time per issue. It’s a fundamentally different risk/reward/confidence situation.
I don’t think that AI would have made this confusion (it’s much less likely to overlook things like these), and I’m also not of the opinion that these comments confuse the two companies, it’s rather than Spotify is used by the grandparent as another example like Shopify.
Actually, the first occurrence might have just been a typo (auto-correct?), but the second occurrence looks like slop directed at the previous comment.
Aight, I recognize I only skimmed through the comments, I was completely convinced it was a typo because it has to be a big coincidence that in a post about Shopify suddenly they talk about Spotify and it's not by mistake.
To start -- how many of those 3,000 engineers do you think work on the mobile app? And even among those who work on the app -- do you think they're all working on user quality-of-life and just can't get it right? And it's a $175BB company -- do you think it's worth that much based on the quality of its mobile app?
What are we talking about here - Spotify or Shopify ?
If Shopify - and you are concerned about their engineering teams, please consider that Shopify's revenue grew from roughly $205 million in 2015 to $11.56 billion in 2025, reflecting an explosive compound annual growth rate (CAGR) of over 45% across the past decade. Market validates !
I have nothing to add about Spotify - I use it to listen to music and it works well for me !
Shopify works well for me but it used to push nonsense like podcasts or audio books that I had no interest in, with no way for me to hide them. I just want to listen to music.
Upon looking just now, seems like they have been relegated to their own tabs now, which is great.
When I did some consulting for an e-commerce company that used Shopify, I had a Colombian coworker who kept confusing Shopify and Spotify which was contagious across our company but we always knew what we were referencing because we dont use Spotify to start an e-commerce page.
Similarly, we've had confusion with AWS Amplify and Amplitude (metrics service).
Or I just made a typo. I dont think anyone actually has the understanding that Shopify is a music streaming service and Spotify is a shopping plug-in. I was addressing the latter half of gp's comment which was saying that Spotify has had no problems and I wrote (or perhaps got autocorrected, as I had to correct my phone several times writing this comment).
People who has not run software at scale have no idea what it takes to run it at scale. Google chrome is 60 engineers at launch but google same company has more than 100k engineers. Building first version was always easy and only gotten easy, scaling software was always hard and it is still hard.
I am quite curious about what people hat so much about Spotify. I made some excursions the last few years to competitors like Tidal and Apple Music but I just found myself coming back because the Spotify mobile app experience (and desktop) was just plain better.
The website, desktop app, and mobile apps all have different feature sets, for one. There are things that you can only do in one of them, but it is a different one of them for each thing. There is no one feature set. It feels so cobbled together, with each platform doing their own thing.
Also, the website is slow and buggy, and the Electron “desktop” app is even worse. Both gobble up way too many resources and soft-crash constantly. The app does not lock up, but simply stops working. Often it even shows an error like “Spotify cannot play this song right now.”.
Also, probably due to some DRM bullshit, resuming a song from the middle doesn't work most of the time. I have to seek to the beginning for it to start playing.
Like that's literally the only thing it should be able to do 100%..
Spotify works mostly fine for me but there's weird rough edges that I don't always see in "simpler" apps.
Stuff like transitioning between desktop and mobile - it tries to work and most of the time it does, but sometimes I need to manually make my desktop play on my desktop. Not a big deal but sometimes I'd be happier if this feature didn't exist at all.
On my desktop, Spotify can be finicky when I connect/disconnect my bluetooth headphones. Sometimes it refuses to play after I connect my headphones, and I need to restart the app. I think it's trying to do something magically for me after it detects the headphones and gets into a wedged state, but a simpler "play to active speaker, whatever it is" audio app wouldn't have this problem.
It’s not that much about scalling software, as scalling software on highly concentered nodes. Distribution downstream can be its own hell, admittedly, but otherwise having fully independent copy of software copies that run in local terminal is a no-brainer if all that matter is running software at scale.
You're comparing a company (Shopify) to an application (Google Chrome). A better comparison would be the number of engineers at Google (90,000 [1]) vs Shopify, or the number of developers actually working on the mobile application instead of any other area (website, backend database, internal systems and processes, infrastructure management and maintenance, etc.).
> 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!
Just so it is said: my understanding is it's really easy to not end up on the credits list for games despite having worked on it. I don't know if contractors end up on there for example, at least beyond some team leads or the like. I don't know R*'s policies though, I've heard stories of people not being in credits because they, for example, changed jobs near the end of the development.
They have updated their policies a bit. You may not be in the game credits but you'll show up here.
FWIW the social club team which handled a lot of the online components was small around the time GTA5 released. They built the APIs to handle user generated content, telemetry, accounts, etc. But, there were other team members that made it so the game would call said APIs.
I remember hearing in an old podcast (Dad & Sons), one of the guys there worked at Rockstar in QA in 2012 and he's still listed in the credits for Red Dead Redemption 2 (2018), so the policies are unclear to say the least.
Video games are much easier than what Shopify do which will be a long tail of business cases and local permutations for all the countries they operate in.
Commercial software is usually a simple core and a long tail of business exceptions
Like comparing a climb and along run. Sure both require some physical abilities, but in the first case any error and the collapse mean dead end bringing progress to zero, while the second one you can rest on the side any time and still have the miles behind you accomplished.
It's complex vs complicated. A compiler may be very difficult to build but it is largely complicated.
Human issues are often complex and may not even have a real solution. Consider human issues like Brexit and the Good Friday Agreement - at face value they are a contradiction and yet a solution must be found.
Coding is absolute - trying to build software that can handle all these edge cases, let alone adapt to environmental changes like the law changing around you, when the decision makers have no insight (or interest) in the details is what makes software difficult.
In the corporate software world, especially anything to do with the web both front and back, most people really don’t know what they are doing. The goal is hiring/firing and agile.
Compare that to companies that release actual software products. The goal is product release at high enough quality. There are real performance and security targets to achieve.
Your typical corporate developer, on the other hand, does not have release targets. The actual goal is compatibility with the industry least common denominator expectations and retaining employment. This is why so many people are needed to do the work and why the result is so slow and bloated.
What's an "actual software product" and why don't you think web products count as them?
I'm a full stack web developer. I've worked for startups and F500 companies. There is always a push for release targets. The less technical the leadership, the stricter the release targets (its hard to sell a critical refactoring to management when they cant sell a shiny new feature or kpi to their own boss). We've kept our teams pretty lean too.
We still aim for high quality, and performance and security.
I do agree that many people dont really know what theyre doing and are kinda just winging it, especially with AI at the helm, and many companies are likely overstaffed, but I dont think theres a correlation between headcount and slow/bloated software. Any team of any size can make slow and bloated software.
I worked at Expedia for a bit. Ask yourself if they are a tech company, software company, or travel company. It’s not a trick question. They have a shit ton of software developers that work there. Same with Bank of America where I also worked. In fact BoA has more software developers as employees than almost any other company.
Compare those to a company whose only product is software or is primarily a software service.
The difference is directness to the goal. If you are a big bank you need software and web services just like everyone else, but if you get it wrong it’s not going to bankrupt you. You can always hire an outside consultancy to fix it knowing your employees suck at what they do. If all your business does is sell a retail software product and it turns out to be slow broken shit then you have nothing. That’s the difference and layoffs aren’t a bandaid.
At places like Expedia and BoA you can absolutely suck at what you do. Sucking is actually the expectation because 20% of the people solve 80% of the problems, nobody provides substantive training, and everyone is easily replaceable. If you are the guy building innovative solutions on an original software product for a company that only sells software as a retail product you are still ultimately replaceable, but not immediately so.
One key identifier if the business intends to hire sucky people for a sucky job is degree of abstraction. Is the given job about solving a real problem directly, for example using JavaScript to create a new transmission system that achieves higher availability and lowers costs. Or, is it a tech stack nightmare pretending to not write JavaScript to do the same boring shit everyone is doing in a half ass way?
I dont see the correlation between company type (tech/software/X company) and sucking at your job though. Ive never worked for a, as you define it, "software" company because the software ive built has always been in service of selling other things, but people who sucked at their jobs got let go quickly.
And there are absolutely software companies that hire sucky people. I don't know for certain if the people who work there are sucky, but the software they build and sell certainly are.
Maybe for big corporation non-tech companies the calculus is different? But both Shopify and Spotify certainly cant exist without their software.
> I dont see the correlation between company type (tech/software/X company) and sucking at your job though.
The difference is in culture and expectations. People can suck when they are allowed or expected to suck. They can’t suck when the employer sets high expectations. If a company wants to ease hiring and employment flexibility they have to set the bar low to increase the prospective candidate pool. Otherwise they have to be extremely selective and/or train people.
Perhaps the distinction is outside your imagination because it’s outside your experience.
> People can suck when they are allowed or expected to suck.
This is not a unique concept to software or any company type though. You don't have to look far on the antiwork subreddit to find people who work in all types of different industries, technical and not, big and small, where some people just suck and everyone knows it and no one does anything about it.
That is true, but it’s also why most industries require licensing and/or certifications. These things are not 100% effective, but are still excellent at removing disqualified candidates.
If you are selling the code as the product, it could be said to be an “actual” software product, rather than a mechanism for selling other products, or software as a substrate for some other business.
Those other businesses aren’t any less valid, of course. They just aren’t software businesses. They are businesses that (quite sensibly) use software.
Is Facebook, a company that build software to sell ads, a software company or an ad company? I think its a bit bikesheddy, if not pointless, to try to confine companies to labels like this.
A lot of shopify's engineering probably work on the back-end business logic for payment processing, sales tax, etc. Shopify has to comply with financial norms, rule and laws in so many different jurisdictions.
I know someone who works for Gusto (HR and payroll SaaS for small businesses)... most of their code-base is also business logic and whatnot for all the jurisdictions they support.
The site is currently running, yes. Don't forget it went down quite often immediately following the mass firing though. They seem to have fixed that.
There was certainly a ton of bloat to trim, but the haphazard "just pick 80% of the people and fire them" was incredibly stupid. Should have chosen whoever was producing the bloat, at least.
Pretty well if you don't mind some features being built twice or three times and appearing inconsistently at different screens, or users being able to bypass usage limits by pressing the back button on the usage limit sign...
And now we learn they use Swift and Kotlin to replace React with. So they are not replacing it with Ruby. I think they've hit the limits on Ruby (like twitter had on Scala).
P.s.: I find Kotlin "an acceptable typed-Ruby" with an industrial strength VM (the JVM) and two compiles to native stories (KMP and GraalVM-native).
They'll be mostly involved with the parts that make money. I worked in a similar situation as one of about 5 people keeping the core infrastructure of the product working, meanwhile about 500 people optimized the ads
How many of those 3000 engineers are working on the core engine?
That is vs infrastructure, customer support, partner outreach etc? Then you have all the people working on localisation, not just changing the words, but local regulatory issues.
Chrome only has one customer to deal with, Google itself. And since Shopify is saas and hosted for thousands of customers, vs Chrome running on the users pc, the infrastructure complexity does not compare
>what “engineering” Spotify is doing, it’s the worst app I’ve used in my life.
Engineering is app usability. Theres no other possible thing an engineer might do. Chrome ofc has infrastructure to distribute a binary. Spotify of course having a global content delivery network for terabytes of music. Hey GANG CAN WE WOKK OUT WHAT THESE ENGINEERS MIGHT BE DOING?????? WHY HASNT JIM STORAGE ENGINEER IMPLEMENTED A UI REFRESH YET!!!!
Shopify supports multiple countries both as a buyer/seller. I assume there is all kind of customizations needed to comply with each country weird rules. Are all of these software engineers doing core engineering? Probably not. But they are probably tagged as software engineers within the organization.
> 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!
This is so... wow. You think only 150 devs made GTA 5? Despite the fact that rockstar has 10 studios and you think only 150 people in 5 years touch the code of the game? You should learn how those credits work. It doesn't mean what you think it does.
Furthermore, game dev also includes so many artists and other work. It is so insane to claim gta 5 was made by 150 people that I don't think the rest of your comment can be taken seriously.
And how many engineers does Google have? The people working on Chrome are a tiny, numerically insignificant fraction of Google’s employees. A much better comparison would be people working on Google ads and their other commercial products.
Ironically enough, you using "GPT Astra" to query for such simple information is probably in no small way correlated to the state of software engineering (in these large corporations and otherwise) today.
I love Tidal. That said its UI is remarkably heavy for what it is. You also used to see what quality the songs were in without playing them, but they removed that. They added bpm and key, but that is not as useful to most of us as seeing the quality of the song beforehand.
And you also have to make sure you're getting the most out of it manually. Here are three steps for those who have Tidal and wan't to make sure that they're getting the most (ish) for their money:
1. Hardware Source: If you're using the soundcard in your computer, make sure to bump up the sample rate: on macOS you go to "Audio MIDI Setup" and change the sample rate to highest possible for your output.
2. Software Source: In Tidal itself you have to go to "Settings" and under "Audio quality" choose "Max". Under "Playback" turn off "Normalize volume". If you're having a dinner party and playing the music through a bluetooth speaker, you might want to leave it on. But otherwise off; the normalization causes distortion.
3. Output Device: You have two options here and you can go with both or invest more in the other one:
* Option 1: Invest in some decent studio monitors. They don't have to be expensive or be able to play super loud, they just have to not lie to you. I would 100% recommend buying higher quality low power monitors for small spaces and/or spaces that lack acoustic treatment.
* Option 2: Buy some actually ok headphones. Bluetooth headphones are not good. I got Sony WH-1000XM6 which I mostly use outside. Inside I can plug them with an audio cable and turn them on and then they double their sample rate from 22kHz to 44kHz. But I also got Sennheizer HD600 which cost about the same and I plug them into a cheap headphone amp, and these headphones are really a world appart.
Note: You have to actually find the high quality songs on Tidal to enjoy all those changes. Aim for the 24-bit 192kHz or at least 24-bit 96kHz (personally, the DAC on my Mac only offers 96kHz anyway).
Remasters are often a good source, but sometimes they're from the loudness era and are horrible comparing to the originals.
Lazily researched comment. Pretty much anyone who isn't in sales can have "engineer" in their title. I'm sure there were plenty of "support engineers" in the Shopify number you cited, and I'm sure there were zero in the GTA and Chrome numbers you cited.
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.
We have people on the team that are android users. I just meant that I don't want to evaluate whether it feels "native" as I personally am not an Android user.
You just install it on your phone and use the app.
Maintainability concerns are entirely overblown by people who don't use agentic AI to develop large mobile apps, but anyway give their opinion as if they had that experience.
I put in a few hundred hours, and I reached the same conclusion as Shopify. With reviews from other models and then a manual QA pass the result is fully usable.
I work as a professional app developer. And I find this take to be naive.
Most of the time when I review code from AI, there is always something to improve.
It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.
The maintenance is not only the burden on the human and LLM. With too many moving parts, it becomes harder and harder to build and verify the correctness of future features. Yes you can write test for this and that, but it didn’t need to exist in the first place.
The second problem is correctness issues. Especially the edge cases. You cannot just manually test out a race condition on a phone! Sometimes it happens! Sometimes it doesn’t! If it leads to a visible signal like a crash, then yes, you can try to reproduce it. But there are a lot of these that are “silent” and would just lead to bad experiences.
We already had a software quality crisis! And I think such views only exacerbate the situation! Quality matters!
And this is not an anti-AI stance. I vibe code personal projects where I don’t even look at the code. But when I use AI as a professional engineer, I act like a professional. Because these products do have an impact on people’s lives.
All true (and thanks for posting a concrete example rather than "LLMS suck"). But my take is that none of this is much different than before times when I had teams of developers creating applications. They would often make similar mistakes which I would either need to catch or which would flush out in the field. Where it seems that LLMs are not excellent is where the person driving it is also the senior domain expert so can immediately spot pitfalls. But typically using humans to develop software this was really not often the case. Those people get promoted so they're no longer cutting the code. Under that scenario (replacing subordinate humans) I find the current models are either on-par or somewhat better (specifically because the models can also act like a peer senior dev, discussing approach options etc).
So you don't use agentic AI to develop a large mobile app and you think my take is naive?
I also used to work full time as a Android developer for five years, and I'm pretty sure I know better than you about the quality of my app that I work on everyday.
> It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.
I understand this, but I just can't bring myself to care. I've been doing professional software work for almost two decades. These sorts of improvements/time savers are great without AI. With AI? Whatever. It's fine.
When the underlying lib has an issue, it'll be quicker to debug with the whole thing in context.
You do realize that letting the LLM produce more output means that maintenance will be more expensive? I can easily see a world where claude and gpt are producing more tokens to sell you more tokens.
Just the other day I burned through my 5h quota twice in a row because I had opus spawn a review session on a medium sized PR and I don't know what happened but I told it to summarize to me and it said it spent 100M tokens throughout 50 subagent sessions.
And more recently its been recommending that i install this new browser called Aside. I did, and it almost felt like I was installing malware so I Uninstalled it fairly quickly (it also was not a great browser)
Well yeah, that's the name of the game of most software companies. Anthropic has been fairly good up until the last week or so when it started needing more hand holding to not do things it didn't normally do.
It depends on how hard to maintain the code added is, how likely it needs to change in the future, and most importantly on the cost.
If reviewing and manually improving the code takes hours, the cost may already be in the thousands.
That buys you a lot of AI usage, roughly a few months of continuous work.
You have to balance this with the chance that the suboptimal code the AI generated is actually fine and maintainable enough, and also the chance that during further work on that code a model might implement the same optimization on its own.
Same result here just using plain Opus 4.8+. I had a web ap with a PWA approach. Now I have an iOS app written in Swift/SwiftUI and an Android app in Kotlin in the appstores. I do not know how to code a single line of Swift or Kotlin. You just test the app and iterate with the AI over it until it is stable and does what it should.
Why would you asume that, and how do you define serious? Ever since the iOS appstore presence I get more signups from organic app store searches + installs, which results to some percentage in new daily+monthly active users. Meaning: People use the native app and keep using it. That is how I would define have value, as it provides value to the users - else they wouldn't be using it.
My main agentic coding side project is something that I can't justify paying the apple developer license for. If I was an Android person or I didn't have to pay the developer license, maybe I'd just go for it.
Android got wirse than Apple. It costs 25 dollar now to get ID verified (mandatory) and before you can publish in the Ply store you need 12 betatester that install the app from a special link - those testers must keep the app installed 14days. Only then will you become visible publicly in the play store.
So you end up paying people on Fiverr to do it which costs more than 99€
I have been getting these comments often here, including concerns about my non existent backend's security.
Last time, when I pointed out that the attack surface for mobile apps is typically very small, some users started to talk about zero day vulnerabilities in the OS's media handling, as if it was a concern for my app implementation.
You sound like a person who's never had their app pen tested. The attack surface is anything but small if you're working with any kind of sensitive data.
Are there cybersecurity concerns in the frontend? I would have thought you have to assume the client is untrusted and only do security work on the backend
My favourite is a logout button with a logout API that fails. (Not a huge pratical concern, I admit, because it's a local attack.) Nobody ever notices because it still shows the logout screen, which hides the API error toast (if errors were even displayed). The still valid refresh token stays in sessionStorage (or even localStorage) while the app displays "logged out". (Bonus points if you cleared the access token in the error handler but not the refresh token, and on page reload you ask the user to log in again despite having a valid token.)
Or a login form that gets hidden after login, but clears the username and password only when you click "login back in". (Bonus points if the backend also enforces a 5min session timeout "for security".)
Storing private secrets in your public client is easy to avoid for anyone halfway competent. We are all professionals here.
Turn on the secrets scan in GitLab, and put in your release checklist to have the AI audit the usage of secrets in your app, and this is basically guaranteed not to occur.
I doubt current models even make such a mistake in the first place, and particularly so if you use reviews at all.
WebViews are not an inherent problem, it's the system browser embedded in your app.
Where it gets tricky is if your use case involves authentication in the browser. Together with the authentication in your app this is the one area where you need to focus on security.
The case where a SDK update is needed to prevent weaknesses of the OS seems rather unlikely.
Doing anything right on web is 10x harder and more complex. The problem is the browser, once you use it to deliver anything you have to buy into all of it’s bullshit. CORS, XSS, headers, caching. All that just goes away (outside your backend API, if you even need one) when you ship a native app
This is the most naive take on security ever. For the backend, you assume your client is compromised, but you still don't want to allow your client to be compromised.
If your clients are compromised then what's even the point of backend security. Users will login and do legitimate actions while their compromised client does whatever behind their back, while still looking normal. And the backend can't tell the difference.
You don’t believe how often people leave secrets in the app or use webviews and iframes badly, misconfigure OAuth in client side and so on. There are many issues where secure API does not help.
I am using Gemini as well as Opus on a somewhat small project in React Native and I can not imagine this thing being able to build the whole thing on its own without it being a dumbpster fire.
Can you share some details of how you work? What models? What harness?
I use Codex and Claude Code desktop apps. I generally use only the SOTA, now Astra and Fable 5.1, Opus 5 when Fable runs out.
I don't know if Gemini is suitable.
I had few issues with my native iOS app, the results are just decent after a few iterations, the models do what I ask them to do. Where do you see the problem?
The LOC for my app is now at almost 200k + 110k lines of test code.
We use CC with Fable(Opus before that) continuously on a rather large project, everything is tested, we maintain high verified test coverage, we ship features x10 faster than when we started(pre Claude-everything era 2-3 years ago). I never worked with RN before and I ship features now. LLMs allowed us to find issues within RN itself, that thanks to some patches, improved lower end Android experience by a lot. We just use all the Claude defaults with claude.md that evolved over last year.
> Are there cybersecurity concerns in the frontend? I would have thought you have to assume the client is untrusted and only do security work on the backend.
No, they said they don't use android so don't know the native UX. You can test your app on the platform and confirm that the functionality all works, but how well it adheres to the platform's design language is subjective and hard to say if you aren't used to the platform.
I used the emulator - but just like I can use an iOS app for 30 seconds and tell you whether it feels native or not, I can't do the same for Android, since I'm not a daily user of Android phones.
And in the past, I didn't care because when I was manually building the app, I would just do my best with react native. But now that I can actually sweat the details (with the help of agents), I do want to hear from android users and use as many OS-native APIs and features.
Others on our team use Android phones. So when I said that we spent the next few days actually polishing it, that's where others came in, providing feedback when they used it.
I could only sweat the details on liquid glass, etc because I'm a daily iOS user.
That's a recipe for regressions as the amount of surface you have to cover with "just...use the app" gets bigger and bigger.
You can write more automation to test it. But that's also how you end up with ever-growing test run times.
There are much better ways that aren't just "throw out the LLM" either. You just need to be more focused on throughput. Requiring manual validation can pretty rapidly require more hours than just sanity-checking code by hand, even (and I'm not advocating that for every use case, either.)
I can't afford manual QA passes if I'm gonna go as quickly as I want to.
This is wildly overblown. I've been working with agents for a good while, read tens of thousands of generated Python and the language factor is actually the part they get right that humans don't.
Seriously! What a bonkers thing to claim. "I had codex use maestro so I assume it made Android work well and idiomatically".
It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem, which makes me feel fear in my heart when I imagine the first "production is down" page coming in. I already hated mobile because it's so much harder to maintain than web (and I don't do any spyware or IAP so no benefits for me there); this yolo approach would give me constant dread.
It shows that at least some software development is moving away from code and to product management instead. I'm not passing judgement on that; I actually think that's great for a lot of software. It is interesting to see the shift happening though and will be fun to see if the general quality of software noticeably changes over the next few years.
> It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem,
As much as I dislike it, I think that's the future of _all_ non-critical software (think social media, crms, CI, food delivery etc). Leadership in many companies is explicitly asking employees to have multiple agents running through the day and that will lead to this.
Read this for example: https://www.uber.com/in/en/blog/efficient-software-factory/ . A very useful system, I am sure. But when you have AI at every layer from code to review to triaging, rest assured AI is the only know who knows your system. And you better hope it's not telling you that something is load bearing during an incident.
I read the article and couldn't understand it. I asked Gemini; Pareto things definitely sounds like science.
I read the article again:
- We had bugs. We let agents try to fix the bugs. True positive (fixed bug) is the F1 score. Here are the results for different models. Fixes worked 50% of the time.
- We needed to find a query. Without a knowledge graph it took 20mins, and didn't work. We used a knowledge graph. It was fast (20s), and found the right thing.
I gave my LLM my summary of the article and apparently I "hit the nail on the head".
I answered elsewhere that I don’t personally use Android phones but we have people on our team that do. Which is why I don’t want to personally claim that it feels native.
But yes we are having real Android users test it.
So it’s quite the contrary. I care MORE what real users say. I can only guarantee that the app does things when I tap. So I’m not trusting the agent on UX, only on functionality. But whether it feels native, I am relying on those users in our team.
I wrote every single line of the react native app we ported, and maintained it for 9 years. So suffice to say, I'm familiar with the code.
But I am going to always prioritize the user experience over a developer (like myself)'s need for satisfaction to see code. And a pure native app is _always_ going to behave better than react native.
> And a pure native app is _always_ going to behave better than react native.
Maybe iOS is better about consistency, but I've used enough horribly made Android apps that I would not expect one that's vibe coded to behave better than a professionally made react native version.
You are familiar with the React Native code, you are not familiar with the Swift or Kotlin code, and likely nobody on your team is, since the AI wrote all of it for you.
Presumably a sarcastic post, but this is actually going to be how things are done soon. I had a box that OOMed and needed to be rebooted every few weeks. It was a disaster recovery standby box so figuring out what was going on never rose to the top of my priority list. So I asked Claude to dig into it (proxying the commands it wanted to run through me) and in an hour it had diagnosed the problem, fixed it, and taught me a bunch about memory usage in our system on modern kernels.
Not sarcastic. I have a moderately successful app and I haven’t once looked at the code (though I am capable, so far atleast). The only time I open Xcode is if I have to modify signing certificates. I did set up a slack workflow with a “fix it” button that basically tells Codex to fix the issue, run comprehensive tests, manually UI test for that particular issue with computer use and then deploy it.
It is. For my day job, I’m a software engineering director and I probably won’t have a job in under five years. For low to medium complexity apps, even Codex before Astra was capable of doing it completely by itself from scratch. For testing I would bring up the app after each atomic change and then manually try it out. I also use my own app heavily multiple times a day and I have found dozens of issues but I just ask Codex to fix it on the spot.
React native is an obstacle compared to what clear Swift/Kotlin code may produce. Swift is very powerful and Kotlin, in all honesty, is the first reasonable and very useful thing to come to the JRE ecosystem (save for Scala, which is, well, quite complex still).
Myself turned some python code to Swift, and keep doing so, without trouble or pressure. Of course, I've been doing fair amount of systems programming for 20 years now, so not sure what to advice newcomers. But this approach to dev DOES work for me very well.
Sounds like the advice to newcomers is to not worry about trying to learn a programming language. There already is an llm to program for you, and do it better than you could, so just learn how to talk.
While I mostly agree with you, this is the kind of thing that might not have been done if the AI couldn't do the heavy lifting.
They had previously chosen React Native because it was easier for programmers to keep it updated, since it was really just 1 codebase. With AI, those same programmers can do the more difficult version, keeping the native apps updated separately.
So did it kill a job, or did it make it possible for the existing programmers to do it better?
It's the kind of thing that is really hard to determine in general, but here, it really does sound like they only made the change because it became possible with existing resources. They would not have done it otherwise.
That's an example of AI growing the sector that can lead to more jobs. Because suddenly a lot of tasks that weren't economically viable are now going to be in demand. Custom software for small businesses, platform specific optimized code instead of cross platform software, etc...
In case of my company, the port was planned for this year, with a 9 month timeline and about 10 FTE team. It ended up being done in 3 months, with 2 engineers. (Sure, plus testers and internal bureaucracies, but that 2 FTE for 3 months vs. 10 FTE for 9 forecasted is apples-to-apples). Sure its eating up SWE jobs.
Of course it would. Supply and demand. Some companies would decide not to bother. Others would decide it was worthwhile. The limited pool of supply (app developers) would be distributed across demand.
>> Some companies would decide not to bother. Others would decide it was worthwhile.
The parent's point is that AI lowers the cost/benefit ratio drastically, by reducing the cost. So companies that would have shied away from projects like this pre-AI are now pulling the trigger without much hesitation.
And what a lot of people seem to miss is that with AI, there is going to be (already is?) orders of magnitude more software in this world. I'm sure a lot of jobs will be eliminated, but new jobs will be created as well. Hopefully enough to balance things out, but we'll see.
I agree that AI is suppressing developer wage growth and taking real jobs. The opposite argument is being made elsewhere in the thread, and I think that argument is wrong.
Previous company I worked for would have (and did) hire dedicated swift/java mobile developers to build and maintain ios and android native versions (largely porting functionality from an existing web application)
What's more likely (as others have said) is that the other thousand companies that can't afford to have dedicated staff would've just used React Native. So no jobs were lost, they weren't there in the first place. The places that have dedicated Swift/Java devs can now be more ambitious in what they build.
Really? I’ve worked with plenty of companies that had separate native iOS & Android teams. I don’t know any that use a compatibility layer. Unless by compatibility layer, you mean a web view.
This app has 15/20 screens, an app this small wouldn't employ many people to begin with. Before there was one guy (op) maintaining it in react native and now he maintains it native. I don't see much change tbh.
Just like this has made Web devs into Mobile devs, so could Mobile devs leverage AI to work in Web shops.
I'm not an optimist but there could be an increase of available apps being created which would still keep people employed. Theoretically the cost of creating an iOS app for a company without an engineering team dropped from several hundreds of thousand to a few thousand or hundreds, which could be paid out to a freelancer with AI. More people would go into freelancing for industries which were not contemplated before due to cost.
This is an incredibly boring task. Nothing new, just rewrite everything to just see it all rewritten again in 1 year. Perfect for LLMs and something humans shouldn't do.
While I agree with that statement -- that is also a lot of jobs. We have a lot of humans -- not every single developer sits in the innovation seat. The fewer the jobs available the less employable humans.
I think that rewrite - if AI enabled - owes its thanks to the legion of individuals who put their code up on the internet in the first place.
We all want super exciting jobs. But plenty have boring jobs like this. Between not having a job or having a boring job that pays well, the choice is obvious for many of us.
This is just not true. In the olden times (pre-claude) devs were constantly asking to do full rewrites of legacy code. This kind of project is exactly the kind of work I've trained for and have loved to do for the last 15 years as a mobile dev.
We did the same with our apps used by a few hundred thousand people a day. We are a slow, boring company, so the port took about 4 weeks of engineering work, and maybe 3 months taking into account release process and change management. But in fairness, we had the first working version after a day as well. This was in February, too, with substantially less capable models, unable to do overnight runs.
I thought the same, but then I build a few complicated apps and thought I could keep the different codebases stable but still was a headache, so switched web, ios, android all back to expo/rn. I love that testing is only (almost) only thing now, instead of 3 platforms.
Yes uniffi created swift and kotlin bindings. The app I did with this is just a sudoku game https://www.puzzlesight.com . Before AI I would have reached for something like Flutter to avoid doing all work twice but with AI doing two apps makes more sense.
Okay, makes sense, the whole thing looks and screams vibe coded. On a beefy machine, navigating between your website pages takes 2-3 seconds. So still a long way to go with AI.
Interesting, it's instant on mine. The landing page is just Astro with cloudflare in front of it, the origin server is a hetzner box in Germany though.
So now you have two vibe coded applications you don’t understand. I’m not an advocate of making “job security” decisions but this definitely goes to red flag territory. Was it your job to maintain the RN codebase or do you have other functions there as well? I’m not sure I would keep a native noob on a vibed native codebase. What is your take?
People routinely decompile and recompose existing binaries, and if you use "obfuscation" in your app it's still a small bump.
In today's age, IP is no longer a tangible concept that gives any advantages in software. What differentiates two businesses isn't their IP, it's their relationships and their moat.
Most vendors that had protected proprietary IP are now irrelevant within their vertical. What saves them are the protection provided by patents, which is public.
Definitely agree. Most developers could build a basic Twitter or Facebook clone. The hard part is getting the users, content, and relationships that make the product worth coming back to.
It is both tbh. Anyone can build a poor clone of an application. However there are many things that you don't realise is happening beneath the scene.
It is all the small things e.g.
YouTube Mobile website works really well when you have a inconsistent connection compared to the alternatives such as Odysee, Rumble, Kick and Twitch.
I can listen to a live stream or a video style podcast in the car and YouTube will resume the connection properly as long as the browser tab on my phone hasn't gone to sleep. Kick will just stop, if it is a replay it will resume from the start of the stream after rewinding the stream a few seconds while attempting playback.
While the code to do this isn't that difficult. YouTube has bothered to deal with the edge case of someone like me driving through an area with inconsistent connection while running their mobile site (not even their app).
Whenever people try to use alternatives, they often complain about poor reliability of the app. A lot of the clones are losing users and I doubt they really even know they are doing it.
I've had it work well on both (iOS and Graphene OS) using Brave browser on both. It is simply much better when you are on a unstable connection than any of the other sites.
Isn't ZDR only the case if you "opt out" through a setting? Lots of opportunities to make a mistake here, or for the LLM provider to play games. You could be unaware of the setting. The provider could reset the setting upon subscription lapse/renewal, application update, model release, etc. A developer could accidentally use their personal subscription (w/ setting on) on a work codebase.
Also what's the timing on this setting's effectiveness? What if before you knew to "opt out" you used the agent for a refactor and your entire repo got sucked up in inference? But then you opt out the next day? Is it too late?
That’s the case with a personal subscription directly with OpenAI or Anthropic, but enterprise customers are opt-in, AFAIK.
And there are solutions around it from other providers and model routers. OpenRouter lets you explicitly say on a per-request basis you don’t want to be routed to a provider that trains on your input, for example.
The mistakes you describe are only possible if the company doesn’t really think there’s proprietary IP in the codebase.
If a company really believed there’s valuable IP in code, there would at a minimum, ban laptops or ban code on laptops[0], provide and maintain a centrally managed LLM gateway[1] that handles authentication, billing and model choice, have MDM to prevent you from using your own Claude login, etc.
[0]: For example when I worked at Google, the proprietary google3 codebase cannot exist on laptops because there are no tools to download it to your laptop.
I'd wager many software startups out there would consider their code valuable IP (even if in the AI era it's not), and don't have these types of IT controls in place. Startups I worked at gave you an email account, github access to their private repos, and that was that.
Heck, you don't even need to mix up a personal and business AI subscription. For the vast majority of folks one day their IDE "updated" and a bunch of AI features suddenly became available. Free, no sub needed. A dev starts using them (because, why not?) and lo and behold the company's code got shipped out in an inference call and is now scheduled to be in the next training run. Oops.
You are merely describing companies that aspire to consider their code valuable IP, not companies that actually do so.
IDE updated? It’s the company IT’s job to perform testing before distributing those updates. And also their job to use whatever managed settings to disable those unmanaged AI features.
Yeah man I think we just have experience in two different worlds.
A single digit headcount startup with a "company IT" team testing program updates before distributing them??? Um, no. You just download VS Code (or whatever IDE you want) on the Macbook they give you and it updates when Microsoft pushes a public update.
How's that any different from, say, Windows updating and backing up the company's code to OneDrive?
Actions speak louder than words. If the company doesn't even supply and require work devices, they don't effectively consider their code to be valuable IP.
Next up, designing an even higher level language which will be used by LLMs to compile to high level languages like kotlin or swift. Just store instructions for LLMs in repos.
2021-11-08: https://shopify.engineering/high-performance-hydrogen-powere... ("The future of commerce is dynamic, contextual, and personalized. Hydrogen is a React-based framework for building custom and creative storefronts powered by Shopify’s platform and APIs.")
2025-01-13: https://shopify.engineering/five-years-of-react-native-at-sh... ("React Native has come a long way in the last 5 years and a lot of limitations that led people to not adopt it simply don’t exist anymore. If you haven’t tried using RN in a while, now would be a good time to revisit it.")
2026-09-10: https://shopify.engineering/back-to-native ("React Native was working well for us, and it remains an excellent framework. But since then, coding models have gotten dramatically better, and for our apps and our team, building the same feature in Swift and Kotlin no longer carries the cost it used to.")
Seems a lot like the meme of the new designers pushing a redesign to justify their existence.
To be less dismissive it seems an industry wide problem that big splashy projects get rewarded while the silent “Snow Leopard” mind numbingly obvious just up your quality and fix bugs and UX issues work goes unnoticed.
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.
> The continued React Native tax of unnecessarily difficult upgrades,
My very first experience of RN was having to update an app to handle the mandatory change to 64 bit APKs
Which required a massive update not only to several dependencies but also xcode, iOS frameworks, the weird objective C caches that get smuggled into node_modules, _as well as_ all the rigmarole or making the 64 bit APK build work
> cause your business to really spend a lot of time shepherding the tech over the finish line
some may be better than others, but isnt this basically true
for all these 'multiplatform' systems? i have nightmares of all the time it took with handling platform-boundaries/integration and lots of other grinding...
> The continued React Native tax of unnecessarily difficult upgrades
I thought I read somewhere that this is what prompted the move. I don't use RN, but apparently the new architecture isn't exactly a drop-in replacement.
I experienced the same issues but went the other way and migrated from React Native to React. Still one codebase but none of the issues. Performance was better too even though half the code stayed the same.
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.
Not sure why someone would say it was a wrong decision. Why would they even need to do this if LLMs make coding easier. They are likely chasing the things I advocate for: direct access to latest APIs from each platform, platform specific UI, UI that behaves correctly on each platform without chasing down edge case solutions (also said as ui that looks and feels "right"), and a bonus of separate developer pool to hire from that knows the ins and outs of the platform without needing to hire a developer to know all three- react, iOS, and Android.
> Not sure why someone would say it was a wrong decision.
Writing almost anything with javascript sucks ass to begin with. Writing native code with it is even more painful. Most javascript engines don't even have any decent model of parallelism. It takes zero imagination to see the problem here
The problem with everything being single threaded isn't so much that you want to do a lot of parallel processing, but that you don't want to have the occasional fat loop cause the whole engine to start stuttering. If you want butter smooth scrolling while there's (for example) a lot of dynamic content moving around, you want very precise control of the threading so you can get the gnarly stuff done without causing hitches that don't feel right.
The browser, iOS, and Android all use a main thread separate from the thread responsible for scrolling animations.
However, I think it's true that controlling threading in order to perform gnarly work in a separate thread is more ergonomic on mobile than in JS/React.
You'd need to create a Promise that wraps a Web Worker, which would be an unusual thing to use. I don't think most apps need such control over threading in the browser.
If you care about smooth interactions, the browser even in 2026 is not the most straightforward route, nor the route any reasonable small company takes.
Why would they need to worry about hiring for specific skills at all? As AI progresses, isn't the only skill that matters that you can drive it effectively (which encompasses testing and review) without needing oversight?
Yeah they do say that but as someone who has worked on native apps / RN for most of my career I think that is bullshit. They're not going to come out with a mea culpa owning that, this is as close as it gets.
FWIW, the native app specialists are in some sense the most invalidated here. Shopify decided they couldn't afford your skill set and didn't change their mind until you could be replaced with an LLM.
Really the whole concept of technology specialization is the thing in jeopardy. It no longer appears to work to make a career out of deeply learning something obscure. Agent-farming generalists appear to be the ones who own the future right now (if, heh, not the agents themselves).
My validation is that platform specific codebases is what is the right course of action. The c-level decision is that they want the cheapest route to consumers. My point is that consumers can tell, the product is better, and developers are happier working on native codebases.
I'd challenge you to determine which of the top app store(s) apps are react native vs not -- plenty of app store awards have gone to react native apps -- bad software is bad software. plenty of you ios devs write shit software. I've done this job almost 40 years and no language or platform has ever prevented people from building shitty software or for that matter gotten in the way of writing good software. good engineers can figure it out.
source: ios dev since it was possible -- I am not even pro react native, I am just pro merit based arguments -- you aren't making any
Challenge not accepted but deferred to the article where one of the largest business wants to sit at the intersection of native apis without a a middle layer for the sake of saving money. Put another way, given unlimited resources, native wins out over shared.
Shopify is moving its mobile apps from React Native back to native Swift and Kotlin. With the main cost of native gone, the benefits of staying close to platform APIs and first-party tooling win out. This has been my ethos. That native is better than shared.
Your argument was you've argued your whole career for native. The article argues only very recently the cost equation has changed. Your argument reads like you are not taking into account the broader context or the passage of time.
I'll put it this way, my argument was pro native. And in the context of the article, if a large company had unlimited resources, they would choose native. I'm not discussing the business case for it, but the end result of it being the better option. It can be seen as "Shopify tried Reactive Native and left it behind the second they could after sinking resources into it for 6 years".
Time and progress have overtaken them. At the time they were likely correct but I certainly wouldn’t bother with react native any more when the LLMs have gotten so good
My argument is that platform specific codebases is the right course of action. My point is that consumers can tell, the product is better, and developers are happier working on native codebases.
> developers are happier working on native codebases.
Agents are happier working on any codebase, but ultimately Shopify and other companies want iOS native app level quality without the huge cost of hiring many native iOS / Android devs.
LLMs and Agents deliver on getting a native app out at lower cost, higher quality, faster all at once.
I think everyone is trying to tell you your skills as an iOS native dev have been commoditised and Shopify and others don't need to hire anymore native devs to find this out.
I don't see how your job being completely commoditised and cannibalised by LLMs replacing your job is some how vindication?
This is just like saying "we won the argument", but what did you actually "win"?
Yea, I hear that. I'm content with winning the argument and truthfully, I think they will find they need to hire iOS engineers because we do more than write Swift. There are whole ecosystems of knowledge to go from a product idea, sit in meetings with many stakeholders, and implement the actual thing everyone wants. All they got here was a 1-to-1 implementation of their current app which was born of engineers working through real constraints. It says nothing of new features that have to play nice with other pillars of the company.
Not sure why you are defining my vindication. Its purely rooted in native is the better solution for mobile apps. Which they are using. Not sure how that makes it the opposite.
You're looking at it from iOS side only, and for a US company that would be the last platform they'd ever drop.
It was a different picture out of the Apple garden, when a company only brings their next major feature to iOS because they couldn't be bothered to hire the same headcount on two development teams and their CEO uses an iPhone anyway.
We had that discussion about a decade ago with a company rep that didn't realize 70% of their EU users were on Android yet their play store app didn't have the feature they were planning to promote.
Basically, better was the enemy of good for most companies.
Correct, I advocated for the solution that produced the best outcome for user experience, code and architecture simplicity, and prevented having to rewrite an app in the future in native. Which has been validated here.
The android shortfall is a real one but I also pushed for hiring native android developers too.
As someone who has watched a team battle Xamarin and now Maui, and all the painful upgrades in between, I agree with you. Sure they never had the pain of supporting two separate codebases, but they also never had the luxury of doing anything the easy way.
We'll have to wait and see if the extra maintenance / bugs / attack surface is justified. This an announcement of future direction so vindicated is certainly premature.
If you weren't arguing against the business case, what were you arguing with the C-level types about? I don't think I have ever heard a case for react that wasn't centered around shared codebases mean fewer resources/cost/time to deliver a feature.
I'm inclined to agree on certain points; true native apps are, generally speaking, better when it comes to e.g. customer experience. It comes with risks and costs (but I think the cost vs benefit is exaggerated) - risk being the ability to find good native developers, which aren't as common as e.g. web developers who can switch to RN fairly easily.
But there's a factor few people (that decide on using RN) miss; it adds a layer of indirection, so you're no longer as "in touch" with the underlying platform. While possible, few RN developers would consider adding widgets or smart watch apps to their main app, but (I feel like) if you're a native iOS developer who is all-in on the Apple ecosystem, you're more likely to try and adopt these features (where applicable).
(disclaimer: RN is my current day job, used to do native iOS development and I frequently miss it)
Same here. Glad I stuck with native iOS development. I still haven’t switched to SwiftUI though (except for some small stuff). Still sticking with UIKit here.
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.
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.
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.
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.
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.
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 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.
Hmmm, the article doesn't really say what is better about the Swift/Kotlin apps, compared to React Native. All we get is:
"Native keeps us closer to platform capabilities and first-party tooling, with fewer framework and dependency layers between our code and the platform"
What's the user benefit of that? It's not speed, they say "React Native apps can be fast. Ours are."
I'd expect it to be considerably easier for a few people to use the AI to improve React Native with whatever matters, than for every company in the world to permanently maintain two apps.
And those improvements to React Native, would make all mobile apps easier for everyone to build forever more.
Are LLMs going to stop everyone collaborating, making libraries and platforms, and shared language and abstractions, because we can all vibe code our own thing? This seems a loss to cost and quality, even with lots of tokens available.
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
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
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'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.
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?
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.
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"
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 ]
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?
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):
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
When so many people talk about companies going with React "because AI knows React," it's interesting to see Shopify draw the opposite conclusion: AI "knows" all major platforms and frameworks, so at a certain scale it makes sense to let AI handle cross-platform development as a translation problem.
Modern LLMs evolved from translation models, and they still seem to work best at translation-shaped problems. Even if you are asking them to translate specs to code, or code for system A to code for system B.
In my case, I added SQLite and Postgres adapters to a formerly MongoDB-specific CMS, including support for a largely compatible API, "in one wild weekend..." followed by lots of verification. That was only practical because we already had a large test suite. But it was still a task that would have been out of the question for our team size before Opus 4.6 or so. Again, it was very much a translation-shaped problem.
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.
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.
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.
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
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.
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.
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've been a mobile developer for 15 years and being able to develop two codebases in parallel is by far the best productivity gain LLMs have to offer in this space.
These cross-platform SDKs try too hard to solve a very difficult problem and never last (looking at you Xamarin). My first job was actually working on a Lua framework that was shared between an Android and iOS codebase.
It's far better to tell claude to port your swift+core data implementation to kotlin+room then fix whatever it did then it is to try to debug a complicated view hierarchy that renders incorrectly on a specific Android version because you're framework decided to nest a list in a scroll view.
The answer depends on scale, and appropriateness. If you've got enough engineers, you can do platform native code. The results will look better.
Appropriateness often comes down to is the code doing deep platform API things, with sensors for example, or anything else that's not part of user interface, but has an API that's going to require you to write platform native code.
Shopify clearly meets the first criterion, but are the commerce and security parts enough to drive the second criterion?
Anyway they're big enough to make a slightly less than optimal solution and still get a better result than sticking to a cross platform SDK.
The true test here, which I don’t see much discussion around, isn’t how fast or how well agents can convert the existing apps to native; it’s how fast and how well the team can build entirely new features across platforms with native vs react. The existing app code is an unambiguous spec — perfect for agents to build from. Typical design specs, PRDs, and prompts have a lot more ambiguity. There’s a lot of iteration that needs to happen to get a feature from concept to launch and I’d wager that will not be as fast with the fully native approach.
> Agents can make code changes in seconds, but it takes them several minutes to test the output. This makes iterating extremely slow and manual ... We’re fixing this by designing our app architecture to work for both humans and agents. The core principle here is that business logic should be completely decoupled from the UI and be able to run headlessly on desktop.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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?
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?
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.
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?
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.
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.
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.
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.
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?
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.
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).
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
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
> 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.
“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.
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.
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.
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
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.
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
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.
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?)
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
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?
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.
It's nice storytelling, but hard to take completely seriously. As others have commented, there's a lot that's not being said.
We may also look back on a (now-deleted?) tweet in which this company's CEO meme-trolled another engineering org. for their mobile decision-making. The overall tone here and over the past years comes off as holier-than-thou.
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.
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.
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.
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.
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.
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.
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.
When Chrome 1.0 came out in 2008, it only ran on Windows, and it couldn't do basic things like print or export to PDF, didn't have any accessibility, didn't work in RTL languages, and didn't have any graphics acceleration, among other limitations. Don't get me wrong, it was a marvelous piece of engineering - but it was extremely incomplete. By the time it was what we think of as a modern, complete browser, they had many hundreds of engineers working on it.
Also, you're comparing the number of engineers working on one product, to the number of engineers working at Shopify across their entire company today, which includes far more than just one app.
You're entitled to your opinion that Shopify is a poor app or that it's overengineered, but clearly it's not simple. That's just a fact. If it looks like a simple app to you, that's because you're not seeing most of it.
It's like looking at the YouTube mobile app as someone who watches videos and saying that the app frontend looks simple. You're only seeing 5% of the app. The other 95% is for video creators and advertisers, and it is decidedly NOT simple. I think that's the same here.
I agree with what you're saying that it's not exactly what we're seeing which makes it not as simple.
However, I've seen this play out in many a big companies where there's a big mess going on. Answer is always similar pointing to -> "clearly it's not simple" and that's kind of the whole point. They made it not simple. 3k ENGINEERS, my sweet dude. THREE THOUSAND. By any and all account that's half as much as current chrome team or in total if you account for open source contributors as well. If robot is to believed that's also a headcount of windows and macos core teams. What is even going on, I don't even..
Taxes, compliance, regulatory bodies, logistics multiplied by X countries X products has an amazing way to bog you down. If you have money and problems money solves (eg you could hire more people to do something) you do not have a problem (except for people on the internet making arguments from personal inexperience)
I think there is something like Parkinson's Law: "Work expands so as to fill the time available for its completion."
This is more like the engineering team scales to match your budget.
It is why successful companies, when starting out and getting to their defining project completion state have significantly less engineers then 10 years later when they are massively more successful.
The cost of having the engineers is nothing compared to the profits, so why not hire more so you can defend your position. Are 80% of them needed to keep the system going, I think Elon showed that you can prune most of them away and the system will keep humming along (ignoring some initial problems). The trouble is bureaucracy, lack of technical knowledge at the top, and the hazy difficulty of identifying what is needed is really difficult, and if you mess it up, you could ruin a billion dollar business to save a hundred million dollars in salaries.
That is the crux of it. You can't know who to cut, and even if you are really good at it, you will still create problems and create ill will. Elon was pretty successful, but it did have some momentary problems. If his negative cult of personality didn't get in the way, it would have been better off.
Twitter is an empty shell though. Yes it technically works, that’s about that.
I certainly wouldn’t go anywhere near Twitter these days, but the question is how much of that is to do with engineering failures and how much is to do with the overall change of culture and moderation practices that Musk has introduced.
I get that, I truly do since I see it all and every day. We're talking engineering hands here though. Presumably programmers and infrastructure and SRE.
> If you have money and problems money solves (eg you could hire more people to do something) you do not have a problem
If you have money there's a greater chance that someone in that X by X matrix might see you as a juicy target to go after so your expensive handling of every item in that matrix needed to be better still.
Very much this. If you have 3000 engineers (and all the associated non-engineering roles that inevitably come with that) then you have guaranteed that no problem will ever be easy to solve. Possibly you might be able to solve some extremely difficult problems that you couldn’t solve with fewer engineers.
> When Chrome 1.0 came out in 2008, it only ran on Windows, and it couldn't do basic things like print or export to PDF, didn't have any accessibility, didn't work in RTL languages, and didn't have any graphics acceleration, among other limitations.
It also was reusing the WebKit browser engine, work on which started in the 20th century (as KHTML)
As to Shopify needing zillion of engineers: does their backend query seller APIs? If so, I expect many of their engineers work on keeping that working.
And Chrome doesn't even need to support millions (billions) of users on a single, coherent "system". There's no scaling, it's just people running it on their computers and phones.
I suspect the vast majority of Shopify engineers never touch the core Shopify experience, but work on the long tail of invisible things that are nevertheless considered important. I'm talking along the lines of "direct integration with bank X for UPI in India to save 0.3% on payment costs in scenario Y."
And, importantly, this was 2008.
Most of the modern software tooling you have today wasn't available back then, from great IDE's to popular libraries, writing software in 2008 was a different beast compared to today.
Tja, besides LLMs I can't really see the major improvement todays IDEs and language combination brings over Eclipse+Java. Great docs, good autocomplete, good compiler feedback.
Yes, IntelliJ 8 was out in 2008. From my experience most of the progress since then has been keeping up with language and library updates.
When Visual Studio (not VSCode) incorporated a time travel debugger, that felt like a major advance in an IDE. I don’t remember exactly when that was, but I think it was around 2013.
I am still a little stunned by the rapid adoption of VSCode over IntelliJ and the original Visual Studio. Maybe being free was the important part, but I still chafe at the idea that we should configure our tools using JSON instead of just, you know, buttons and checkboxes.
Of course, VSCode and its ilk are jam packed with AI stuff I don’t not want, so it is mostly back to a fancy text editor for me.
Wasn’t Chrome mostly a wrapper on Webkit, though? You had to add the engineers who worked on Safari and KHTML before to the count..
Sounds like you're describing the shit show that is web development
DevOps and infrastructure, Security. Internal tools is correct, but speed, video quality as well as sound seems so easy. Google is responsible for many compression algorithms and standards - byproducts so to say. And they are top notch.
I have insights into the matters, and a lot goes into behind the scene optimization. Some specialists in the pre-AI phase were tasked to do nothing else but optimize build tools but in the sense of tweaking every millisecond out of it. This guy saved Google Billions over the years.
Others work in compiler building etc.
There are a couple of hints in the books by Google engineers but I am regularily blown away during meetings what really highly inspiring things are there to discover as well as presented.
Another factor: Google is spread around the globe. Regulation, law. Believe me, having over a billion users per app is mindblowing.
And it is 24/7/365. And support. And research.
Google is a company I admire. Technical provess at its finest.
And it was a fork.
5% is insanely generous for the YouTube example.
Rubbish. Most of the stuff you’re listing is handled by OS and frameworks themselves, you don’t need hundreds of SE to handle RTL or a11y. I work in one of those companies, most people just regurgitate existing shit into another form of shit and collect salary (not complaining, as I’m one of them, but let’s be honest).
The original Edge had to switch over to Chromium because it was hard to build a compliant accessible browser from scratch and this is Microsoft we are talking about.
> ...this is Microsoft we are talking about.
Exactly!
More seriously, it not just about building a compliant web browser engine, it is about tracking the dominant browser engine which introduces their own "standards" along the way too.
Microsoft could have easily continued to invest in maintaining their browser engine, but it would have to be comparable to what Google is doing, and yet they'd always be perceived as "behind" due to non-dominant position they have.
I'd say strategically they do not want to invest in tech that's not winning (in marketshare), so when they are not dominant, they'll instead adopt and extend (not just web browsers, look at WSL too).
https://news.ycombinator.com/item?id=18697824
> one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn't keep up
> build a compliant accessible browser from scratch
Which is not something even Google ever succeeded. They had a significant head start due to Webkit being open source.
The didn't had to, MS Browser team was incompetent from the beginning of internet
Oh the memories. Took them forever to introduce something as simple as tabs that virtually all other competitors had since years.
File explorer was the same, only recently it got tabs.
We live in a time now where libraries are free and plentiful and pretty good. It is easy to forget that this was not the case for the vast majority of time that computers have existed.
Chrome’s original design definitely predates our current rich ecosystem. Plus, V8 and Chrome’s performance profile are demanding enough that there would be a pretty high bar for those dependencies anyway.
> We live in a time now where libraries are free and plentiful and pretty good.
Specifically what are you talking about here? Chrome is c++ I thought?
Chrome was invented in 2008. Abseil[1] didn't exist publicly until 2017, derived partly from Chromium.
HarfBuzz wasn't ported to C++ until 2010. I don't know the entire constellation of libs Chrome would use if it was designed in C++ today, but I bet a lot of them didn't exist before Chrome or were even created partly as a downstream byproduct of Chromium.
In other ecosystems: if Chrome were designed in Rust in 2008, there would be no crates.io to pull from. There would be no NPM, since Node followed V8/Chrome's invention in 2009. Maven Central had ~50K packages in 2009[2], which was a lot back then. In 2026, Maven Central hosts over 3 million.
[1]: https://github.com/abseil/abseil-cpp
[2]: https://mvnrepository.com/repos/central
I think you've come from an npm world because c++ still doesn't have a great library ecosystem if thats what you mean.
> In other ecosystems: if Chrome were designed in Rust in 2008, there would be no crates.io to pull from. There would be no NPM, since Node followed V8/Chrome's invention in 2009. Maven Central had ~50K packages in 2009[2], which was a lot back then. In 2026, Maven Central hosts over 3 million.
Yeah, this is all web development stuff.... Doesn't apply to c++
A browser isn't drawing its content using OS frameworks, so A11Y is a major undertaking. Much more so because A11Y for web content specifically is a bit of a different beast than native widgets, and the amount of stuff you have on the web these days means that you have to pay a lot more attention to performance.
Okay, since it might’ve been confusing from my comment: I meant mobile apps, not Chrome or browser. Mobile frameworks abstract all of this.
This is plain wrong. For a browser, a11y doesn't just get handled by the OS automatically. In general, claiming a11y is easy or will be done by someone else is bordering on evil.
[dead]
Spotify has progressively gotten much worse over the last 15 years, all while the size of their engineering team has ballooned.
I am very unsurprised by this outcome.
People wonder why good software becomes bad, and it’s because the people who were good at engineering are often outmaneuvered by corporate-politics savvy people in a growing company. One of the best political moves in a company is to have a lot of people under you.
A couple years ago, an engineer I know who has always been a very poor performer and lacks initiative, but is friendly and non-confrontational, was hired by GitHub. It would not have been hard for GitHub to find a much better engineer, but this person would be an easy person to keep under a manager on a team who wouldn’t leave or make waves. That can be more important to some managers than skills.
>Spotify has progressively gotten much worse over the last 15 years, all while the size of their engineering team has ballooned.
Spotify or Shopify?
Spotify, the comment I replied to drew a comparison from Shopify to Spotify.
I think I’ll start a company called Shpoptify.
You could start a consultancy called Optify to help them optimize their engineering.
Shoplifty
I’ll subscribe to your Sphoophtify service immediately
Can’t wait for Sphpoophteefy+ premium subscription to be released!
Slopify
Probably both
Shopify has gotten quite a bit better tho.
> One of the best political moves in a company is to have a lot of people under you.
This is why I’m sceptical of “AI will kill corporate jobs”. A big company has no profit sharing for successful departments. Everyone is trying to get budget to hire because it makes them feel important.
Sometimes I wonder what the tech ecosystem would look like without the ZIRP era.
I look back over 15 years and with the exception of increased smart phone usage, everything else still looks mostly familiar. Maybe a bit more slick, but also slower and buggier despite having much better hardware.
There hasn't been a qualitative leap in software (as was in the 90s). Just larger SaaS companies. Without ZIRP would it have been any different?
Things have become measurably worse as open standards have been dropped.
An example is messaging apps. Today, if I want to remain in touch with my friends and family I have to juggle between Facebook messenger (thank the heavens for this app which means I rarely need to open Facebook itself), Whatsapp, Signal, etc.
In the early 2000s, even though I was on more services, Yahoo, MSN, ICQ, AIM, a single app such as trillian or Adium was enough to communicate on all of them.
While today we have to go to a whole slew of walled gardens to read posts from folks, such as substack, medium, twitter, etc. earlier, the heavy use of RSS meant that a single RSS news client covered everything.
From a socio-political standpoint, “canceling” also wasn’t a thing, since you could trivially self host a blog and discovery would be no different.
Even better, discovery was through human recommendations rather than algorithms designed to keep you hooked on the platform.
> Even better, discovery was through human recommendations rather than algorithms designed to keep you hooked on the platform.
Yeah, that's one thing that is definitely noticeable. Online social services basically became data-driven psychology research companies, with the goal being to improve engagement. Every page refresh became an A/B test designed to keep you hooked.
That and venture investment has become bane of good.
When a company can run for years, hell, decade+ on the red thanks to investments, that means every competitor now have to compete with company that sells their goods or services below production value. It just kills competition and innovation, which only becomes possible if other company also attracts investors
15 years of extremely well paid engineers and yet we still cannot delete a track from Recently Listened. ಠ _ ಠ
Recently listened is an automatic list like a log, not user curated. I would never expect to be able to delete things from that list.
I don't need an audit log for my audio. What I do need however is to remove something so it doesn't influence the algorithm. I may not remember every time I play music for a kid to turn on the right mode.
That would also then require them to invalidate caches and rerun scripts to rebuild those lists and recommendations, which costs extra compute.
Invalidate the recommendation cache
You mean like, when a new song is added to the list???
You're never going to win against a black box algorithm. Just let Spotify do it's thing or go back to hosting your own music if you don't like it.
I have the impression that for hiring this is fundamentally the most important aspect: Finding a prospect that is just skilled enough for the position without being a risk to the person who is hiring them.
When it comes to number of engineers, always keep in mind that it costs more engineers to maintain (and understand) software than the initial development push.
I’d add on to that lifecycle demands: a development project with no users has a tight cheap feedback loop with high quality bug reports with relatively obvious bug sources, once issues start working through layers of QA and customers the per-issue costs raise by several factors (50x to 200x are numbers I’ve seen from research, YMMV).
I would feel very confident slapping something onto Chrome ‘back then’ with only internal users. Today, with millions of users and CEO-level attention to screwups, I’d use a lot more time per issue. It’s a fundamentally different risk/reward/confidence situation.
The mythical man-month ;)
Any book recommendations, that is not satire, about navigating the political landscape?
Spotify had a good app when it came out, p2p and UDP custom networking...
Such book could be distilled in simple essence:
- stay out of it for your sanity
- sell your soul, organically adapt by looking at those who make it to the top fast
[flagged]
The first comment in this thread drew a comparison between Spotify and Shopify. Perhaps you were skimming and missed it.
I don’t think that AI would have made this confusion (it’s much less likely to overlook things like these), and I’m also not of the opinion that these comments confuse the two companies, it’s rather than Spotify is used by the grandparent as another example like Shopify.
Actually, the first occurrence might have just been a typo (auto-correct?), but the second occurrence looks like slop directed at the previous comment.
Actually, the IAs don’t mess up Shopify with Spotify.
>> This is unfortunately not an isolated issue, Spotify for one has the same issue.
I just brought up Spotify since I have more experience using their app and they have also gone fully into “agents have made us 100X more productive”
AI can do captchas better than humans can
They don’t confuse them, he says both have the same issue.
Perhaps you are the AI slop?
Seriously, it’s funny how confident people can be about something despite their awful reading comprehension.
Aight, I recognize I only skimmed through the comments, I was completely convinced it was a typo because it has to be a big coincidence that in a post about Shopify suddenly they talk about Spotify and it's not by mistake.
This is wrongheaded in so many ways.
To start -- how many of those 3,000 engineers do you think work on the mobile app? And even among those who work on the app -- do you think they're all working on user quality-of-life and just can't get it right? And it's a $175BB company -- do you think it's worth that much based on the quality of its mobile app?
i will bet 175 billion dollars people like that guy are bikeshedding types
What are we talking about here - Spotify or Shopify ?
If Shopify - and you are concerned about their engineering teams, please consider that Shopify's revenue grew from roughly $205 million in 2015 to $11.56 billion in 2025, reflecting an explosive compound annual growth rate (CAGR) of over 45% across the past decade. Market validates !
I have nothing to add about Spotify - I use it to listen to music and it works well for me !
> Spotify or Shopify
Both. The post is about Shopify, but some of the comments expanded the conversation to include Spotify as well.
> In a sane society, Shopify’s opinion on anything engineering related would be thrown into rubbish [...].
> This is unfortunately not an isolated case, Spotify for one has the same issue, [...]
fwiw the post mentioned Shopify and Spotify, hence why you see discussion of both
[dead]
[dead]
Shopify works well for me but it used to push nonsense like podcasts or audio books that I had no interest in, with no way for me to hide them. I just want to listen to music.
Upon looking just now, seems like they have been relegated to their own tabs now, which is great.
I can’t tell if we’re trolling at this point with the mixing up of Shopify and Spotify
I thought we were talking about Sportifei - the new outdoors retailer ?
It's accidental. This mixup is essentially a meme at Shopify this point.
When I did some consulting for an e-commerce company that used Shopify, I had a Colombian coworker who kept confusing Shopify and Spotify which was contagious across our company but we always knew what we were referencing because we dont use Spotify to start an e-commerce page.
Similarly, we've had confusion with AWS Amplify and Amplitude (metrics service).
Poor reading comprehension is more likely than trolling.
Or I just made a typo. I dont think anyone actually has the understanding that Shopify is a music streaming service and Spotify is a shopping plug-in. I was addressing the latter half of gp's comment which was saying that Spotify has had no problems and I wrote (or perhaps got autocorrected, as I had to correct my phone several times writing this comment).
I cant speak for the rest of the commenters.
People who has not run software at scale have no idea what it takes to run it at scale. Google chrome is 60 engineers at launch but google same company has more than 100k engineers. Building first version was always easy and only gotten easy, scaling software was always hard and it is still hard.
PS - Spotify i can't defend the product sucks.
I am quite curious about what people hat so much about Spotify. I made some excursions the last few years to competitors like Tidal and Apple Music but I just found myself coming back because the Spotify mobile app experience (and desktop) was just plain better.
I wonder what gripes people have.
The website, desktop app, and mobile apps all have different feature sets, for one. There are things that you can only do in one of them, but it is a different one of them for each thing. There is no one feature set. It feels so cobbled together, with each platform doing their own thing.
Also, the website is slow and buggy, and the Electron “desktop” app is even worse. Both gobble up way too many resources and soft-crash constantly. The app does not lock up, but simply stops working. Often it even shows an error like “Spotify cannot play this song right now.”.
Also, probably due to some DRM bullshit, resuming a song from the middle doesn't work most of the time. I have to seek to the beginning for it to start playing.
Like that's literally the only thing it should be able to do 100%..
Spotify works mostly fine for me but there's weird rough edges that I don't always see in "simpler" apps.
Stuff like transitioning between desktop and mobile - it tries to work and most of the time it does, but sometimes I need to manually make my desktop play on my desktop. Not a big deal but sometimes I'd be happier if this feature didn't exist at all.
On my desktop, Spotify can be finicky when I connect/disconnect my bluetooth headphones. Sometimes it refuses to play after I connect my headphones, and I need to restart the app. I think it's trying to do something magically for me after it detects the headphones and gets into a wedged state, but a simpler "play to active speaker, whatever it is" audio app wouldn't have this problem.
It's cool to hate on Spotify now I guess. But I agree with you, Spotify works really well for me.
The article is about Shopify, not Spotify.
I wonder how many of the 100k+ enginners at Google work on that "simple" text box that shows you relevant websites to the input text.
I'm guessing that maybe 4 of them maintain that in their "20% time", while the 99,996 other engineers are:
"The best minds of my generation are thinking about how to make people click ads." -Jeff Hammerbacher
It’s not that much about scalling software, as scalling software on highly concentered nodes. Distribution downstream can be its own hell, admittedly, but otherwise having fully independent copy of software copies that run in local terminal is a no-brainer if all that matter is running software at scale.
You're comparing a company (Shopify) to an application (Google Chrome). A better comparison would be the number of engineers at Google (90,000 [1]) vs Shopify, or the number of developers actually working on the mobile application instead of any other area (website, backend database, internal systems and processes, infrastructure management and maintenance, etc.).
[1] https://www.linkedin.com/posts/rpandey1234_its-mind-bending-...
> 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!
Just so it is said: my understanding is it's really easy to not end up on the credits list for games despite having worked on it. I don't know if contractors end up on there for example, at least beyond some team leads or the like. I don't know R*'s policies though, I've heard stories of people not being in credits because they, for example, changed jobs near the end of the development.
I get your overall point though
https://www.rockstargames.com/gta-v/thankyou
They have updated their policies a bit. You may not be in the game credits but you'll show up here.
FWIW the social club team which handled a lot of the online components was small around the time GTA5 released. They built the APIs to handle user generated content, telemetry, accounts, etc. But, there were other team members that made it so the game would call said APIs.
I remember hearing in an old podcast (Dad & Sons), one of the guys there worked at Rockstar in QA in 2012 and he's still listed in the credits for Red Dead Redemption 2 (2018), so the policies are unclear to say the least.
Video games are much easier than what Shopify do which will be a long tail of business cases and local permutations for all the countries they operate in.
Commercial software is usually a simple core and a long tail of business exceptions
That’s different difficulties.
Like comparing a climb and along run. Sure both require some physical abilities, but in the first case any error and the collapse mean dead end bringing progress to zero, while the second one you can rest on the side any time and still have the miles behind you accomplished.
It's complex vs complicated. A compiler may be very difficult to build but it is largely complicated.
Human issues are often complex and may not even have a real solution. Consider human issues like Brexit and the Good Friday Agreement - at face value they are a contradiction and yet a solution must be found.
Coding is absolute - trying to build software that can handle all these edge cases, let alone adapt to environmental changes like the law changing around you, when the decision makers have no insight (or interest) in the details is what makes software difficult.
It's externally mandated difficulties vs internally created ones. I think the latter should always be easier, because you can change the requirements.
In the corporate software world, especially anything to do with the web both front and back, most people really don’t know what they are doing. The goal is hiring/firing and agile.
Compare that to companies that release actual software products. The goal is product release at high enough quality. There are real performance and security targets to achieve.
Your typical corporate developer, on the other hand, does not have release targets. The actual goal is compatibility with the industry least common denominator expectations and retaining employment. This is why so many people are needed to do the work and why the result is so slow and bloated.
What's an "actual software product" and why don't you think web products count as them?
I'm a full stack web developer. I've worked for startups and F500 companies. There is always a push for release targets. The less technical the leadership, the stricter the release targets (its hard to sell a critical refactoring to management when they cant sell a shiny new feature or kpi to their own boss). We've kept our teams pretty lean too.
We still aim for high quality, and performance and security.
I do agree that many people dont really know what theyre doing and are kinda just winging it, especially with AI at the helm, and many companies are likely overstaffed, but I dont think theres a correlation between headcount and slow/bloated software. Any team of any size can make slow and bloated software.
I worked at Expedia for a bit. Ask yourself if they are a tech company, software company, or travel company. It’s not a trick question. They have a shit ton of software developers that work there. Same with Bank of America where I also worked. In fact BoA has more software developers as employees than almost any other company.
Compare those to a company whose only product is software or is primarily a software service.
The difference is directness to the goal. If you are a big bank you need software and web services just like everyone else, but if you get it wrong it’s not going to bankrupt you. You can always hire an outside consultancy to fix it knowing your employees suck at what they do. If all your business does is sell a retail software product and it turns out to be slow broken shit then you have nothing. That’s the difference and layoffs aren’t a bandaid.
At places like Expedia and BoA you can absolutely suck at what you do. Sucking is actually the expectation because 20% of the people solve 80% of the problems, nobody provides substantive training, and everyone is easily replaceable. If you are the guy building innovative solutions on an original software product for a company that only sells software as a retail product you are still ultimately replaceable, but not immediately so.
One key identifier if the business intends to hire sucky people for a sucky job is degree of abstraction. Is the given job about solving a real problem directly, for example using JavaScript to create a new transmission system that achieves higher availability and lowers costs. Or, is it a tech stack nightmare pretending to not write JavaScript to do the same boring shit everyone is doing in a half ass way?
I dont see the correlation between company type (tech/software/X company) and sucking at your job though. Ive never worked for a, as you define it, "software" company because the software ive built has always been in service of selling other things, but people who sucked at their jobs got let go quickly.
And there are absolutely software companies that hire sucky people. I don't know for certain if the people who work there are sucky, but the software they build and sell certainly are.
Maybe for big corporation non-tech companies the calculus is different? But both Shopify and Spotify certainly cant exist without their software.
> I dont see the correlation between company type (tech/software/X company) and sucking at your job though.
The difference is in culture and expectations. People can suck when they are allowed or expected to suck. They can’t suck when the employer sets high expectations. If a company wants to ease hiring and employment flexibility they have to set the bar low to increase the prospective candidate pool. Otherwise they have to be extremely selective and/or train people.
Perhaps the distinction is outside your imagination because it’s outside your experience.
> People can suck when they are allowed or expected to suck.
This is not a unique concept to software or any company type though. You don't have to look far on the antiwork subreddit to find people who work in all types of different industries, technical and not, big and small, where some people just suck and everyone knows it and no one does anything about it.
That is true, but it’s also why most industries require licensing and/or certifications. These things are not 100% effective, but are still excellent at removing disqualified candidates.
If you are selling the code as the product, it could be said to be an “actual” software product, rather than a mechanism for selling other products, or software as a substrate for some other business.
Those other businesses aren’t any less valid, of course. They just aren’t software businesses. They are businesses that (quite sensibly) use software.
Shopify is literally selling software.
That’s right, they are. I don’t think I said they weren’t.
Is Facebook, a company that build software to sell ads, a software company or an ad company? I think its a bit bikesheddy, if not pointless, to try to confine companies to labels like this.
Absolutely an ad company, 100% without question.
A lot of shopify's engineering probably work on the back-end business logic for payment processing, sales tax, etc. Shopify has to comply with financial norms, rule and laws in so many different jurisdictions.
I know someone who works for Gusto (HR and payroll SaaS for small businesses)... most of their code-base is also business logic and whatnot for all the jurisdictions they support.
Comments like these make me wonder if people don't understand the difference between engineering and business.
That’s what they said about Elon firing 80% of Twitter’s staff. But X is doing pretty well.
For some definition of pretty well which doesn't include human user numbers, revenue, profit, or ratio of humans to bots
Pretty well from an engineering perspective. But they've lost so many advertisers because it's intentionally not very moderated.
The site is currently running, yes. Don't forget it went down quite often immediately following the mass firing though. They seem to have fixed that.
There was certainly a ton of bloat to trim, but the haphazard "just pick 80% of the people and fire them" was incredibly stupid. Should have chosen whoever was producing the bloat, at least.
Pretty well if you don't mind some features being built twice or three times and appearing inconsistently at different screens, or users being able to bypass usage limits by pressing the back button on the usage limit sign...
The usage limit is trying to block scrapers and xcancel. It's already reset by the time your cursor gets to the back button.
Twitter was never a profitable business. You actually renforce his point.
(Maybe that was intended I might have missed some irony here)
I'm not sure why people keep repeating this when Twitter was profitable at the point that Elon bought it.
I'd be shocked if a ton of contractors haven't worked for X since then
most people don’t. that’s why they are employees.
Add to it that they need a compiler team for a Ruby JIT, due to the language choice to run an heavy load server infrastructure.
And now we learn they use Swift and Kotlin to replace React with. So they are not replacing it with Ruby. I think they've hit the limits on Ruby (like twitter had on Scala).
P.s.: I find Kotlin "an acceptable typed-Ruby" with an industrial strength VM (the JVM) and two compiles to native stories (KMP and GraalVM-native).
They'll be mostly involved with the parts that make money. I worked in a similar situation as one of about 5 people keeping the core infrastructure of the product working, meanwhile about 500 people optimized the ads
How is life at Google nowadays?
Oh you said 500, not 5000, my bad.
I wonder how many of those are there to consult with customers and help them build their stores.
How many of those 3000 engineers are working on the core engine?
That is vs infrastructure, customer support, partner outreach etc? Then you have all the people working on localisation, not just changing the words, but local regulatory issues.
Chrome only has one customer to deal with, Google itself. And since Shopify is saas and hosted for thousands of customers, vs Chrome running on the users pc, the infrastructure complexity does not compare
>what “engineering” Spotify is doing, it’s the worst app I’ve used in my life.
Engineering is app usability. Theres no other possible thing an engineer might do. Chrome ofc has infrastructure to distribute a binary. Spotify of course having a global content delivery network for terabytes of music. Hey GANG CAN WE WOKK OUT WHAT THESE ENGINEERS MIGHT BE DOING?????? WHY HASNT JIM STORAGE ENGINEER IMPLEMENTED A UI REFRESH YET!!!!
Shopify supports multiple countries both as a buyer/seller. I assume there is all kind of customizations needed to comply with each country weird rules. Are all of these software engineers doing core engineering? Probably not. But they are probably tagged as software engineers within the organization.
> 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!
This is so... wow. You think only 150 devs made GTA 5? Despite the fact that rockstar has 10 studios and you think only 150 people in 5 years touch the code of the game? You should learn how those credits work. It doesn't mean what you think it does.
Furthermore, game dev also includes so many artists and other work. It is so insane to claim gta 5 was made by 150 people that I don't think the rest of your comment can be taken seriously.
3000 engineers or 3000 people on the engineering side of the org ?
Not sure I'd trust Astra in its numbers.
Shopify also seems to be very solid and reliable and I imagine that could require a lot of QA and edge cases (and a lot of support engineers)
Shopify as a company works on a lot more products than Chrome developers do.
More relevantly, a lot of their work involves interfacing with hundreds, if not thousands, of external partners, competitors, etc. systems.
And how many engineers does Google have? The people working on Chrome are a tiny, numerically insignificant fraction of Google’s employees. A much better comparison would be people working on Google ads and their other commercial products.
When you see seemingly simple products have too many engineers, most are almost always there to cater for enterprise customers.
Shopify is handling customer payments worldwide, 90% of their work is probably localization issues rather than customer-facing feature development.
GTA V developers don't give a fuck whether the game is running on a computer in North Korea or in Sweden.
Extremely ignorant comment.
Ironically enough, you using "GPT Astra" to query for such simple information is probably in no small way correlated to the state of software engineering (in these large corporations and otherwise) today.
"A simple app" well there's your first mistake, it's not a simple app is it
When business is booming, you can do nothing wrong, as with that revenue even big mistakes stop mattering.
All I want from Spotify is API so someone can make better player/plugin to a better player.
Tidal is pretty nice to use. Plus the music isn't compressed.
I love Tidal. That said its UI is remarkably heavy for what it is. You also used to see what quality the songs were in without playing them, but they removed that. They added bpm and key, but that is not as useful to most of us as seeing the quality of the song beforehand.
And you also have to make sure you're getting the most out of it manually. Here are three steps for those who have Tidal and wan't to make sure that they're getting the most (ish) for their money:
1. Hardware Source: If you're using the soundcard in your computer, make sure to bump up the sample rate: on macOS you go to "Audio MIDI Setup" and change the sample rate to highest possible for your output.
2. Software Source: In Tidal itself you have to go to "Settings" and under "Audio quality" choose "Max". Under "Playback" turn off "Normalize volume". If you're having a dinner party and playing the music through a bluetooth speaker, you might want to leave it on. But otherwise off; the normalization causes distortion.
3. Output Device: You have two options here and you can go with both or invest more in the other one:
Note: You have to actually find the high quality songs on Tidal to enjoy all those changes. Aim for the 24-bit 192kHz or at least 24-bit 96kHz (personally, the DAC on my Mac only offers 96kHz anyway). Remasters are often a good source, but sometimes they're from the loudness era and are horrible comparing to the originals.Did they finally implemented Last.fm integration and sleep timer?
Comparing Chrome in 2008 to a company in 2026 is a choice.
In a sane society we would be less willing to pass heavy judgement on so many things at passing glance.
its actually not that weird if you consider that those shopify engineers are probably not even exceeding 150,000 usd on average salary wise
canadian dollar is very cheap so you'd likely see 40~50% more headcounts for the same burn rates you get in USA
i definitely dont think those shopify engineers are going to be retained long term however
Lazily researched comment. Pretty much anyone who isn't in sales can have "engineer" in their title. I'm sure there were plenty of "support engineers" in the Shopify number you cited, and I'm sure there were zero in the GTA and Chrome numbers you cited.
One word: Ottawa. There's a lot of engineers, most of them underemployed.
Shopify has approximately 7,600 employees globally
I don't share your opinion.
With no deeper knowledge to the matter, it is pretty senseless to speculate.
"Numbers from GPT Astra" - well, well...
Currently roughly 1000 engineers are working on Google Chrome.
GTA 6 has around 6000 developers working on GTA 6 since 2019.
So sounds a bit off what you allegedly researched. But, hey, AI slop is real.
We have no idea how many of these engineers work on the mobile app. This comment is somehow both AI slop and human slop.
> Numbers from GPT Astra
Come on.
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.
How are you evaluating the Android build if you don’t use Android and you don’t know Kotlin?
We have people on the team that are android users. I just meant that I don't want to evaluate whether it feels "native" as I personally am not an Android user.
You just install it on your phone and use the app.
Maintainability concerns are entirely overblown by people who don't use agentic AI to develop large mobile apps, but anyway give their opinion as if they had that experience.
I put in a few hundred hours, and I reached the same conclusion as Shopify. With reviews from other models and then a manual QA pass the result is fully usable.
I work as a professional app developer. And I find this take to be naive.
Most of the time when I review code from AI, there is always something to improve.
It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.
The maintenance is not only the burden on the human and LLM. With too many moving parts, it becomes harder and harder to build and verify the correctness of future features. Yes you can write test for this and that, but it didn’t need to exist in the first place.
The second problem is correctness issues. Especially the edge cases. You cannot just manually test out a race condition on a phone! Sometimes it happens! Sometimes it doesn’t! If it leads to a visible signal like a crash, then yes, you can try to reproduce it. But there are a lot of these that are “silent” and would just lead to bad experiences.
We already had a software quality crisis! And I think such views only exacerbate the situation! Quality matters!
And this is not an anti-AI stance. I vibe code personal projects where I don’t even look at the code. But when I use AI as a professional engineer, I act like a professional. Because these products do have an impact on people’s lives.
All true (and thanks for posting a concrete example rather than "LLMS suck"). But my take is that none of this is much different than before times when I had teams of developers creating applications. They would often make similar mistakes which I would either need to catch or which would flush out in the field. Where it seems that LLMs are not excellent is where the person driving it is also the senior domain expert so can immediately spot pitfalls. But typically using humans to develop software this was really not often the case. Those people get promoted so they're no longer cutting the code. Under that scenario (replacing subordinate humans) I find the current models are either on-par or somewhat better (specifically because the models can also act like a peer senior dev, discussing approach options etc).
I agree with you! And I’m not trying to romanticize the past! Humans/me wrote slop too.
I think we are over-indexing on speed of delivery. I think this is a mistake. The alpha is in speed and quality.
Currently, my experience is that human + AI can write software faster and with better quality than either party can do alone.
So you don't use agentic AI to develop a large mobile app and you think my take is naive?
I also used to work full time as a Android developer for five years, and I'm pretty sure I know better than you about the quality of my app that I work on everyday.
No where did I say we don’t do agentic dev!
Years of experience doesn’t mean much! I will challenge you on ideas. And the idea you are sharing is dangerous and unprofessional.
Especially at scale. e.g., we process more than 3.5 billion orders annually! This is serious business. Edge cases are common.
> It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.
I understand this, but I just can't bring myself to care. I've been doing professional software work for almost two decades. These sorts of improvements/time savers are great without AI. With AI? Whatever. It's fine.
When the underlying lib has an issue, it'll be quicker to debug with the whole thing in context.
So exactly what value are you adding, then?
I take the specifications from the customer and type them into the AI
Well then I just have to ask why can't the customers type them directly into the AI?
Funny that none of the commenters got the reference/joke
One hopes you are better at that than the many others who are doing the same.
I have people skills; I am good at dealing with people.
You do realize that letting the LLM produce more output means that maintenance will be more expensive? I can easily see a world where claude and gpt are producing more tokens to sell you more tokens.
Just the other day I burned through my 5h quota twice in a row because I had opus spawn a review session on a medium sized PR and I don't know what happened but I told it to summarize to me and it said it spent 100M tokens throughout 50 subagent sessions.
And more recently its been recommending that i install this new browser called Aside. I did, and it almost felt like I was installing malware so I Uninstalled it fairly quickly (it also was not a great browser)
I feel like theres collusion somewhere.
yea man they are trying to nickle and dime you
Well yeah, that's the name of the game of most software companies. Anthropic has been fairly good up until the last week or so when it started needing more hand holding to not do things it didn't normally do.
This is not as obvious as many naively believe.
It depends on how hard to maintain the code added is, how likely it needs to change in the future, and most importantly on the cost.
If reviewing and manually improving the code takes hours, the cost may already be in the thousands.
That buys you a lot of AI usage, roughly a few months of continuous work.
You have to balance this with the chance that the suboptimal code the AI generated is actually fine and maintainable enough, and also the chance that during further work on that code a model might implement the same optimization on its own.
The models will only get better and inference cost will go down.
I don’t see any reason to think the same thing that happens with all tech won’t happen here.
That's just a straight shooter with upper management written all over him
Enshittification and profit maximalization is around the corner looking for you.
Same result here just using plain Opus 4.8+. I had a web ap with a PWA approach. Now I have an iOS app written in Swift/SwiftUI and an Android app in Kotlin in the appstores. I do not know how to code a single line of Swift or Kotlin. You just test the app and iterate with the AI over it until it is stable and does what it should.
> I do not know how to code a single line of Swift or Kotlin
sounds like your app is nothing serious
Why would you asume that, and how do you define serious? Ever since the iOS appstore presence I get more signups from organic app store searches + installs, which results to some percentage in new daily+monthly active users. Meaning: People use the native app and keep using it. That is how I would define have value, as it provides value to the users - else they wouldn't be using it.
My main agentic coding side project is something that I can't justify paying the apple developer license for. If I was an Android person or I didn't have to pay the developer license, maybe I'd just go for it.
Android got wirse than Apple. It costs 25 dollar now to get ID verified (mandatory) and before you can publish in the Ply store you need 12 betatester that install the app from a special link - those testers must keep the app installed 14days. Only then will you become visible publicly in the play store.
So you end up paying people on Fiverr to do it which costs more than 99€
> You just install it on your phone and use the app.
Some people on the cybersecurity side are starting to cry....
I have been getting these comments often here, including concerns about my non existent backend's security.
Last time, when I pointed out that the attack surface for mobile apps is typically very small, some users started to talk about zero day vulnerabilities in the OS's media handling, as if it was a concern for my app implementation.
I found the concerns again wildly overblown.
You sound like a person who's never had their app pen tested. The attack surface is anything but small if you're working with any kind of sensitive data.
But what if someone discovers a iOS 0day worth several million dollars and burns it to compromise your app specifically? /s
Are there cybersecurity concerns in the frontend? I would have thought you have to assume the client is untrusted and only do security work on the backend
1. Not storing secrets properly or using hardcoded secrets
2. Wild use of webviews/iframes sometimes easily propagates as XSS in phones
3. Incorrect client-side OAuth 2.0 configuration e.g. with schema-based redirect URLs.
4. Not supporting high-enough API versions, which may prevent some OS-related weaknesses
5. The list is actually very long. Just few top of my mind.
My favourite is a logout button with a logout API that fails. (Not a huge pratical concern, I admit, because it's a local attack.) Nobody ever notices because it still shows the logout screen, which hides the API error toast (if errors were even displayed). The still valid refresh token stays in sessionStorage (or even localStorage) while the app displays "logged out". (Bonus points if you cleared the access token in the error handler but not the refresh token, and on page reload you ask the user to log in again despite having a valid token.)
Or a login form that gets hidden after login, but clears the username and password only when you click "login back in". (Bonus points if the backend also enforces a 5min session timeout "for security".)
Storing private secrets in your public client is easy to avoid for anyone halfway competent. We are all professionals here.
Turn on the secrets scan in GitLab, and put in your release checklist to have the AI audit the usage of secrets in your app, and this is basically guaranteed not to occur.
I doubt current models even make such a mistake in the first place, and particularly so if you use reviews at all.
WebViews are not an inherent problem, it's the system browser embedded in your app.
Where it gets tricky is if your use case involves authentication in the browser. Together with the authentication in your app this is the one area where you need to focus on security.
The case where a SDK update is needed to prevent weaknesses of the OS seems rather unlikely.
Doing anything right on web is 10x harder and more complex. The problem is the browser, once you use it to deliver anything you have to buy into all of it’s bullshit. CORS, XSS, headers, caching. All that just goes away (outside your backend API, if you even need one) when you ship a native app
Fantastic answer thank you
Nailed it. Assume your client is compromised and/or malicious regardless of how it was built.
This is the most naive take on security ever. For the backend, you assume your client is compromised, but you still don't want to allow your client to be compromised.
If your clients are compromised then what's even the point of backend security. Users will login and do legitimate actions while their compromised client does whatever behind their back, while still looking normal. And the backend can't tell the difference.
They better start a proper hydration regime because they'll be crying a lot.
Why? The api has to be secure. Mobile os keeps the app safe. Where is the attack surface?
You don’t believe how often people leave secrets in the app or use webviews and iframes badly, misconfigure OAuth in client side and so on. There are many issues where secure API does not help.
Ok, yeah, I forgot that people do ship api keys inside binaries
I am using Gemini as well as Opus on a somewhat small project in React Native and I can not imagine this thing being able to build the whole thing on its own without it being a dumbpster fire.
Can you share some details of how you work? What models? What harness?
I use Codex and Claude Code desktop apps. I generally use only the SOTA, now Astra and Fable 5.1, Opus 5 when Fable runs out.
I don't know if Gemini is suitable.
I had few issues with my native iOS app, the results are just decent after a few iterations, the models do what I ask them to do. Where do you see the problem?
The LOC for my app is now at almost 200k + 110k lines of test code.
[flagged]
can't believe what has become of this profession
what in the gobbledygook is this
We use CC with Fable(Opus before that) continuously on a rather large project, everything is tested, we maintain high verified test coverage, we ship features x10 faster than when we started(pre Claude-everything era 2-3 years ago). I never worked with RN before and I ship features now. LLMs allowed us to find issues within RN itself, that thanks to some patches, improved lower end Android experience by a lot. We just use all the Claude defaults with claude.md that evolved over last year.
> Opus
> Are there cybersecurity concerns in the frontend? I would have thought you have to assume the client is untrusted and only do security work on the backend.
I hate software engineering now.
> You just install it on your phone and use the app.
OP says they don't have an android phone...
No, they said they don't use android so don't know the native UX. You can test your app on the platform and confirm that the functionality all works, but how well it adheres to the platform's design language is subjective and hard to say if you aren't used to the platform.
Android studio has a emulator
I used the emulator - but just like I can use an iOS app for 30 seconds and tell you whether it feels native or not, I can't do the same for Android, since I'm not a daily user of Android phones.
And in the past, I didn't care because when I was manually building the app, I would just do my best with react native. But now that I can actually sweat the details (with the help of agents), I do want to hear from android users and use as many OS-native APIs and features.
I missed that.
I'd order a cheap Android phone to have a device in hand instead of working only with the simulator.
Others on our team use Android phones. So when I said that we spent the next few days actually polishing it, that's where others came in, providing feedback when they used it.
I could only sweat the details on liquid glass, etc because I'm a daily iOS user.
That's a recipe for regressions as the amount of surface you have to cover with "just...use the app" gets bigger and bigger.
You can write more automation to test it. But that's also how you end up with ever-growing test run times.
There are much better ways that aren't just "throw out the LLM" either. You just need to be more focused on throughput. Requiring manual validation can pretty rapidly require more hours than just sanity-checking code by hand, even (and I'm not advocating that for every use case, either.)
I can't afford manual QA passes if I'm gonna go as quickly as I want to.
Damn, we really gotta get rid of the vibe coders. Bad things are on the horizon if we keep encouraging these naive habits.
How do you propose getting "rid" of "Vibe coders" (which I'm assuming you're pooling me into?)
Severe financial liability for security breaches, severe enough that, for instance, companies which leak 1m+ user data are driven to bankruptcy
[yes, this would also get rid of the previous generation of 1000-JS-lego vibers]
[dead]
Yes, what type of "engineering" is this? "I click the button and I see if it works or not" holy shit.
> You just install it on your phone and use the app.
That‘s how you check functionality but that’s not how you get the bugs in the code.
That's the part covered by the other model's review. That together with manually verifying the functionality results in output that works.
If you don’t know the language you can’t evaluate if the models really found bugs.
That’s like translating a text to another language without knowing the language
This is wildly overblown. I've been working with agents for a good while, read tens of thousands of generated Python and the language factor is actually the part they get right that humans don't.
Do you know Python?
What do you think has more training data Python or Kotlin?
20+ years of using Python. I don't really think that lack of training data for Kotlin is a problem.
Remember the first step to fixing any problem is admitting you have a problem.
If you are blind, you cant see anything wrong, if you are deaf uou cant hear anything is wrong.
Seriously! What a bonkers thing to claim. "I had codex use maestro so I assume it made Android work well and idiomatically".
It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem, which makes me feel fear in my heart when I imagine the first "production is down" page coming in. I already hated mobile because it's so much harder to maintain than web (and I don't do any spyware or IAP so no benefits for me there); this yolo approach would give me constant dread.
It shows that at least some software development is moving away from code and to product management instead. I'm not passing judgement on that; I actually think that's great for a lot of software. It is interesting to see the shift happening though and will be fun to see if the general quality of software noticeably changes over the next few years.
> It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem,
As much as I dislike it, I think that's the future of _all_ non-critical software (think social media, crms, CI, food delivery etc). Leadership in many companies is explicitly asking employees to have multiple agents running through the day and that will lead to this.
Read this for example: https://www.uber.com/in/en/blog/efficient-software-factory/ . A very useful system, I am sure. But when you have AI at every layer from code to review to triaging, rest assured AI is the only know who knows your system. And you better hope it's not telling you that something is load bearing during an incident.
I read the article and couldn't understand it. I asked Gemini; Pareto things definitely sounds like science.
I read the article again:
- We had bugs. We let agents try to fix the bugs. True positive (fixed bug) is the F1 score. Here are the results for different models. Fixes worked 50% of the time.
- We needed to find a query. Without a knowledge graph it took 20mins, and didn't work. We used a knowledge graph. It was fast (20s), and found the right thing.
I gave my LLM my summary of the article and apparently I "hit the nail on the head".
I have no clue if I learned anything.
I answered elsewhere that I don’t personally use Android phones but we have people on our team that do. Which is why I don’t want to personally claim that it feels native.
But yes we are having real Android users test it.
So it’s quite the contrary. I care MORE what real users say. I can only guarantee that the app does things when I tap. So I’m not trusting the agent on UX, only on functionality. But whether it feels native, I am relying on those users in our team.
That's much better than my original, perhaps unfair, read. Thanks for the additional info.
I still would feel scared operating an established product off a newly changed stack the team isn't familiar with though.
Yeah that's totally fair. So am I, which is why I'm making sure we're still manually testing the hell out of it before we release it.
But our product now has a way more extensive test suite than it ever did, again, thanks to the agents writing pretty damn good tests.
> this yolo approach would give me constant dread.
When you’re completely ignorant, there’s nothing to be afraid of.
I wrote every single line of the react native app we ported, and maintained it for 9 years. So suffice to say, I'm familiar with the code.
But I am going to always prioritize the user experience over a developer (like myself)'s need for satisfaction to see code. And a pure native app is _always_ going to behave better than react native.
This gives me a chance to do that.
> And a pure native app is _always_ going to behave better than react native.
Maybe iOS is better about consistency, but I've used enough horribly made Android apps that I would not expect one that's vibe coded to behave better than a professionally made react native version.
I would if it were based on the RN version. RN is kind of okay on iOS, but really shitty on Android. Would be difficult to be _worse_.
That said, I do recommend reading the code the LLM produces whether you understand the language or not. What better time to learn?
Maybe. Android might still be a mess, fair point.
>So suffice to say, I'm familiar with the code.
You are familiar with the React Native code, you are not familiar with the Swift or Kotlin code, and likely nobody on your team is, since the AI wrote all of it for you.
First “production is down” page means you just tell codex production is down and to fix it.
Presumably a sarcastic post, but this is actually going to be how things are done soon. I had a box that OOMed and needed to be rebooted every few weeks. It was a disaster recovery standby box so figuring out what was going on never rose to the top of my priority list. So I asked Claude to dig into it (proxying the commands it wanted to run through me) and in an hour it had diagnosed the problem, fixed it, and taught me a bunch about memory usage in our system on modern kernels.
Not sarcastic. I have a moderately successful app and I haven’t once looked at the code (though I am capable, so far atleast). The only time I open Xcode is if I have to modify signing certificates. I did set up a slack workflow with a “fix it” button that basically tells Codex to fix the issue, run comprehensive tests, manually UI test for that particular issue with computer use and then deploy it.
Equal parts very cool and very scary to me
It is. For my day job, I’m a software engineering director and I probably won’t have a job in under five years. For low to medium complexity apps, even Codex before Astra was capable of doing it completely by itself from scratch. For testing I would bring up the app after each atomic change and then manually try it out. I also use my own app heavily multiple times a day and I have found dozens of issues but I just ask Codex to fix it on the spot.
[dead]
ITT: people dealing with realities.
Remember Chinese accounts on US Facebook say data centers are bad.
React native is an obstacle compared to what clear Swift/Kotlin code may produce. Swift is very powerful and Kotlin, in all honesty, is the first reasonable and very useful thing to come to the JRE ecosystem (save for Scala, which is, well, quite complex still).
Myself turned some python code to Swift, and keep doing so, without trouble or pressure. Of course, I've been doing fair amount of systems programming for 20 years now, so not sure what to advice newcomers. But this approach to dev DOES work for me very well.
Sounds like the advice to newcomers is to not worry about trying to learn a programming language. There already is an llm to program for you, and do it better than you could, so just learn how to talk.
Once you understand how to write a program get someone else to write it - Perlis.
[1] Epigrams in Programming:
https://engineering.yale.edu/academic-study/departments/comp...
And people say AI isn't taking SWE jobs...
While I mostly agree with you, this is the kind of thing that might not have been done if the AI couldn't do the heavy lifting.
They had previously chosen React Native because it was easier for programmers to keep it updated, since it was really just 1 codebase. With AI, those same programmers can do the more difficult version, keeping the native apps updated separately.
So did it kill a job, or did it make it possible for the existing programmers to do it better?
It's the kind of thing that is really hard to determine in general, but here, it really does sound like they only made the change because it became possible with existing resources. They would not have done it otherwise.
That's an example of AI growing the sector that can lead to more jobs. Because suddenly a lot of tasks that weren't economically viable are now going to be in demand. Custom software for small businesses, platform specific optimized code instead of cross platform software, etc...
In case of my company, the port was planned for this year, with a 9 month timeline and about 10 FTE team. It ended up being done in 3 months, with 2 engineers. (Sure, plus testers and internal bureaucracies, but that 2 FTE for 3 months vs. 10 FTE for 9 forecasted is apples-to-apples). Sure its eating up SWE jobs.
This is a type of project that likely wouldn't have been done before AI
Of course it would. Supply and demand. Some companies would decide not to bother. Others would decide it was worthwhile. The limited pool of supply (app developers) would be distributed across demand.
>> Some companies would decide not to bother. Others would decide it was worthwhile.
The parent's point is that AI lowers the cost/benefit ratio drastically, by reducing the cost. So companies that would have shied away from projects like this pre-AI are now pulling the trigger without much hesitation.
And what a lot of people seem to miss is that with AI, there is going to be (already is?) orders of magnitude more software in this world. I'm sure a lot of jobs will be eliminated, but new jobs will be created as well. Hopefully enough to balance things out, but we'll see.
> The parent's point is that AI lowers the cost/benefit ratio drastically, by reducing the cost.
…as long as Claude is still subsidized…
[dead]
> Some companies would decide not to bother
Sounds like you agree
I agree that AI is suppressing developer wage growth and taking real jobs. The opposite argument is being made elsewhere in the thread, and I think that argument is wrong.
It ported overnight. I don't think it would create from scratch without a lot of hand holding.
Previous company I worked for would have (and did) hire dedicated swift/java mobile developers to build and maintain ios and android native versions (largely porting functionality from an existing web application)
Not anymore.
What's more likely (as others have said) is that the other thousand companies that can't afford to have dedicated staff would've just used React Native. So no jobs were lost, they weren't there in the first place. The places that have dedicated Swift/Java devs can now be more ambitious in what they build.
That's fairly rare. Most companies would use a compatibility layer instead.
Really? I’ve worked with plenty of companies that had separate native iOS & Android teams. I don’t know any that use a compatibility layer. Unless by compatibility layer, you mean a web view.
This does seem like the kind of task LLM's are ideal for. Just like that port of Bun from one language to another.
This app has 15/20 screens, an app this small wouldn't employ many people to begin with. Before there was one guy (op) maintaining it in react native and now he maintains it native. I don't see much change tbh.
The optimistic outlook:
Just like this has made Web devs into Mobile devs, so could Mobile devs leverage AI to work in Web shops.
I'm not an optimist but there could be an increase of available apps being created which would still keep people employed. Theoretically the cost of creating an iOS app for a company without an engineering team dropped from several hundreds of thousand to a few thousand or hundreds, which could be paid out to a freelancer with AI. More people would go into freelancing for industries which were not contemplated before due to cost.
But I'm not an optimist.
This is an incredibly boring task. Nothing new, just rewrite everything to just see it all rewritten again in 1 year. Perfect for LLMs and something humans shouldn't do.
While I agree with that statement -- that is also a lot of jobs. We have a lot of humans -- not every single developer sits in the innovation seat. The fewer the jobs available the less employable humans.
I think that rewrite - if AI enabled - owes its thanks to the legion of individuals who put their code up on the internet in the first place.
Weird times.
Unfortunately theres no thanks to the suppliers of training data. US courts made sure there’s no recompense for them, and likely never will be.
Seems similar to eminent domain, but without limitations.
> This is an incredibly boring task.
We all want super exciting jobs. But plenty have boring jobs like this. Between not having a job or having a boring job that pays well, the choice is obvious for many of us.
Are you defending doing boring work?
I personally never minded doing migrations. I guess I don't really have to anymore though. Weird.
The problem is that in many companies doing migrations would be the only job, thus now there is none.
This is just not true. In the olden times (pre-claude) devs were constantly asking to do full rewrites of legacy code. This kind of project is exactly the kind of work I've trained for and have loved to do for the last 15 years as a mobile dev.
I assume having Kotlin and Jetpack Compose makes it much easier than it was back around 2020?
We did the same with our apps used by a few hundred thousand people a day. We are a slow, boring company, so the port took about 4 weeks of engineering work, and maybe 3 months taking into account release process and change management. But in fairness, we had the first working version after a day as well. This was in February, too, with substantially less capable models, unable to do overnight runs.
I thought the same, but then I build a few complicated apps and thought I could keep the different codebases stable but still was a headache, so switched web, ios, android all back to expo/rn. I love that testing is only (almost) only thing now, instead of 3 platforms.
React native is broadly an inferior option.
LLMs made it way worse https://ashishb.net/tech/react-native/
this is from 2021....
and still accurate in its conclusion, probably moreso today
This has been my conclusion as well. Agentic workflows drops the effort level in keeping two native code bases in sync.
Same conclusion here. My current preferred setup is native for iOS and Android with common core in rust exposed through uniffi
I was surprised by your comments and then you do Rust to be called via Java or Kotlin and Swift?
What does your app do?
Yes uniffi created swift and kotlin bindings. The app I did with this is just a sudoku game https://www.puzzlesight.com . Before AI I would have reached for something like Flutter to avoid doing all work twice but with AI doing two apps makes more sense.
Okay, makes sense, the whole thing looks and screams vibe coded. On a beefy machine, navigating between your website pages takes 2-3 seconds. So still a long way to go with AI.
Interesting, it's instant on mine. The landing page is just Astro with cloudflare in front of it, the origin server is a hetzner box in Germany though.
Congratulations, you now have 2 codebases to maintain.
So now you have two vibe coded applications you don’t understand. I’m not an advocate of making “job security” decisions but this definitely goes to red flag territory. Was it your job to maintain the RN codebase or do you have other functions there as well? I’m not sure I would keep a native noob on a vibed native codebase. What is your take?
And there's no proprietary IP in your company's app that you don't mind being sucked up into the training data?
> there's no proprietary IP in your company's app
For most app that concept is "gone".
People routinely decompile and recompose existing binaries, and if you use "obfuscation" in your app it's still a small bump.
In today's age, IP is no longer a tangible concept that gives any advantages in software. What differentiates two businesses isn't their IP, it's their relationships and their moat.
Most vendors that had protected proprietary IP are now irrelevant within their vertical. What saves them are the protection provided by patents, which is public.
Can you back these claims, please?
The value of most companies/apps are in the relationship with the customers, so it's the database, not the code.
Definitely agree. Most developers could build a basic Twitter or Facebook clone. The hard part is getting the users, content, and relationships that make the product worth coming back to.
It is both tbh. Anyone can build a poor clone of an application. However there are many things that you don't realise is happening beneath the scene.
It is all the small things e.g.
YouTube Mobile website works really well when you have a inconsistent connection compared to the alternatives such as Odysee, Rumble, Kick and Twitch.
I can listen to a live stream or a video style podcast in the car and YouTube will resume the connection properly as long as the browser tab on my phone hasn't gone to sleep. Kick will just stop, if it is a replay it will resume from the start of the stream after rewinding the stream a few seconds while attempting playback.
While the code to do this isn't that difficult. YouTube has bothered to deal with the edge case of someone like me driving through an area with inconsistent connection while running their mobile site (not even their app).
Whenever people try to use alternatives, they often complain about poor reliability of the app. A lot of the clones are losing users and I doubt they really even know they are doing it.
Is all this praise of YouTube on android or ios?
I've had it work well on both (iOS and Graphene OS) using Brave browser on both. It is simply much better when you are on a unstable connection than any of the other sites.
Are you saying you don’t trust ZDR claims from inference providers?
They don’t care about your code. There’s more and better data on the public web.
Isn't ZDR only the case if you "opt out" through a setting? Lots of opportunities to make a mistake here, or for the LLM provider to play games. You could be unaware of the setting. The provider could reset the setting upon subscription lapse/renewal, application update, model release, etc. A developer could accidentally use their personal subscription (w/ setting on) on a work codebase.
Also what's the timing on this setting's effectiveness? What if before you knew to "opt out" you used the agent for a refactor and your entire repo got sucked up in inference? But then you opt out the next day? Is it too late?
That’s the case with a personal subscription directly with OpenAI or Anthropic, but enterprise customers are opt-in, AFAIK.
And there are solutions around it from other providers and model routers. OpenRouter lets you explicitly say on a per-request basis you don’t want to be routed to a provider that trains on your input, for example.
The mistakes you describe are only possible if the company doesn’t really think there’s proprietary IP in the codebase.
If a company really believed there’s valuable IP in code, there would at a minimum, ban laptops or ban code on laptops[0], provide and maintain a centrally managed LLM gateway[1] that handles authentication, billing and model choice, have MDM to prevent you from using your own Claude login, etc.
[0]: For example when I worked at Google, the proprietary google3 codebase cannot exist on laptops because there are no tools to download it to your laptop.
[1]: For example Claude code supports having a gateway: https://code.claude.com/docs/en/llm-gateway-connect
I'd wager many software startups out there would consider their code valuable IP (even if in the AI era it's not), and don't have these types of IT controls in place. Startups I worked at gave you an email account, github access to their private repos, and that was that.
Heck, you don't even need to mix up a personal and business AI subscription. For the vast majority of folks one day their IDE "updated" and a bunch of AI features suddenly became available. Free, no sub needed. A dev starts using them (because, why not?) and lo and behold the company's code got shipped out in an inference call and is now scheduled to be in the next training run. Oops.
You are merely describing companies that aspire to consider their code valuable IP, not companies that actually do so.
IDE updated? It’s the company IT’s job to perform testing before distributing those updates. And also their job to use whatever managed settings to disable those unmanaged AI features.
Yeah man I think we just have experience in two different worlds.
A single digit headcount startup with a "company IT" team testing program updates before distributing them??? Um, no. You just download VS Code (or whatever IDE you want) on the Macbook they give you and it updates when Microsoft pushes a public update.
How's that any different from, say, Windows updating and backing up the company's code to OneDrive?
Actions speak louder than words. If the company doesn't even supply and require work devices, they don't effectively consider their code to be valuable IP.
Is Microsoft mining their customers' backup files looking for source code to ingest into their model training pipeline?
Of course the company can still consider their code to be valuable IP.
Every company that is not Google lets you have code on your laptop. This is only an annoying thing that they came up with.
Mine doesn’t. They don’t even issue work laptops; work is done on desktops only.
You should educate yourself about AWS Bedrock and Azure Foundry.
As other have mentioned, the code isn't the valuable part. But also there are alternatives now to these LLM providers.
Codex with what model?
Next up, designing an even higher level language which will be used by LLMs to compile to high level languages like kotlin or swift. Just store instructions for LLMs in repos.
[flagged]
2020-01-29: https://shopify.engineering/react-native-future-mobile-shopi... ("After years of native mobile development, we’ve decided to go full steam ahead building all of our new mobile apps using React Native.")
2021-11-08: https://shopify.engineering/high-performance-hydrogen-powere... ("The future of commerce is dynamic, contextual, and personalized. Hydrogen is a React-based framework for building custom and creative storefronts powered by Shopify’s platform and APIs.")
2025-01-13: https://shopify.engineering/five-years-of-react-native-at-sh... ("React Native has come a long way in the last 5 years and a lot of limitations that led people to not adopt it simply don’t exist anymore. If you haven’t tried using RN in a while, now would be a good time to revisit it.")
2025-09-05: https://shopify.engineering/react-native-new-architecture ("We successfully migrated two of our largest apps, Shopify Mobile and Shopify Point of Sale (POS) to React Native's New Architecture")
2026-09-10: https://shopify.engineering/back-to-native ("React Native was working well for us, and it remains an excellent framework. But since then, coding models have gotten dramatically better, and for our apps and our team, building the same feature in Swift and Kotlin no longer carries the cost it used to.")
^ to show the timeline of things.
Seems a lot like the meme of the new designers pushing a redesign to justify their existence.
To be less dismissive it seems an industry wide problem that big splashy projects get rewarded while the silent “Snow Leopard” mind numbingly obvious just up your quality and fix bugs and UX issues work goes unnoticed.
I don't understand the logic. AI vs Human development still have similar cost profiles. It costs $ per unit of thought (salary or tokens).
If React Native worked well for human programmers, wouldn't it be just as good for AI?
ah yes, the classic full circle
/remind me in 6 years about this thread
Makes perfect sense.
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.
> The continued React Native tax of unnecessarily difficult upgrades,
My very first experience of RN was having to update an app to handle the mandatory change to 64 bit APKs
Which required a massive update not only to several dependencies but also xcode, iOS frameworks, the weird objective C caches that get smuggled into node_modules, _as well as_ all the rigmarole or making the 64 bit APK build work
It was completely miserable
> The continued React Native tax of unnecessarily difficult upgrades
I thought I read somewhere that this is what prompted the move. I don't use RN, but apparently the new architecture isn't exactly a drop-in replacement.
I experienced the same issues but went the other way and migrated from React Native to React. Still one codebase but none of the issues. Performance was better too even though half the code stayed the same.
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.
They specifically say in the post how React Native was the correct decision and that it worked well for them.
Now it's a different situation as implementation has become incredibly cheap.
Not sure why someone would say it was a wrong decision. Why would they even need to do this if LLMs make coding easier. They are likely chasing the things I advocate for: direct access to latest APIs from each platform, platform specific UI, UI that behaves correctly on each platform without chasing down edge case solutions (also said as ui that looks and feels "right"), and a bonus of separate developer pool to hire from that knows the ins and outs of the platform without needing to hire a developer to know all three- react, iOS, and Android.
> Not sure why someone would say it was a wrong decision.
Writing almost anything with javascript sucks ass to begin with. Writing native code with it is even more painful. Most javascript engines don't even have any decent model of parallelism. It takes zero imagination to see the problem here
how much parallelism are you writing in your frontends?
The problem with everything being single threaded isn't so much that you want to do a lot of parallel processing, but that you don't want to have the occasional fat loop cause the whole engine to start stuttering. If you want butter smooth scrolling while there's (for example) a lot of dynamic content moving around, you want very precise control of the threading so you can get the gnarly stuff done without causing hitches that don't feel right.
The browser, iOS, and Android all use a main thread separate from the thread responsible for scrolling animations.
However, I think it's true that controlling threading in order to perform gnarly work in a separate thread is more ergonomic on mobile than in JS/React.
You'd need to create a Promise that wraps a Web Worker, which would be an unusual thing to use. I don't think most apps need such control over threading in the browser.
If you care about smooth interactions, the browser even in 2026 is not the most straightforward route, nor the route any reasonable small company takes.
I mean, why would they admit to it being the wrong decision. Its a business.
Why would they need to worry about hiring for specific skills at all? As AI progresses, isn't the only skill that matters that you can drive it effectively (which encompasses testing and review) without needing oversight?
Because we are not there yet and you can't oversee something you don't know
> worked well for them
yeah because they don't care about a top notch user experience.
Yeah they do say that but as someone who has worked on native apps / RN for most of my career I think that is bullshit. They're not going to come out with a mea culpa owning that, this is as close as it gets.
FWIW, the native app specialists are in some sense the most invalidated here. Shopify decided they couldn't afford your skill set and didn't change their mind until you could be replaced with an LLM.
Really the whole concept of technology specialization is the thing in jeopardy. It no longer appears to work to make a career out of deeply learning something obscure. Agent-farming generalists appear to be the ones who own the future right now (if, heh, not the agents themselves).
My validation is that platform specific codebases is what is the right course of action. The c-level decision is that they want the cheapest route to consumers. My point is that consumers can tell, the product is better, and developers are happier working on native codebases.
I'd challenge you to determine which of the top app store(s) apps are react native vs not -- plenty of app store awards have gone to react native apps -- bad software is bad software. plenty of you ios devs write shit software. I've done this job almost 40 years and no language or platform has ever prevented people from building shitty software or for that matter gotten in the way of writing good software. good engineers can figure it out.
source: ios dev since it was possible -- I am not even pro react native, I am just pro merit based arguments -- you aren't making any
Challenge not accepted but deferred to the article where one of the largest business wants to sit at the intersection of native apis without a a middle layer for the sake of saving money. Put another way, given unlimited resources, native wins out over shared.
You should read the article. You'd realize that you're not actually vindicated by its contents.
I read it. They chose native over shared. Hence vindicated.
Derp. Read it again.
Shopify is moving its mobile apps from React Native back to native Swift and Kotlin. With the main cost of native gone, the benefits of staying close to platform APIs and first-party tooling win out. This has been my ethos. That native is better than shared.
Your argument was you've argued your whole career for native. The article argues only very recently the cost equation has changed. Your argument reads like you are not taking into account the broader context or the passage of time.
I'll put it this way, my argument was pro native. And in the context of the article, if a large company had unlimited resources, they would choose native. I'm not discussing the business case for it, but the end result of it being the better option. It can be seen as "Shopify tried Reactive Native and left it behind the second they could after sinking resources into it for 6 years".
Everyone always knew native was better if dev cost weren't a factor
Go back in time and read the react-native vs native debates. Many react advocates claimed otherwise
Time and progress have overtaken them. At the time they were likely correct but I certainly wouldn’t bother with react native any more when the LLMs have gotten so good
What was the claimed advantage of react-native aside from ease of use?
I don't see why you would, unless your argument for your whole career has been that LLMs make this easy.
My argument is that platform specific codebases is the right course of action. My point is that consumers can tell, the product is better, and developers are happier working on native codebases.
> developers are happier working on native codebases.
Agents are happier working on any codebase, but ultimately Shopify and other companies want iOS native app level quality without the huge cost of hiring many native iOS / Android devs.
LLMs and Agents deliver on getting a native app out at lower cost, higher quality, faster all at once.
I think everyone is trying to tell you your skills as an iOS native dev have been commoditised and Shopify and others don't need to hire anymore native devs to find this out.
I don't see how your job being completely commoditised and cannibalised by LLMs replacing your job is some how vindication?
This is just like saying "we won the argument", but what did you actually "win"?
Yea, I hear that. I'm content with winning the argument and truthfully, I think they will find they need to hire iOS engineers because we do more than write Swift. There are whole ecosystems of knowledge to go from a product idea, sit in meetings with many stakeholders, and implement the actual thing everyone wants. All they got here was a 1-to-1 implementation of their current app which was born of engineers working through real constraints. It says nothing of new features that have to play nice with other pillars of the company.
> I think they will find they need to hire iOS engineers because we do more than write Swift.
Shopify isn't hiring any mobile engineers.
Probably because the agents were hired first and took the job already.
That is the point of the job being literally commoditized and cannibalised, they hire less or close to 0.
Your quixotic 'vindication' means nothing and has the opposite effect.
Not sure why you are defining my vindication. Its purely rooted in native is the better solution for mobile apps. Which they are using. Not sure how that makes it the opposite.
You're looking at it from iOS side only, and for a US company that would be the last platform they'd ever drop.
It was a different picture out of the Apple garden, when a company only brings their next major feature to iOS because they couldn't be bothered to hire the same headcount on two development teams and their CEO uses an iPhone anyway.
We had that discussion about a decade ago with a company rep that didn't realize 70% of their EU users were on Android yet their play store app didn't have the feature they were planning to promote.
Basically, better was the enemy of good for most companies.
Correct, I advocated for the solution that produced the best outcome for user experience, code and architecture simplicity, and prevented having to rewrite an app in the future in native. Which has been validated here.
The android shortfall is a real one but I also pushed for hiring native android developers too.
As someone who has watched a team battle Xamarin and now Maui, and all the painful upgrades in between, I agree with you. Sure they never had the pain of supporting two separate codebases, but they also never had the luxury of doing anything the easy way.
We'll have to wait and see if the extra maintenance / bugs / attack surface is justified. This an announcement of future direction so vindicated is certainly premature.
They're right when it makes business sense, which is also about cost and why Shopify didn't do it before.
I'm not arguing the business sense. Two sides can be right which is why I advocated for native development. Which is vindicated here.
If you weren't arguing against the business case, what were you arguing with the C-level types about? I don't think I have ever heard a case for react that wasn't centered around shared codebases mean fewer resources/cost/time to deliver a feature.
Because someone needs to be in the room to show the “make the most money with the least resources” people that there are more variables to consider.
In other words your team also resigned the next day ?
probably because every react native app they've used feels like shit
I'm inclined to agree on certain points; true native apps are, generally speaking, better when it comes to e.g. customer experience. It comes with risks and costs (but I think the cost vs benefit is exaggerated) - risk being the ability to find good native developers, which aren't as common as e.g. web developers who can switch to RN fairly easily.
But there's a factor few people (that decide on using RN) miss; it adds a layer of indirection, so you're no longer as "in touch" with the underlying platform. While possible, few RN developers would consider adding widgets or smart watch apps to their main app, but (I feel like) if you're a native iOS developer who is all-in on the Apple ecosystem, you're more likely to try and adopt these features (where applicable).
(disclaimer: RN is my current day job, used to do native iOS development and I frequently miss it)
Same here. Glad I stuck with native iOS development. I still haven’t switched to SwiftUI though (except for some small stuff). Still sticking with UIKit here.
If only LLMs had been invented at the beginning of your career, you would have been right all along!
what they should've done is written logic etc.. in rust and use mobile app just for native layers, so they can still share code.
[dead]
[dead]
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.
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.
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.
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.
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.
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 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.
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
Hmmm, the article doesn't really say what is better about the Swift/Kotlin apps, compared to React Native. All we get is:
"Native keeps us closer to platform capabilities and first-party tooling, with fewer framework and dependency layers between our code and the platform"
What's the user benefit of that? It's not speed, they say "React Native apps can be fast. Ours are."
I'd expect it to be considerably easier for a few people to use the AI to improve React Native with whatever matters, than for every company in the world to permanently maintain two apps.
And those improvements to React Native, would make all mobile apps easier for everyone to build forever more.
Are LLMs going to stop everyone collaborating, making libraries and platforms, and shared language and abstractions, because we can all vibe code our own thing? This seems a loss to cost and quality, even with lots of tokens available.
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
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
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'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.
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?
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.
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"
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 ]
I believe this will be overall trend in industry. Dropping React Native and Flutter for native
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?
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
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.
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.
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.
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.
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.
Vibe-based architectural changes undoubtedly destined for "extreme" success until the next turn of the churn
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.
https://shopify.engineering/shop-app-migration
follow up with some more technical details and benchmarks
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.
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.
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.
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
And so the mobile app development wheel turns. All of this has happened before, and all of this will happen again.
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.
When so many people talk about companies going with React "because AI knows React," it's interesting to see Shopify draw the opposite conclusion: AI "knows" all major platforms and frameworks, so at a certain scale it makes sense to let AI handle cross-platform development as a translation problem.
Modern LLMs evolved from translation models, and they still seem to work best at translation-shaped problems. Even if you are asking them to translate specs to code, or code for system A to code for system B.
In my case, I added SQLite and Postgres adapters to a formerly MongoDB-specific CMS, including support for a largely compatible API, "in one wild weekend..." followed by lots of verification. That was only practical because we already had a large test suite. But it was still a task that would have been out of the question for our team size before Opus 4.6 or so. Again, it was very much a translation-shaped problem.
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.
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.
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.
They are admitting React was a shtty choice for a mobile app if they have a choice.
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
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.
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.
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.
I've been a mobile developer for 15 years and being able to develop two codebases in parallel is by far the best productivity gain LLMs have to offer in this space.
These cross-platform SDKs try too hard to solve a very difficult problem and never last (looking at you Xamarin). My first job was actually working on a Lua framework that was shared between an Android and iOS codebase.
It's far better to tell claude to port your swift+core data implementation to kotlin+room then fix whatever it did then it is to try to debug a complicated view hierarchy that renders incorrectly on a specific Android version because you're framework decided to nest a list in a scroll view.
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
Not mentioned but this also gets them away from what now seems monthly npm supply chain attacks.
Big win for security
The answer depends on scale, and appropriateness. If you've got enough engineers, you can do platform native code. The results will look better.
Appropriateness often comes down to is the code doing deep platform API things, with sensors for example, or anything else that's not part of user interface, but has an API that's going to require you to write platform native code.
Shopify clearly meets the first criterion, but are the commerce and security parts enough to drive the second criterion?
Anyway they're big enough to make a slightly less than optimal solution and still get a better result than sticking to a cross platform SDK.
The true test here, which I don’t see much discussion around, isn’t how fast or how well agents can convert the existing apps to native; it’s how fast and how well the team can build entirely new features across platforms with native vs react. The existing app code is an unambiguous spec — perfect for agents to build from. Typical design specs, PRDs, and prompts have a lot more ambiguity. There’s a lot of iteration that needs to happen to get a feature from concept to launch and I’d wager that will not be as fast with the fully native approach.
> Agents can make code changes in seconds, but it takes them several minutes to test the output. This makes iterating extremely slow and manual ... We’re fixing this by designing our app architecture to work for both humans and agents. The core principle here is that business logic should be completely decoupled from the UI and be able to run headlessly on desktop.
Looks like we're back to Uncle Bob! [1]
[1] https://youtu.be/o_TH-Y78tt4?t=2203
The wheel of fashion turns once more.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
Sounds like they have problematic management. https://x.com/ErfanEbrahimnia/status/2098145097334379001?s=2...
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.
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.
How long until LLMs just write machine code?
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 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?
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?
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 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.
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?
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?
Can’t wait for the blog post mentioning move back to react native or other cross platform framework.
Their reasoning makes sense. I'd love to read a follow-up and their thoughts in half a year.
I guess expect no new features on mobile until their token budget gets through all the screens?
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.
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.
The 3000 vs 60 comparison ignores what the products do. Chrome 1.0 couldn't print; a complete browser took hundreds more engineers.
Lol, they bought Tailwind CSS, freaked out, and decided not to touch it at all.
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.
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.
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.
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?
Technology historians will pin 2026 as the year frameworks died.
If you build with electron in the age of LLMs, you should change career
Curious how much of this was React Native limits vs just wanting one UI toolkit the iOS/Android platform teams already know cold.
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.
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).
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.
> 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?
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
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
> 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?
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
“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.
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
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.
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.
Finally some common sense. Time to put electron to rest.
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.
Shopify always comes up but I do t know much about it. Do I interact with Shopify sites without knowing they are Shopify?
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.
Would be nice if Spotify and Notion did the same.
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
I've been out of FE dev from awhile, is React still leading? I feel like Vue might be taking over?
In the history books, this'll be the post indicating the end of writing code as a professional occupation.
Thanks for sharing this. The methodology is solid and the results are informative.
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.
Maybe cross platform devkits would not be choosed only becauseof development cost.
Let’s see their app size (and heap)
Who respects shopify's engineering practices?
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
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.
And they still has zero job openings for Android/iOS devs
Major loss for react native community at large with Skia and Flashlist dying. :(
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?)
The article failed to provide reasons on they why move back to native.
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.
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
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?
Does that mean no more react native skia sponsoring?
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
Native. Metal. Remove the abatraction layers
the end of Electron would be a nice silver lining to the new era of coding
is there still no way to compile / execute ios apps on a linux machine ?
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
It's nice storytelling, but hard to take completely seriously. As others have commented, there's a lot that's not being said.
We may also look back on a (now-deleted?) tweet in which this company's CEO meme-trolled another engineering org. for their mobile decision-making. The overall tone here and over the past years comes off as holier-than-thou.
I'm still laughing.
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.
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.
May be a good decision.
Hey what about Flutter
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.
Who could have guessed it!
A side effect of perceived LLM Generated code is now easier to just make it write native I guess.
While Meta's Whatsapp just dropped native Windows client for Electron
Lack of vision?
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.
Why not flutter?
Cool story but what's the token spend?
What is really going on, why suddenly every single company is just saying we going to go native? I mean they are working fine as it is
LOL, good luck keeping feature parity for both code bases. I moved to Flutter which has been a great experience so far.
IMHO, now is a great time to use native Swift/Kotlin code alongside shared Rust code via UniFFI
"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.
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.
[flagged]
[flagged]
[flagged]
[dead]
[flagged]
[flagged]
[flagged]
[dead]
[dead]
[flagged]
[dead]
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.
[dead]
[dead]
[dead]
[dead]
[dead]
Reminder that Shopify's CEO and COO are both literally Nazis and they host websites for literal Nazis.
expected
Good one
this AI stuff is goin crazy
"native" shouldn't be capitalized in the title
the reason what I believe is that, AI can understand react very well. so It can be beneficial for Shopify
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?
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!
Web based mobile made sense pre AI. It is just simpler now to use different languages and have AI implement features across the board.
It's not surprising. Code is cheap nowadays because of AI. I reckon more companies will follow suit.