Shopify is moving from React Native back to Swift and Kotlin
shopify.engineering
shopify.engineering
- 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.
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 or Shopify?
I think I’ll start a company called Shpoptify.
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.
Spotify had a good app when it came out, p2p and UDP custom networking...
- stay out of it for your sanity
- sell your soul, organically adapt by looking at those who make it to the top fast
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 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?
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
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.
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.
You mean like, when a new song is added to the list???
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 !
Upon looking just now, seems like they have been relegated to their own tabs now, which is great.
I cant speak for the rest of the commenters.
Similarly, we've had confusion with AWS Amplify and Amplitude (metrics service).
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, [...]
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
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.
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.
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.
Those other businesses aren’t any less valid, of course. They just aren’t software businesses. They are businesses that (quite sensibly) use software.
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?
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.
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.
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.
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
(Maybe that was intended I might have missed some irony here)
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.
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?
Oh you said 500, not 5000, my bad.
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.
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.
PS - Spotify i can't defend the product sucks.
"The best minds of my generation are thinking about how to make people click ads." -Jeff Hammerbacher
I wonder what gripes people have.
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.”.
Like that's literally the only thing it should be able to do 100%..
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.
[1] https://www.linkedin.com/posts/rpandey1234_its-mind-bending-...
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.
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).
File explorer was the same, only recently it got tabs.
> 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
Which is not something even Google ever succeeded. They had a significant head start due to Webkit being open source.
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.
Specifically what are you talking about here? Chrome is c++ I thought?
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.
> 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++
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.
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.
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..
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.
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 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."
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.
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.
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!!!!
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).
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.
All I want from Spotify is API so someone can make better player/plugin to a better player.
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
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.
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.
Come on.
More relevantly, a lot of their work involves interfacing with hundreds, if not thousands, of external partners, competitors, etc. systems.
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.
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.
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)
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.
Not anymore.
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.
…as long as Claude is still subsidized…
Sounds like you agree
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.
Seems similar to eminent domain, but without limitations.
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.
I personally never minded doing migrations. I guess I don't really have to anymore though. Weird.
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.
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.
What does your app do?
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.
They don’t care about your code. There’s more and better data on the public web.
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?
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.
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
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.
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.
Of course the company can still consider their code to be valuable IP.
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.
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.
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.
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.
OP says they don't have an android phone...
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'd order a cheap Android phone to have a device in hand instead of working only with the simulator.
I could only sweat the details on liquid glass, etc because I'm a daily iOS user.
Can you share some details of how you work? What models? What harness?
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.
I hate software engineering now.
sounds like your app is nothing serious
So you end up paying people on Fiverr to do it which costs more than 99€
That‘s how you check functionality but that’s not how you get the bugs in the code.
That’s like translating a text to another language without knowing the language
What do you think has more training data Python or Kotlin?
Some people on the cybersecurity side are starting to cry....
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.
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.
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".)
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.
[yes, this would also get rid of the previous generation of 1000-JS-lego vibers]
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.
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.
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.
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.
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.
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.
I don’t see any reason to think the same thing that happens with all tech won’t happen here.
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.
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.
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.
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 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.
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.
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.
That said, I do recommend reading the code the LLM produces whether you understand the language or not. What better time to learn?
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.
When you’re completely ignorant, there’s nothing to be afraid of.
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 still would feel scared operating an established product off a newly changed stack the team isn't familiar with though.
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.
Remember Chinese accounts on US Facebook say data centers are bad.
If you are blind, you cant see anything wrong, if you are deaf uou cant hear anything is wrong.
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.
[1] Epigrams in Programming:
https://engineering.yale.edu/academic-study/departments/comp...
Each time I get access to a new model, I do two things on all our active codebases:
- Security review of all the code and vulnerabilities (new models will find new stuff)
- Code review of test suite quality, and idiomatic patterns/code for the language of that codebase.
And in the case of swift and kotlin, it's even more important that an agent helps me with the code quality since I don't know what "idiomatic" swift or kotlin looks like, the way I do with JS, Elixir, C#, Ruby, etc.
LLMs made it way worse https://ashishb.net/tech/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.
/remind me in 6 years about this thread
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.
If React Native worked well for human programmers, wouldn't it be just as good for AI?
- stack A needs lots of tedious, not-quite boilerplate not-quite-copy-paste work whenever you implement something, but reduces cross-OS bugs, UX and accessibility issues down the line. Lots of dev frustration, slows down iteration (when humans actually have to do this).
- stack B has awesome DX and affords smooth operation of the design/UX/dev teams, very fast. More issues down the line, though. May be worth it if unaided humans need to work on it.
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.
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
And as for outdated dependencies, breaking changes, and unfriendly companies, the reason I ever got into RN was after trying to build an iOS app using SwiftUI (and then bailing to UIKit to no avail). Talk about a borked ecosystem.
The frameworks, developer tools, languages, and iteration speed of RN hands down beat any one platform, and you have one model for your data and state which is an unequivocal win. I agree it has plenty of warts, but the arc of progress is that they have been going down steadily.
If you're a 3k person developer team where 200ms can cost millions a year, then by all means go purely native. Though I bet if they'd just gone to the new architecture and spent 1/5 of the cost in agents optimizing things and building a few native bridges they'd have nicer apps and be shipping faster.
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.
> cause your business to really spend a lot of time shepherding the tech over the finish line
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.
The android shortfall is a real one but I also pushed for hiring native android developers too.
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"?
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.
Now it's a different situation as implementation has become incredibly cheap.
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
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.
yeah because they don't care about a top notch user experience.
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).
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
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)
What we found led us back to native.
That said, the massive downsides to native are:
- App Store Review time, this used to be hours to 1-2 days, now it can take a week or more
- In the same vein, you can do updates without waiting on native when using web technologies to build your app. We can go from a bug in the field to a fix in <1hr easy. Try doing that with a native app
- Cross-platform, yes LLMs mean you can create a native iOS and Android app but you have to keep those in sync to say nothing of web (if you want to offer a web app as well)
- Like the point above: Web, if you want to support web, why not get the other platform for cheaper (shared logic)
KMP can be seen as a token optimization at this point. Business logic is shared and doesn't have to be rewritten in Swift.
Yes, for a while they were doing very well and I even once had an app reviewed in <1hr but the average has been creeping up. LLM/Vibe coding is what is often blamed for this increase though at the end of the day it's Apple's problem/fault for not staffing the review department better.
I just ran an analysis of my apps and the fastest was 8hrs (June 20th) but since then it's been trending upwards with my last 3 updates coming in at 40hrs, 67hrs, and 98hrs. These are all my apps, the company I work for has at least 2 recent updates that took over a week. That's just absurd.
If the App Store can commit to 24hrs being the max time then maybe I'd be interested but for the foreseeable future I'll "Settle" for instant updates when I have a fix ready instead of waiting on Apple. Especially with how random approvals are (not just the time, the approval itself), I'll ship a tiny fix and App Review will kick it back for some native API I've been using since version 1 that they now want more info about. I don't fancy having my businesses at the whim of Apple Review.
Just this week I've had an app stay for 9 days in review and another one for 8 hours. Same dev account, same niche.
Edit: was going to update the earlier comment but just hit the 2 hr mark.
There are cons to targetting web/PWA too. Push notifications work but Safari on iOS only allows them if the user adds your website to their home screen. It also doesn't support prompting the user to install the PWA so you have to instruct your users to tap the Share button, tap View more, and then tap Add to Home Screen. And as soon as they tap the Share button the menu opens on top of your instructions so they need to remember the steps to continue. It's hard to defend this behavior because the user will still need to allow notification permission when they open your PWA from their home screen. It's an unnecessary hurdle.
Apple may not trumpet it as loudly, but these freebies are handed out in UIKit too, for cases where declarative UI is cumbersome.
Generally I've found that while SwiftUI is great for little self-contained bits of UI like table/collection view cells and simplistic template-like apps, it tends to become a bear with complex apps, so it's nice to have both options.
Throughout my career, I found that the faster I can go from wanting to try something to seeing it working, the better. Without that quick iteration cycle, I end up, not trying certain things or trying to batch all of my changes which then makes it harder to be sure what actually fixed it.
It's better to find out quickly if you can get traction rather than building something requiring more maintenance. For most bug fixes or enhancements, you make them in the Jumpstart Rails side and they should up instantly in the mobile apps without going through app review again! Most projects are not being built in companies the size of Shopify, so I caution anyone who wants to just get the project out there to use platforms that give them more leverage. And no, I'm still not a fan of low-code or no-code, because I know what it's like to have to maintain apps over many years.
Oh, and I still always warn clients to stay away from native mobile unless they absolutely need it, because even with AI, maintaining just a web app is still light years faster, and far more pleasant. I know from very, very, very recent experience that testing subscriptions is still annoyingly cumbersome in the flaky Apple and Google sandbox environments, and Stripe for web apps is night and day easier to test. Testing on mobile is better than it used to be, but sometimes when I'm waiting for builds onto a physical device or for confusing settings in App Store Connect or Google Play Console to take effect (or just fine where they've been moved to), I think about how a manager 20 years ago was telling me how slowly his development lifecycle was when he used to burn software onto ROM chips. So web is still the way to go, and native mobile only if you absolutely have to. And if you have tons of time or money, sure, start with plain native.
Edit: As a web developer for decades, I still find both Jumpstart iOS/Android and Flutter to be preferable to React Native.
The vastly undersold topic to all of these is how many developers do you have?
We have the option of using flutter, or not launching an app at all. The concept of going full native is a non-starter.
I basically could not care what Shopify is doing because they have hundreds or thousands of people.
What you could do with Kotlin/Swift you can do with React Native as well.
This just feels like internal factions wanting their own teams, and owning their respective politics, than a discussion on Merit.
In theory yes, in practice no. I mean, in theory you can do it in mips ASM and ship QEMU along with the app, in practice it makes no sense.
The problem with xplat is they add extra layer on top of platform native.
- React native and similar, add extra js runtime engine.
- Flutter and Kotlin MP add extra skia graphics engine.
- Skiptools add extra swift runtime
- Cordova adn similar add extra browser engine
- Etc
Also, any plans to open source Helix?
So it goes.
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.
They are like multiple companies in one: Square, Etsy, aspects of Stripe, aspects of Squarespace/Wordpress. Idk I can see why they have a lot of people.
They also have video and music streaming. And Kindle Unlimited.
Even if they gave you feedback I think you would have to take it with a pinch of salt.
Hiring decisions are more emotional than most people would admit.
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.
[0] I always thought the best answer was something like KMM to do all the backend comms and local data model in a shared way, and then a bespoke UI building on what that shared code exposed.
Hi. That’s me… not-great mobile app maker. And yes, I’m grateful that RN exists.
Mostly what it does is make sure that an Android version of things exist at all.
React Native's advantage of having a single source of truth for code hasn't quite gone away yet, imo.
Also, having agents trace and document every logic path to compare with another codebase works well in my experience. It can certainly do that better than me, i would give up and start taking shortcuts pretty early in a process like that.
link to project: https://github.com/skiptools/skip
[1] https://news.ycombinator.com/item?id=41384144 [2] https://news.ycombinator.com/item?id=46706906
Alternatively, point the model at your git repo for platform A, read the diffs since release X and implement the same changes on platform B?
Sure, you need a review to release native code changes, and you should probably get a review if you have big feature changes just for the sake of Apple not banning you. But in practice, it removes one of the biggest annoyances of developing for the App Store.
Changes are cheap and fast, so teams often feel less pressure to test everything thoroughly before a release. Which is a fair tradeoff. That’s part of the reason we can have dozens of releases a day on the web. Not just because we can, but because sometimes we have to.
With native, you know each release is harder to roll back, so you tend to build more tooling around releases, think through changes more carefully, and test more thoroughly before they’re ready to ship. You opt for one bigger, more stable release every few weeks instead.
At the end of the day, both approaches work.
Heh, now that I think about it, maybe web and cross-platform devs were the original vibe coders? Changes are cheap and fast. Just move fast and break stuff.
Native devs are the old-school ones. Shipping is expensive, so you better get it as right as possible.
Exactly this. After close to two decades building for the platform, the mindset is really to be cautious and make sure everything is rock solid before shipping.
This has more to do with building up a quality tool chain and testing process than being slow.
But sometimes there is a need to ship over the air updates, and for that (on Kotlin) there is Zipline [0] from Cashapp. I haven't used it in anger yet, but I know some people who do and trust it.
Also keep in mind Apple might penalize you for dodging the review process and shipping new features, etc.
(btw, one exception to the JIT rule is custom browsers for the EU)
App Review Guidelines §2.5.2 says: "Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps"
Technically Apple can punish you for anything but so far it seems to be accepted for small fixes and tweaks.
It’s a grey area for other parts of the code that are not mentioned in the text.
It’s grey for other parts of the code that are not mentioned in the text.
> 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.
Are you saying:
- webdevs are now able to write and review native code because of AI (who cares if they don't really understand it); or,
- Because developers are more productive we can cut the number of webdevs and hire native engineers – same no. engineers, same output, but now native apps.
Why not:
Continue using RN but now and just enjoy being more productive? If productivity was the reason to pick RN, then enjoy it. It's not a bug.
There's nothing remarkable about the skill set of either party; the appeal here is re-use of code. how the labor markets itself is irrelevant
I don't see a reason to use it over web stacks plus CapacitorJS (Or Tauri) or directly native for very large teams.
any engineering problem is just 'when' and 'how much' at that point
You tell me - what are their intentions? I wasn't really thinking of open models tbh
The other option is to just stay with ChatGPT and Anthropic and fire almost all of their employees, but then they're running the risk of having a significantly worse customer experience in case your development cycle gets out of hand. They'd have lost most of their internal knowledge in the layoffs so they'd be stuck.
If they don't do anything and just let their employees continue to work like they've always been but with LLMs to enhance productivity. Not to the point of implementing software factories, but as most people are using them in the industry. They lose nothing, gain productivity but their shareholders, investors and managers have been gaslit into believing if they're not 200x-ing their AI spending they're probably going to be left behind by competitors who are doing that.
Also some of their larger investors may have investments in other AI companies and they probably strong arm them into contracts with those companies to benefit their portfolio.
> working demo especially good trick: force big brain make something to actually work to talk about and code to look at that do thing, will help big brain see reality on ground more quickly
One of the best things about AI is that you can have a working prototype almost instantly, which is great for iterating quickly over ideas. But it means this trick simply doesn’t work anymore.
Not a new problem, of course - developers wrangling large amounts of code (more than they should or can) is a recurring challenge in the industry.
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.
It’s actually pretty common for a new company to start fully native (only iOS, few features, limited scope), then switch ro react native/electron (need to support more surfaces, features are being developed too quickly), then back to fully native (can afford individual dev teams for each platform).
Not always, but very often people in the past had good reason for what they did.
It is a very capable library, and when I first started using it the docs were more Oracle docs looking - but I could find what I wanted easily. Now, it is much more annoying to delve through but looks more modern.
See also: Chesterton's Fence
The post DOES give more information as to why they looked at switching from React Native to native Platform APIs.
React Native is forcing a major refactor of React Native apps in switching to the React Native "New Architecture" (see https://reactnative.dev/architecture/landing-page).
So if Shopify had to do major refactors of all their React Native apps, maybe they could look at what it would take to go back to native Platform APIs.
from https://shopify.engineering/shop-app-migration
For the Shop App, this coincided with our next major React Native investment: adopting the New Architecture. That work would have required us to revisit native module integrations, rendering, and the boundaries between shared and platform-specific code. Before committing to this investment, we tested whether coding agents could help us build directly in SwiftUI and Jetpack Compose while keeping product behavior aligned across platforms.
- startup time reduced: iOS by 23%, Android by 50%
- crashes - 10x reduction
- app size - iOS increased by 1MB (67MB -> 68MB), Android reduced by 109MB (37.2%)
- build time - Android release build time fell ~75%.
- runtime perf - Android builds could draw at 120fps while scrolling feed and switching screens
They're two different platforms where the capabilities and UI patterns differs, so I don't see why they should be in sync. The web platform is not in sync with them. And using native features can give you a nice boost in maintenance and speed, unlike React Native where you always needs to align library semantics.
Saying the web platform is not in sync with mobile is not a relevant metaphor to justify why Android and iOS should be considered separately.
I really wish they would not do that.
The best thing you can do to make your app trustworthy and friendly is to adhere to the host operating system UI guidelines and expectations.
Nobody wants your unique take on the checkbox or textarea please.
When you get to the point that your have a significant enough number of users across multiple platforms, generalizing everything into a shared UX doesn't make sense; giving those classes of users the best experience requires embracing their platform.
A simple example: Android has a system-wide convention for a `back` button. iOS has no such standard. Users on each platform have different expectations for how to navigate an app fundamentally, and holding tightly onto the concept of identical gives both camps a compromised experience.
I do think that the way the features are implemented should be platform dependent, i.e. use common UX pattern on each platform, fit in with the UI, and be good platform citizens.
Same as if I’m an Android user and you give me the conventional iOS experience.
It’s like if I gave a swing or Gtk+ or Xwindows app experience on Windows 11 or MacOS. It would be usable, but feel conspicuously sub-standard.
The Android back button is legacy.
I agree that most companies do that, but in my opinion that's not really all that important. Some drift between the iOS and Android apps should be expected and accepted.
Conway's law also plays a big part here and it's kind of TBD to see if agentic development will minify or magnify its effects
A lot of companies go to React Native, etc, because they want one single non-native design on both platforms.
Which IMO can be a mistake most of the time, especially from the POV of a user.
it is always the nerds (i’m a nerd, but also run a company and led teams before at a unicorn that IPOd) who obsess over things that normal people would probably not even come to given 100 years
case in point: even some of apples own apps don’t follow their design language.
also some of the most popular apps in the world like tiktok or x don’t use ios glass.
my bank app doesn’t use it and opts for a single theme across platforms.
and you know what? i don’t give a fuck. i just want my money transferred properly, my memes consumed on demand, and that’s about it.
Most likely this will work out fine, but big rewrites like this have a big enough chance of going off the rails that I wouldn't shout success from the rooftops just yet. I'm sure Digg engineering was proud of their rewrite too.
Is there any major browser now that doesn’t support saving websites as apps? Electron is simply a suboptimal and incorrect way of producing web apps.
I don't want to spend much time on this comment so I risk not making a sufficient point, but something I notice is that you're appraising the situation from a purely technical point of view. The technical component is just one piece of what makes a whole product. I think Apple is probably a good example: they regularly make decisions that bother the hell out of tech-centered minds.
Do they leave bad reviews if your app malfunctions due to the system webview behaving differently than the Chromium version you tested with?
Forget about saving websites as apps, no one does that. Not sure if it works on Desktop Safari, it certainly doesn't on iOS Safari. Not even persistent storage is offered for PWAs. Apple likes the billions in AppStore fees they rake in every quarter.
Electron is way bigger than an app needs to be, of course, but those giant apps that you hate, 250MB just for a health tracker? That's not electron being the problem.
Bruno consumes 300MB in RAM. The alternative I am using consumes 25 MB and it is much faster.
The difference is not because some uncompressed PNG or some fonts, it's the Electron architecture that is wasteful, by design.
And yes, not using electron will use less memory, which is an excellent reason to go "we're not using Electron". But there's a difference between "We want to use as little memory as possible" and "300MB of RAM on a system with 8 gigabytes of the stuff is a problem". The first is an excellent call. The second is nonsense =)
Space on disk, I have plenty. But the Electron version of many apps feels slow, sluggish, and it takes time to open, it takes time for every click to respond, it is the runtime cost what matters the most.
You say it is irrelevant? It makes a computer in 2026 feel just as fast as a computer from 2001, doing similar tasks, while the computer from 2026 is thousands of times faster.
And I definitely run more than one app at the same time.
This 300MB is the bare minimum used by these apps, in my example just an API tester. A simple "chat" app like Teams, Slack, or Discord wasting so many CPU cycles and so much memory is to me something that should feel like collective shame to our profession. Maybe that's why you disagree with me.
Haha. I completely replace the software with a non Electron alternative if available.
A one star review, on the other hand, can have a material impact on the search ranking and consequently my revenue.
You don't need to argue with me about it: I'm not the average user. But they really do not care at all in most cases.
They don't care, but they care about their computer being slow because of swapping. While they can't identify the cause and link it to the various Electron apps they're using (Teams, Slack,...) it's obvious for the tech-aware person they complain to.
At some level in your management chain there's someone who cares about selling more software above all else, and it's your job to do what they want.
I don't like it either, but I've fought against it for too long to my own detriment. I think ICs have a responsibility to deliver quality software regardless of external pressures, but there's only so much you have time to do.
Most apps won't need these capabilities to function, but they are there, for all purposes good and bad:
- background activities with fewer restrictions
- less restricted file system and sensor access etc
- ...
sure, many app use this for nefarious things.
But real use cases don't need to be sophisticated rendering algorithms or what not.
I think good streaming apps also use these capabilities, for example, for performance.
I don't think that's necessarily true. Nuance is a thing.
These tools are bad, objectively! They give inferior user experiences, and waste resources (ever more important now with RAM prices what they are).
But that doesn't mean I can't understand or even agree with a company for using them. Building the same native application for more than one platform is expensive and time-consuming. Most of the time I'm happy to prefer an app built with a cross-platform framework vs. not having one at all.
(To be fair, though, if there's a webapp, 90% of the time I'll prefer that over an Electron app. But nothing meets a well-built native app.)
You can say it’s objectively bad from a technical perspective, but clearly that’s only one part of the equation.
It's subjectively bad because it's an embarrassment. Like you're seriously going to tell me something like Discord, worth 15 BILLION, cannot afford native apps? Spare me.
Like yes, I'd prefer native and MS can certainly afford to take that path, but they can't even be bothered to make sure that most of their Electron apps land on the upper half of the quality spectrum.
Only if you don't compare it with any native or quasi native editors like Notepad++ or Sublime text. And Emacs has been cross-platform for decades.
Regardless, there are a bunch of new visual glitches in the release, with regressed performance all over the place.
But I still have to open a modal just because I dragged a meeting from one time to another. This version of Outlook is, slowly, getting better though.
That doesn't mean companies should necessarily avoid them. As a user, I always want the best possible user experience, but a company can't prioritize that above all else, and I know that.
Like, it's fine to criticize something, "this component doesn't follow the OS's UI guidelines" or "this scrollbar disappears when the mouse isn't over it which is a bad UX" or whatever, but this generic "oh this is bad but if it was rewritten it would be perfect" is annoying.
What you're seeing is people actually making that case instead of forcing it. They're saying that if the app wouldn't exist without this bad thing, then it is appropriate to compare using the bad thing to doing nothing.
You just seem to be demanding that people not mention other ways to do things, or you'll get angry.
I’d be very happy if companies didn’t artificially degrade their web version to force installation of an “app” that’s effectively a web browser in disguise.
Apps in 2026 deliver all the disadvantages of a plain ol' website (Requires an always-on WAN to have any function whatsoever, UI that doesn't meld with the OS in any way, no integration with things like Shortcuts...) but add huge real costs: Extra time before I can start using it, the hogging of easily 500-1000MB of disk space on day 1, a growing un-clearable cache, sluggish transitions with useless animations, and the need to be "updated" on a regular basis (whether used or not) wasting my time and bandwidth.
One of the few benefits to me as the user of a 'client application' has always been that a well-made app uses an API to speak to the server which is dramatically lower bandwidth than the modern BloatWeb with AdTech™ stack could ever match, which ought to enable the highest performance. But it seems like they rarely actually deliver that benefit.
We have LLMs.
It's easy to build native everything now without much resource expenditure.
Android will be Kotlin. iOS will be Swift. Desktop and server will be Rust. Web will be TypeScript / React for now, but maybe one day WASM.
LLMs are the target now.
- they follow instructions quite well.
- are tireless at doing mechanical ports between languages and frameworks.
- Can understand a new ecosystem quite well.
we'll know when the next layoffs hit.
Keep in mind, claudecode and the other coding agents were pretty bad until around Jan of this year (2026). So it's only been about 9 months since devs have had decent coding agents and even less time has elapsed since somewhat wide adoption.
Both have an enormous number of paying customers and you don't just disrupt that for a language change.
React -> Rust is ambitious and the models aren't there yet.
Soon.
Preference for a native feel, solid software, bugfree code, compile/develop velocity, LLM friendliness.
We're in a brand new world.
For an example that I actually have experience with, React very frequently gets criticized for being slow, heavy etc. React is not slow. I can make (have made) fast and snappy websites in react. React can render at more than 60fps if necessary, and if the code isn't shit. The fact that someone else has made a slow buggy mess with React does not prove that react is bad, it simply proves that the developers are bad. At this point, someone will typically interject with something along the lines of "but react makes it hard to make fast websites" and to that I simply say no it doesn't. I've seen what makes react apps slow, and it's generally just bad code. The developers who make shitty react apps would make equally shitty apps with any tool because they're the problem not the tool. They don't know how to build good software and literally no tool can help them because it's simply a matter of understanding programming and the sad fact is most developers suck at programming.
I graduated university with about 200 others and out of those people who have the same degree as I do, very few were even decent at programming. I know that because I was the guy who helped them complete their assignments and I was a TA in several different classes, and I'm telling you the overwhelming majority of students sucked at programming even after 2-3 years of studying it.
After graduating I've worked on many different web apps and other stuff, and I've seen an overwhelming trend of trash code and bad developers. The people who actually care about writing good software and have the mental facilities to do so are few and far between. And that's why most software sucks. A good developer can write good software using pretty much any of the popular tools. The tools are just different ways to do the same stuff. Sure there's some overhead with react etc but it's really not that significant, the significant part is all the trash code people put on top of it.
Sorry, that doesn't really come across as a ringing endorsement. React apps are typically not doing anything complex so rendering at less than 60fps should only happen if you're doing very computationally intensive things or writing bottom-quartile quality code.
I'm just saying they can render that fast. So if your app takes a second (or several) to render it's obviously not because react is slow, it's because the code is ass.
In most cases if a React app takes a long time to render a page it isn't really rendering that's taking time, it's a slow network call or multiple. So the app being slow has nothing to do with React at all, it's the backend code that's slow or it's the frontend code doing multiple consecutive requests or something like that.
All I'm saying is react is not the reason it's slow.
However, it's now the default for Multiplatform apps that are used constantly, including IDEs, chat apps, etc. They gobble up memory and cpu cycles and are constantly getting updates due to the shitshow that is the javascript dependancy ecosystem.
https://www.revenuecat.com/blog/engineering/why-react-native...
"First key learning: execution matters far more than stack choice"
which directly translates to: make a great app and nobody cares about the tech and this includes whether or not to use Liquid Glass.
They can be "bad" in some dimensions (as you mentioned) while being "good" in others (dev productivity).
These frameworks didn't become popular for no reason. They have value. The parts that are "good" can easily outweigh the parts that are "objectively bad" when they enable a smaller team to get things out the door they would have had trouble shipping otherwise.
In stories like this its much more likely that they just got sick of refactoring a big ugly code base so got buy in to throw it all away and starting over and the justification is native. Wait like 5 years and there will be a new react-native corss platform app because the native apps have too much cruft. Assuming we still have human in the loop then.
Sure, but thats not an interesting observation unless there is something about react-native that makes those apps consistently higher quality than native apps.
On the other hand, like-for-like C/C++/Rust performs better than javascript in terms of CPU and memory use, so the null hypothesis is that re-implementing would , in fact, improve things. There's little reason to think a priori that the end result would somehow be worse.
For companies the size of Shopify and Airbnb that makes sense. But that doesn’t mean a small ten person startup should do the same thing.
For a while it seemed that having deeply held, nuance-free opinions about technologies was a sign of being wise and experienced.
The slightly lighter version of this was having near-absolute convictions but leaving a tiny exception for extreme cases to try to demonstrate that you weren’t being unreasonable.
These would usually follow trends when something would spread like a meme. Recent examples include “Everyone should use SQLite for everything” and the ironically closely related “Just use PostgreSQL for everything”. The typical pseudo-nuance would be “unless you have FAANG scale” to imply that there is no nuance until your user base includes most of the developed world.
I try as hard as I can to have strong opinions, loosely held
this was every DBA in the late 90's and early 2000s when talking about their pet RDBMS. To me, it was a signal to avoid that person unless absolutely necessary.
"The right tool for the job" is too complicated for a lot of people to understand. Tradeoffs? Tradeoffs require understanding.
"XYZ is the best, just use it" is much easier, especially if you don't know how to make decisions and don't really care. Then you defend your non-decision by parroting what you read.
I remember a product manager talking crap about Kafka years ago, and I started digging in as to why he didn't like it, and all of his reasons were marketing FUD from competitors. It was odd, his understanding of it was a Potemkin village.
All tools presumably solve a problem. If you understand that envelope you can figure out if it works for you and your envelope.
I would have loved to see some performance benchmarks on some critical app flow.
Meanwhile the devs are furiously asking AI how to fix it, every flavor of every model will give you a different diagnosis, GH Copilot will throw a million high/critical at you, and you still have no idea if it's fixed or not.
It's the exact reason why you still need to know the languages you're using despite what leadership/product teams demand.
Its also funny how reality sometimes validates or punishes these loyalties, and that is reaching a fever pitch in the era of LLMs. Platforms that offer familiarity at the expense of complex or inefficient framework will naturally lose ground when familiarity is no longer at a premium. It is a good thing, all of the hard parts are a little easier and it is less tempting to take the shortcut that you know has a dead end somewhere.
I now avoid buying things from anyone who use the dreaded purple "shop" button.
I am still mourning pre-React GitHub. Maybe rose-tinted glasses, but it was so pleasant to use
For example https://diffs.com/ is built in React and it's basically instant.
If the entire page is rendered on the server, the information required to do so is presumably reasonably approximate (same datacenter). If most of the page is rendered on the client, the information needs to be pulled in from arbitrary physical distances.
At some point the engineering really is this simple.
"Oh no, we can't possibly do the computation of all that on our backend! Yikes! Let that run on every single client instead! Let users spend their own compute over and over."
culture.
https://diffshub.com/oven-sh/bun/pull/30412
Compare that to this:
https://github.com/oven-sh/bun/pull/30412/changes
I agree there are limitations bc of physics, but I don't think it explains this particular difference.
https://github.com/pierrecomputer/pierre/blob/main/packages/...
... albeit using React inspired terminology like props and hydration.
I think my point still stands that, if MSFT cared, it would be fast. The issue is not the technology choice in this case.
For example, look at their demo here: https://diffshub.com/oven-sh/bun/pull/30412
It's way faster than GitHub and you check the network tab.
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
"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.
Even if they were to write for two platforms, they'd likely want to have a whole bunch of business & state management logic that would be shared between the two with the native part being a thin platform layer.
It seems like a mostly shared codebase (reglardless of specific tech choice) would let them get precisely the end user UX they care about. Both for performance and capability.
Not saying they should use React Native but maintaining two large apps and using LLMs to keep them in sync seems far worse than many other options.
Sure, you can make it smaller, but how many companies actually do this?
Sure, you can make it faster, but how many companies actually do this? Accountants and product managers don't care about speed or size -- that's a user problem.
Judging by the app sizes I download (and try to avoid), few companies really care about the user experience as long as the basic feature is checked off.
I worked at a company that provided an unnecessary and heavy FE framework (original devs didn't know what they were doing and "just got it out there"). Most of the target audience used used older PCs, and thus slower and memory limited. Some pages required multiple GB of browser memory. We've had this problem for decades because devs usually have well spec'd computers.
I happen to work on a product that is built for accountants. You would not believe how slow these apps are and all they do is display forms!
I believe customers do care about performance even in these B2B industries.
But it feels like they sink into some form of learned helplessness. We were interviewing our customers to learn how to build a better PDF viewer for them. Their biggest complaint had about Adobe Acrobat? Too slow!
And yet most apps feels distinctly different than native.
> 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
That's the real killer feature
> Silos of bugs on native - When you go native you might encounter bugs which appear only on either platform.
This still very much happens with RN on anything bigger than a toy app
> 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.
Speaking of which, what is the iPhone Duo support situation of RN right 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.
The debate has been taking place on the actual street?
I'm currently maintaining versions for both iOS and Android.
I just want to correct this, because I agree with you but the framing is a misinterpretation of the goals of the Cordova project - goals which were ultimately met.
Companies (or their consulting agencies) had tons of webdevs - working on their company public and internal websites, but not many native smartphone devs. Those were the days when people who completed the Stanford iPhone programming course were snapped up lickety-split.
But everyone was clamouring to have their own smartphone app for all the smartphone platforms (well, iPhone, Android, maybe Blackberry)
Hiring enough smartphone devs to fill multiple smartphone-specific dev teams would be like trying to build multiple AI development workstation on the cheap these days.
In the late 2000s, people realized they could write an HTML/JS/CSS website and compile to an app for each J2ME/Blackberry/iPhone/Android platform that would "serve" the website. So their webdevs could be converted to smartphone app developers.
Hey, if you planned your website well, you could use the same business logic for your website AND your smartphone apps.
That was the elevator pitch.
You'd need an actual (maybe two) native smartphone devs for each platform to handle any areas where the marketing didn't meet reality 100%.
But that was doable versus hiring multiple native smartphone devs for each platform.
And in the late 2000s, there seemed to be a lot of potentially viable smartphone platforms - iPhone, Android, Blackberry, J2ME, Windows Phone, Palm's webOS. But we know now that in a few years, all but two would wither away.
Even with native APIs exposed via JavaScript, there were obvious problems with these webview apps. The apps were passable if the app didn't require much user interaction or computation.
Projects like React Native and others tried to reduce the amount of webview usage and increase the amount of native UI controls used.
The mobile platforms themselves aren't going to improve their platform-specific webview to make it easier for webdevs to mimic the "native" experience. Why would they?
Who wants to bet there still won't be a dark mode?
For a while I've been wondering why people are even bothering with high level languages if you aren't even gonna read the code.
I mean maybe there is some substance to the point that llm's have read substantially much more code and projects made in python and JS instead of rust or C++, but as they generalise and improve more and more, there is a case to go back to these languages for the pure speed and close to the metal ideology they have.
Most likely many wont do it because shipping faster and capturing market value makes more sense than optimization for a company like shopify(user probably wont appreciate going from 175ms to 20ms as much as new feature), and for those features the higher level lanugages have more training data in the models, but still interesting to think about.
There are more OS than just iOS, depending on the app a lot of shared logic has to be written only once with RN.
I mean, it's not impossible - I wrote a "coding agent" with GPT-3. It sucked balls. The idea was you write a Markdown spec file and the tool then compiled it to an equivalent source code one shotting it every time, but it hardly worked at all. The file changed too much every time and instruction following wasn't good enough, so it'd keep changing the interface exported by the file, and there were lots of bugs etc.
> Shopify has been using LLMs to build software since 2021
GitHub Copilot integrated into VS Code started becoming available that year. It’s definitely not a coding agent, but it was certainly LLM-assisted programming.
That said I did happen to work with a team in ‘21 - ‘22 that got access to an older coding model from OpenAI, also called Codex, through a corporate partnership. We also tested it out in an autocomplete UX. Our experience was rather hit-or-miss and I was a bit skeptical of AI-based coding at the time. That blog post above and others like it were an eye-opener and made me wonder if we were just “holding it wrong.”
Then ChatGPT was released. It was nowhere as good as the models today but it could write reams and reams of correct code and I realized the world had changed forever.
oh yeah, disclaimer: I write UI frameworks and dabble in PLs.
Is that something we should be engineering for right now?
Now this is somewhat problematic if someone wants to implement better fine grained reactive systems. And I posit that the next paradigm is going to be in that direction given what I've been working on (furthering current reactive systems which only go halfway).
The abstraction is huge advantage, especially when targeting different devices and screen sizes. We (and that includes Apple) have been learning the value of those kinds of abstraction boundaries for years, well before React.
It's also important to note that SwiftUI and UIKit are composable, so if some small part of your app needs low-level, finer grained control, then go ahead and use UIKit/Core Animation/Metal and SwiftUI for the rest.
Then you can only have islands of either paradigm within each other. UIKit and SwiftUI do indeed compose, albeit coarsely.
I can't blame them, they got influenced by react. Don't even blame react, it was a good attempt. Basically trying to build a UI from a snapshot of a tree. Except this is too simplistic a model. They designed it as if you could equate the number of games and the number of positions in chess. Like a markov chain. Except playing chess has side effects. A mere snapshot does not encode those.
I understand the mistake.
We have small shims for IOS or Android BLE. But otherwise the discussion of should you go native is really a discussion of how many employees do you have to throw with this?
I developed React native app for ios as side project and took breaks often and came back to have to do big updates with expo to make it work again. Maybe there is smoother process, but this was annoying
It also depends on features. Many apps don't rely on platform features (widgets, watch apps) and are essentially webviews, and those will continue to do just fine on RN.
[ 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 ]
> 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?
In recent Rails releases, system tests, or E2E tests, are no longer enabled by default. The short version is that they’re significantly slower and more brittle. Basecamp also removed most of their E2E tests.
I don’t know what Shopify does internally, but my guess is that they’ve taken some of those lessons and are trying to apply the same thinking to mobile development too.
https://guides.rubyonrails.org/testing.html?#when-to-use-sys...
I work in Rails too, I try to keep them to a minimum, but I definitely try to do at least one happy-path test of any major page (which includes automated accessibility audit), going without them at all seems insane to me.
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 Shop app, which is regularly at the top of the list in the shopping category in the app stores, is the first to be migrated. Assisted by AI, the team was able to go from a proof of concept to a fully rebuilt native app published in the app stores in just 12 weeks. We’ve written about this migration in depth here [0].
The migration of the Shopify app (our biggest with 300+ screens, home & lockscreen widgets, Apple Watch app, complications, Siri Shortcuts, etc.), is also underway and will ship later this year. The rest of our apps will be migrated soon."
[0] Migrating Shop app from React Native to native https://shopify.engineering/shop-app-migration
> 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.
At work, we use react native, and although the upgrades and stuff are painful, I'd never give up the ability to ship over the air updates.
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
2. AI will manually test code
They made a separate article on why, which they linked to. Performance is significantly better. The native Android app launches twice as fast for example
Don't get me wrong I don't have anything against AI, I'm a heavy user myself, but refactoring everything just for the sake of it and bragging on HN with little to no tangible effects - that's a whole different story.
And, in all honesty, the difficult part with many projects is the bootstrap, the scaffolding, not the continuous dev. Agentic dev. made this a piece of cake.
follow up with some more technical details and benchmarks
That was my thought when I saw the headline and then reading the article confirms this is the inflection point per their own words. Very interesting.
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
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.
This is non-starter math for small companies.
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
There's also a project to add a static JS compiler, but it's been in development hell for the last 3 years: https://github.com/facebook/hermes/tree/static_h
They increased the interpreter performance by quite a bit, but JITs are impossible on iOS, so it can never be fast.
We have a RN app that needs to do a lot of geometry processing and things like polyclip are unbearably slow, so we had to add native modules to accelerate them. The web version with a true JIT works just fine.
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.
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.
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
Plus now with iPhone Duo which has so much variation in layout, I don’t think React Native would work well for it.
Big win for security
I’m not aware of any attacks on native package managers in the past 5 years. The closest would be a poisoned Xcode build in China that wasn’t downloaded from Apple a while back.
Also getting an attack on one of the platforms means at least ~half your users are safe on the other one.
So that's good. One of my larger gripes with native Mac/iPhone dev was always needing to rely on a third-party package manager with all its quirks.
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.
LLMs change the tradeoff and organizations would be remiss to not reconsider previous decisions.
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.
Interestingly Apple approved it very quickly, which I was afraid of given such a huge rewrite.
I created a standardised bootstrap for all our projects here starting from the KMP wizard:
https://bitbucket.org/workingsoftware/kmpbootstrap/src/main/
The reason it the bootstrap has all platforms included is that adding in iOS, android and desktop after you have already created the project is a bit of a hassle compared with just always having the same structure even if you only want to use web.
Then you can easily add on native apps later if you like.
Looks like we're back to Uncle Bob! [1]
Then they say:
> We decided to switch from native to React Native in 2020 for three reasons:
> Stop building the same features twice
> Allow developers to work across the stack
> Spend less time chasing feature parity and more time shipping value
Totally!
Is there some kind of shame in just saying:
- we didn't want to hire more people
- we didn't want to pay those salaries
- we fired a lot of engineers with move to react native/hybrid in mind
- we could reuse the frontend devs (aka "full stack" folks) with or without some extra whippings ensuring they grok the bare minimum they'd need to build for mobile and test in on mobile.
The native apps will definitely be better in terms of performance and UX. However, having 2 codebases means twice the tokens.
Who has more people/resources to justifiably throw at their native app than Shopify? Maybe a dozen companies?
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.
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.
One other person in this place gets it: "fewer tokens, faster progress"
Electron, Tauri, React Native/Expo, Flutter (and countless others) are the wrong kind of abstractions, built for a time pre-AI, solving pre-AI problems
We need a new post-AI abstraction that embraces this opportunity!
That's why we're building SuperNative
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.
That's why I'm building SuperNative
It preferably come with superior guard rails, so strict static typing, borrow checker if not gc, perhaps ability to state proofs, etc.
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.
The most advanced in this area may well be websites and into those decades of work of thousands of engineers went (HTML, CSS and JS standards).
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.
And, honestly, the cost of tracking React over time has always been higher than the cost of tracking native deployment options, which move more slowly and usually with more care than React, where breaking backward compatibility is just another Tuesday. I don't think the promise of React Native being an almost-free "native" app actually pans out in reality. I've never maintained a large React Native app, but from following some apps that are, it seems like it introduces a sizable amount of technical debt that you pay over time. So, in exchange for worse software you also get worse maintenance costs.
In fact, I think Google's been saying this for 6-7 years already.
After the app mature enough company should decide to move native.
It sounds pretty solid, so I wouldn't expect anything to change in just 6 months.
> 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.
Hopefully they will write more about that in the future.
React popular -> llms get good at react -> llm generated apps default to react
So... local maxima?
“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.
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.
A ton more what? Money? AI costs are insignificant to a company like Spotify. Hell I've been using Astra fairly extensively at work and I've only racked up like $500 in the last month. Peanuts.
Hard pass on the PHP though!
Technologies are never the issue. The people is.
Odd banter. So did anybody using GitHub copilot which was in technical preview back then?
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
Maybe React Native isn't the right choice - but two tech stacks for virtually identical interfaces is dumb. Three stacks if you include browsers.
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.
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?)
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.
Code and optimization is going to be a niche moving forward
Companies can now just afford to maintain a hundred different native apps, rather than settle for a write once, run anywhere approach.
Quality is, was and always will be job one. There's obviously a place for AI tools (providing the economy doesn't melt), but can we please just slow down for a second and think about what we're actually doing?
It's not the layers that are the problem; they're the point.
It's the quality of those layers. React is just a poor abstraction layer
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:
And that's not even discussing the heresy of app stores. Curse smartphones for ever happening.
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.
Article is too long to summarise but basically they outgrew it tech- and org-wise.
Lack of vision?
Heck Microsoft wrote their own damn start menu in React native, and VS Code in Electron.
Their reasoning’s and opinions on anything are useless to compare to almost anyone.
We’re using Flutter successfully and love it. I don’t have 6 engineers to throw at Native, let alone 6000.
Sounds like a complete waste of tokens with the worst case of just quickly building more technical debt, three times.
One of the big rules is don't repeat yourself – much of the logic only needs to be written once (except UI)
Kotlin is already multi-platform and can be re-used as the business logic in iOS apps with Swift as the UI and the Android app with a Kotlin UI (Jetpack Compose) or both iOS and Android apps can be written entirely in Kotlin.
That vastly reduces the maintenance and Kotlin is reused across all apps and keeps it at 2 languages at most.
No need to introduce Rust to achieve the same goal.
Rust has a smaller library ecosystem, I'd say. Kotlin can use Java libraries on the server side, and on the client side on Android, and the ones needed on iOS are easy to convert to KMP - IntelliJ can do it semi-automatically. And KMP has the libraries that matter on mobile, for hardware access, animations and so on.
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.
Literally a Nazi. His best friend and the COO is the founder of the Canadian equivalent of Breitbart, and also, they hosted the store for Breitbart...
Nah, miss me with that clownshoes moron shit.
Grow up and join the real world anytime.
(Sure. “Nazi” is frequently used figuratively to mean “fascist”, but that's not “literally”. Except, perhaps, in the sense where literally is itself used figuratively as a intensifier for a figurative description, but at least not literally “literally”.)
You answered your own question