Numbers from GPT Astra
- Shopify has 3000 engineers as of 2026
- Google Chrome when released in 2008 conservatively had ~ 60 engineers.
- GTA 5 in its credits had 150 software engineers. Surprising even to me who has had many an experience of being in a bloated FAANG team, this 150 includes GTA Online!
In a sane society, Shopify’s opinion on anything engineering related would be thrown into rubbish because they seem to have managed to complicate a simple app into requiring thousands of engineers and now maybe millions in cloud spending to Frontier labs. This is unfortunately not an isolated case, Spotify for one has the same issue, idk what “engineering” Spotify is doing, it’s the worst app I’ve used in my life.
When Chrome 1.0 came out in 2008, it only ran on Windows, and it couldn't do basic things like print or export to PDF, didn't have any accessibility, didn't work in RTL languages, and didn't have any graphics acceleration, among other limitations. Don't get me wrong, it was a marvelous piece of engineering - but it was extremely incomplete. By the time it was what we think of as a modern, complete browser, they had many hundreds of engineers working on it.
Also, you're comparing the number of engineers working on one product, to the number of engineers working at Shopify across their entire company today, which includes far more than just one app.
You're entitled to your opinion that Shopify is a poor app or that it's overengineered, but clearly it's not simple. That's just a fact. If it looks like a simple app to you, that's because you're not seeing most of it.
It's like looking at the YouTube mobile app as someone who watches videos and saying that the app frontend looks simple. You're only seeing 5% of the app. The other 95% is for video creators and advertisers, and it is decidedly NOT simple. I think that's the same here.
Rubbish. Most of the stuff you’re listing is handled by OS and frameworks themselves, you don’t need hundreds of SE to handle RTL or a11y. I work in one of those companies, most people just regurgitate existing shit into another form of shit and collect salary (not complaining, as I’m one of them, but let’s be honest).
The original Edge had to switch over to Chromium because it was hard to build a compliant accessible browser from scratch and this is Microsoft we are talking about.
More seriously, it not just about building a compliant web browser engine, it is about tracking the dominant browser engine which introduces their own "standards" along the way too.
Microsoft could have easily continued to invest in maintaining their browser engine, but it would have to be comparable to what Google is doing, and yet they'd always be perceived as "behind" due to non-dominant position they have.
I'd say strategically they do not want to invest in tech that's not winning (in marketshare), so when they are not dominant, they'll instead adopt and extend (not just web browsers, look at WSL too).
We live in a time now where libraries are free and plentiful and pretty good. It is easy to forget that this was not the case for the vast majority of time that computers have existed.
Chrome’s original design definitely predates our current rich ecosystem. Plus, V8 and Chrome’s performance profile are demanding enough that there would be a pretty high bar for those dependencies anyway.
This is plain wrong. For a browser, a11y doesn't just get handled by the OS automatically. In general, claiming a11y is easy or will be done by someone else is bordering on evil.
Spotify has progressively gotten much worse over the last 15 years, all while the size of their engineering team has ballooned.
I am very unsurprised by this outcome.
People wonder why good software becomes bad, and it’s because the people who were good at engineering are often outmaneuvered by corporate-politics savvy people in a growing company. One of the best political moves in a company is to have a lot of people under you.
A couple years ago, an engineer I know who has always been a very poor performer and lacks initiative, but is friendly and non-confrontational, was hired by GitHub. It would not have been hard for GitHub to find a much better engineer, but this person would be an easy person to keep under a manager on a team who wouldn’t leave or make waves. That can be more important to some managers than skills.
Sometimes I wonder what the tech ecosystem would look like without the ZIRP era.
I look back over 15 years and with the exception of increased smart phone usage, everything else still looks mostly familiar. Maybe a bit more slick, but also slower and buggier despite having much better hardware.
There hasn't been a qualitative leap in software (as was in the 90s). Just larger SaaS companies. Without ZIRP would it have been any different?
I have the impression that for hiring this is fundamentally the most important aspect: Finding a prospect that is just skilled enough for the position without being a risk to the person who is hiring them.
When it comes to number of engineers, always keep in mind that it costs more engineers to maintain (and understand) software than the initial development push.
> One of the best political moves in a company is to have a lot of people under you.
This is why I’m sceptical of “AI will kill corporate jobs”. A big company has no profit sharing for successful departments. Everyone is trying to get budget to hire because it makes them feel important.
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?
You're comparing a company (Shopify) to an application (Google Chrome). A better comparison would be the number of engineers at Google (90,000 [1]) vs Shopify, or the number of developers actually working on the mobile application instead of any other area (website, backend database, internal systems and processes, infrastructure management and maintenance, etc.).
People who has not run software at scale have no idea what it takes to run it at scale. Google chrome is 60 engineers at launch but google same company has more than 100k engineers. Building first version was always easy and only gotten easy, scaling software was always hard and it is still hard.
I am quite curious about what people hat so much about Spotify. I made some excursions the last few years to competitors like Tidal and Apple Music but I just found myself coming back because the Spotify mobile app experience (and desktop) was just plain better.
It’s not that much about scalling software, as scalling software on highly concentered nodes. Distribution downstream can be its own hell, admittedly, but otherwise having fully independent copy of software copies that run in local terminal is a no-brainer if all that matter is running software at scale.
What are we talking about here - Spotify or Shopify ?
If Shopify - and you are concerned about their engineering teams, please consider that Shopify's revenue grew from roughly $205 million in 2015 to $11.56 billion in 2025, reflecting an explosive compound annual growth rate (CAGR) of over 45% across the past decade. Market validates !
I have nothing to add about Spotify - I use it to listen to music and it works well for me !
Shopify works well for me but it used to push nonsense like podcasts or audio books that I had no interest in, with no way for me to hide them. I just want to listen to music.
Upon looking just now, seems like they have been relegated to their own tabs now, which is great.
> GTA 5 in its credits had 150 software engineers. Surprising even to me who has had many an experience of being in a bloated FAANG team, this 150 includes GTA Online!
Just so it is said: my understanding is it's really easy to not end up on the credits list for games despite having worked on it. I don't know if contractors end up on there for example, at least beyond some team leads or the like. I don't know R*'s policies though, I've heard stories of people not being in credits because they, for example, changed jobs near the end of the development.
Video games are much easier than what Shopify do which will be a long tail of business cases and local permutations for all the countries they operate in.
Commercial software is usually a simple core and a long tail of business exceptions
Like comparing a climb and along run. Sure both require some physical abilities, but in the first case any error and the collapse mean dead end bringing progress to zero, while the second one you can rest on the side any time and still have the miles behind you accomplished.
In the corporate software world, especially anything to do with the web both front and back, most people really don’t know what they are doing. The goal is hiring/firing and agile.
Compare that to companies that release actual software products. The goal is product release at high enough quality. There are real performance and security targets to achieve.
Your typical corporate developer, on the other hand, does not have release targets. The actual goal is compatibility with the industry least common denominator expectations and retaining employment. This is why so many people are needed to do the work and why the result is so slow and bloated.
What's an "actual software product" and why don't you think web products count as them?
I'm a full stack web developer. I've worked for startups and F500 companies. There is always a push for release targets. The less technical the leadership, the stricter the release targets (its hard to sell a critical refactoring to management when they cant sell a shiny new feature or kpi to their own boss). We've kept our teams pretty lean too.
We still aim for high quality, and performance and security.
I do agree that many people dont really know what theyre doing and are kinda just winging it, especially with AI at the helm, and many companies are likely overstaffed, but I dont think theres a correlation between headcount and slow/bloated software. Any team of any size can make slow and bloated software.
If you are selling the code as the product, it could be said to be an “actual” software product, rather than a mechanism for selling other products, or software as a substrate for some other business.
Those other businesses aren’t any less valid, of course. They just aren’t software businesses. They are businesses that (quite sensibly) use software.
They'll be mostly involved with the parts that make money. I worked in a similar situation as one of about 5 people keeping the core infrastructure of the product working, meanwhile about 500 people optimized the ads
The site is currently running, yes. Don't forget it went down quite often immediately following the mass firing though. They seem to have fixed that.
There was certainly a ton of bloat to trim, but the haphazard "just pick 80% of the people and fire them" was incredibly stupid. Should have chosen whoever was producing the bloat, at least.
And now we learn they use Swift and Kotlin to replace React with. So they are not replacing it with Ruby. I think they've hit the limits on Ruby (like twitter had on Scala).
P.s.: I find Kotlin "an acceptable typed-Ruby" with an industrial strength VM (the JVM) and two compiles to native stories (KMP and GraalVM-native).
>what “engineering” Spotify is doing, it’s the worst app I’ve used in my life.
Engineering is app usability. Theres no other possible thing an engineer might do. Chrome ofc has infrastructure to distribute a binary. Spotify of course having a global content delivery network for terabytes of music. Hey GANG CAN WE WOKK OUT WHAT THESE ENGINEERS MIGHT BE DOING?????? WHY HASNT JIM STORAGE ENGINEER IMPLEMENTED A UI REFRESH YET!!!!
Shopify supports multiple countries both as a buyer/seller. I assume there is all kind of customizations needed to comply with each country weird rules. Are all of these software engineers doing core engineering? Probably not. But they are probably tagged as software engineers within the organization.
We did the same thing - had 90% of it overnight. Then spent a few days in the background tweaking for polish.
Our app is smaller, and has about 15-20 screens. I started at about 12:30am by giving codex a goal and it inventoried every screen based on the react native code, then created android and iOS directories, used maestro (I had already set up this tooling for a previous personal app build a few weeks prior), and had the whole thing working in android and iOS in the morning. Took it about 6 hours while I slept.
The app is way smaller, launches instantly, and the android app is (supposedly) native looking. I say supposedly because I don't use android phones. But it's using Jetpack Compose and Kotlin.
And I don't know Swift or Kotlin. I honestly don't see the point of React Native anymore. I know Expo is doing very cool agentic stuff, but I'm just not sure why I'd need any of it when I can write a native app.
We have people on the team that are android users. I just meant that I don't want to evaluate whether it feels "native" as I personally am not an Android user.
You just install it on your phone and use the app.
Maintainability concerns are entirely overblown by people who don't use agentic AI to develop large mobile apps, but anyway give their opinion as if they had that experience.
I put in a few hundred hours, and I reached the same conclusion as Shopify. With reviews from other models and then a manual QA pass the result is fully usable.
I work as a professional app developer. And I find this take to be naive.
Most of the time when I review code from AI, there is always something to improve.
It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.
The maintenance is not only the burden on the human and LLM. With too many moving parts, it becomes harder and harder to build and verify the correctness of future features. Yes you can write test for this and that, but it didn’t need to exist in the first place.
The second problem is correctness issues. Especially the edge cases. You cannot just manually test out a race condition on a phone! Sometimes it happens! Sometimes it doesn’t! If it leads to a visible signal like a crash, then yes, you can try to reproduce it. But there are a lot of these that are “silent” and would just lead to bad experiences.
We already had a software quality crisis! And I think such views only exacerbate the situation! Quality matters!
And this is not an anti-AI stance. I vibe code personal projects where I don’t even look at the code. But when I use AI as a professional engineer, I act like a professional. Because these products do have an impact on people’s lives.
All true (and thanks for posting a concrete example rather than "LLMS suck"). But my take is that none of this is much different than before times when I had teams of developers creating applications. They would often make similar mistakes which I would either need to catch or which would flush out in the field. Where it seems that LLMs are not excellent is where the person driving it is also the senior domain expert so can immediately spot pitfalls. But typically using humans to develop software this was really not often the case. Those people get promoted so they're no longer cutting the code. Under that scenario (replacing subordinate humans) I find the current models are either on-par or somewhat better (specifically because the models can also act like a peer senior dev, discussing approach options etc).
> It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.
I understand this, but I just can't bring myself to care. I've been doing professional software work for almost two decades. These sorts of improvements/time savers are great without AI. With AI? Whatever. It's fine.
When the underlying lib has an issue, it'll be quicker to debug with the whole thing in context.
You do realize that letting the LLM produce more output means that maintenance will be more expensive? I can easily see a world where claude and gpt are producing more tokens to sell you more tokens.
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.
Just the other day I burned through my 5h quota twice in a row because I had opus spawn a review session on a medium sized PR and I don't know what happened but I told it to summarize to me and it said it spent 100M tokens throughout 50 subagent sessions.
And more recently its been recommending that i install this new browser called Aside. I did, and it almost felt like I was installing malware so I Uninstalled it fairly quickly (it also was not a great browser)
So you don't use agentic AI to develop a large mobile app and you think my take is naive?
I also used to work full time as a Android developer for five years, and I'm pretty sure I know better than you about the quality of my app that I work on everyday.
Same result here just using plain Opus 4.8+. I had a web ap with a PWA approach. Now I have an iOS app written in Swift/SwiftUI and an Android app in Kotlin in the appstores. I do not know how to code a single line of Swift or Kotlin. You just test the app and iterate with the AI over it until it is stable and does what it should.
Are there cybersecurity concerns in the frontend? I would have thought you have to assume the client is untrusted and only do security work on the backend
My favourite is a logout button with a logout API that fails. (Not a huge pratical concern, I admit, because it's a local attack.) Nobody ever notices because it still shows the logout screen, which hides the API error toast (if errors were even displayed). The still valid refresh token stays in sessionStorage (or even localStorage) while the app displays "logged out". (Bonus points if you cleared the access token in the error handler but not the refresh token, and on page reload you ask the user to log in again despite having a valid token.)
Or a login form that gets hidden after login, but clears the username and password only when you click "login back in". (Bonus points if the backend also enforces a 5min session timeout "for security".)
Storing private secrets in your public client is easy to avoid for anyone halfway competent. We are all professionals here.
Turn on the secrets scan in GitLab, and put in your release checklist to have the AI audit the usage of secrets in your app, and this is basically guaranteed not to occur.
I doubt current models even make such a mistake in the first place, and particularly so if you use reviews at all.
WebViews are not an inherent problem, it's the system browser embedded in your app.
Where it gets tricky is if your use case involves authentication in the browser. Together with the authentication in your app this is the one area where you need to focus on security.
The case where a SDK update is needed to prevent weaknesses of the OS seems rather unlikely.
Doing anything right on web is 10x harder and more complex. The problem is the browser, once you use it to deliver anything you have to buy into all of it’s bullshit. CORS, XSS, headers, caching. All that just goes away (outside your backend API, if you even need one) when you ship a native app
If your clients are compromised then what's even the point of backend security. Users will login and do legitimate actions while their compromised client does whatever behind their back, while still looking normal. And the backend can't tell the difference.
This is the most naive take on security ever. For the backend, you assume your client is compromised, but you still don't want to allow your client to be compromised.
I have been getting these comments often here, including concerns about my non existent backend's security.
Last time, when I pointed out that the attack surface for mobile apps is typically very small, some users started to talk about zero day vulnerabilities in the OS's media handling, as if it was a concern for my app implementation.
You don’t believe how often people leave secrets in the app or use webviews and iframes badly, misconfigure OAuth in client side and so on. There are many issues where secure API does not help.
That's a recipe for regressions as the amount of surface you have to cover with "just...use the app" gets bigger and bigger.
You can write more automation to test it. But that's also how you end up with ever-growing test run times.
There are much better ways that aren't just "throw out the LLM" either. You just need to be more focused on throughput. Requiring manual validation can pretty rapidly require more hours than just sanity-checking code by hand, even (and I'm not advocating that for every use case, either.)
I can't afford manual QA passes if I'm gonna go as quickly as I want to.
No, they said they don't use android so don't know the native UX. You can test your app on the platform and confirm that the functionality all works, but how well it adheres to the platform's design language is subjective and hard to say if you aren't used to the platform.
I used the emulator - but just like I can use an iOS app for 30 seconds and tell you whether it feels native or not, I can't do the same for Android, since I'm not a daily user of Android phones.
And in the past, I didn't care because when I was manually building the app, I would just do my best with react native. But now that I can actually sweat the details (with the help of agents), I do want to hear from android users and use as many OS-native APIs and features.
Others on our team use Android phones. So when I said that we spent the next few days actually polishing it, that's where others came in, providing feedback when they used it.
I could only sweat the details on liquid glass, etc because I'm a daily iOS user.
I am using Gemini as well as Opus on a somewhat small project in React Native and I can not imagine this thing being able to build the whole thing on its own without it being a dumbpster fire.
Can you share some details of how you work? What models? What harness?
We use CC with Fable(Opus before that) continuously on a rather large project, everything is tested, we maintain high verified test coverage, we ship features x10 faster than when we started(pre Claude-everything era 2-3 years ago). I never worked with RN before and I ship features now. LLMs allowed us to find issues within RN itself, that thanks to some patches, improved lower end Android experience by a lot. We just use all the Claude defaults with claude.md that evolved over last year.
I use Codex and Claude Code desktop apps. I generally use only the SOTA, now Astra and Fable 5.1, Opus 5 when Fable runs out.
I don't know if Gemini is suitable.
I had few issues with my native iOS app, the results are just decent after a few iterations, the models do what I ask them to do. Where do you see the problem?
The LOC for my app is now at almost 200k + 110k lines of test code.
> Are there cybersecurity concerns in the frontend? I would have thought you have to assume the client is untrusted and only do security work on the backend.
This is wildly overblown. I've been working with agents for a good while, read tens of thousands of generated Python and the language factor is actually the part they get right that humans don't.
Seriously! What a bonkers thing to claim. "I had codex use maestro so I assume it made Android work well and idiomatically".
It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem, which makes me feel fear in my heart when I imagine the first "production is down" page coming in. I already hated mobile because it's so much harder to maintain than web (and I don't do any spyware or IAP so no benefits for me there); this yolo approach would give me constant dread.
It shows that at least some software development is moving away from code and to product management instead. I'm not passing judgement on that; I actually think that's great for a lot of software. It is interesting to see the shift happening though and will be fun to see if the general quality of software noticeably changes over the next few years.
> It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem,
As much as I dislike it, I think that's the future of _all_ non-critical software (think social media, crms, CI, food delivery etc). Leadership in many companies is explicitly asking employees to have multiple agents running through the day and that will lead to this.
Read this for example: https://www.uber.com/in/en/blog/efficient-software-factory/ . A very useful system, I am sure. But when you have AI at every layer from code to review to triaging, rest assured AI is the only know who knows your system. And you better hope it's not telling you that something is load bearing during an incident.
I answered elsewhere that I don’t personally use Android phones but we have people on our team that do. Which is why I don’t want to personally claim that it feels native.
But yes we are having real Android users test it.
So it’s quite the contrary. I care MORE what real users say. I can only guarantee that the app does things when I tap. So I’m not trusting the agent on UX, only on functionality. But whether it feels native, I am relying on those users in our team.
I wrote every single line of the react native app we ported, and maintained it for 9 years. So suffice to say, I'm familiar with the code.
But I am going to always prioritize the user experience over a developer (like myself)'s need for satisfaction to see code. And a pure native app is _always_ going to behave better than react native.
> And a pure native app is _always_ going to behave better than react native.
Maybe iOS is better about consistency, but I've used enough horribly made Android apps that I would not expect one that's vibe coded to behave better than a professionally made react native version.
You are familiar with the React Native code, you are not familiar with the Swift or Kotlin code, and likely nobody on your team is, since the AI wrote all of it for you.
Presumably a sarcastic post, but this is actually going to be how things are done soon. I had a box that OOMed and needed to be rebooted every few weeks. It was a disaster recovery standby box so figuring out what was going on never rose to the top of my priority list. So I asked Claude to dig into it (proxying the commands it wanted to run through me) and in an hour it had diagnosed the problem, fixed it, and taught me a bunch about memory usage in our system on modern kernels.
Not sarcastic. I have a moderately successful app and I haven’t once looked at the code (though I am capable, so far atleast). The only time I open Xcode is if I have to modify signing certificates. I did set up a slack workflow with a “fix it” button that basically tells Codex to fix the issue, run comprehensive tests, manually UI test for that particular issue with computer use and then deploy it.
It is. For my day job, I’m a software engineering director and I probably won’t have a job in under five years. For low to medium complexity apps, even Codex before Astra was capable of doing it completely by itself from scratch. For testing I would bring up the app after each atomic change and then manually try it out. I also use my own app heavily multiple times a day and I have found dozens of issues but I just ask Codex to fix it on the spot.
While I mostly agree with you, this is the kind of thing that might not have been done if the AI couldn't do the heavy lifting.
They had previously chosen React Native because it was easier for programmers to keep it updated, since it was really just 1 codebase. With AI, those same programmers can do the more difficult version, keeping the native apps updated separately.
So did it kill a job, or did it make it possible for the existing programmers to do it better?
It's the kind of thing that is really hard to determine in general, but here, it really does sound like they only made the change because it became possible with existing resources. They would not have done it otherwise.
That's an example of AI growing the sector that can lead to more jobs. Because suddenly a lot of tasks that weren't economically viable are now going to be in demand. Custom software for small businesses, platform specific optimized code instead of cross platform software, etc...
Of course it would. Supply and demand. Some companies would decide not to bother. Others would decide it was worthwhile. The limited pool of supply (app developers) would be distributed across demand.
I agree that AI is suppressing developer wage growth and taking real jobs. The opposite argument is being made elsewhere in the thread, and I think that argument is wrong.
>> Some companies would decide not to bother. Others would decide it was worthwhile.
The parent's point is that AI lowers the cost/benefit ratio drastically, by reducing the cost. So companies that would have shied away from projects like this pre-AI are now pulling the trigger without much hesitation.
And what a lot of people seem to miss is that with AI, there is going to be (already is?) orders of magnitude more software in this world. I'm sure a lot of jobs will be eliminated, but new jobs will be created as well. Hopefully enough to balance things out, but we'll see.
Just like this has made Web devs into Mobile devs, so could Mobile devs leverage AI to work in Web shops.
I'm not an optimist but there could be an increase of available apps being created which would still keep people employed. Theoretically the cost of creating an iOS app for a company without an engineering team dropped from several hundreds of thousand to a few thousand or hundreds, which could be paid out to a freelancer with AI. More people would go into freelancing for industries which were not contemplated before due to cost.
This is an incredibly boring task. Nothing new, just rewrite everything to just see it all rewritten again in 1 year. Perfect for LLMs and something humans shouldn't do.
While I agree with that statement -- that is also a lot of jobs. We have a lot of humans -- not every single developer sits in the innovation seat. The fewer the jobs available the less employable humans.
I think that rewrite - if AI enabled - owes its thanks to the legion of individuals who put their code up on the internet in the first place.
We all want super exciting jobs. But plenty have boring jobs like this. Between not having a job or having a boring job that pays well, the choice is obvious for many of us.
This is just not true. In the olden times (pre-claude) devs were constantly asking to do full rewrites of legacy code. This kind of project is exactly the kind of work I've trained for and have loved to do for the last 15 years as a mobile dev.
This app has 15/20 screens, an app this small wouldn't employ many people to begin with. Before there was one guy (op) maintaining it in react native and now he maintains it native. I don't see much change tbh.
Previous company I worked for would have (and did) hire dedicated swift/java mobile developers to build and maintain ios and android native versions (largely porting functionality from an existing web application)
What's more likely (as others have said) is that the other thousand companies that can't afford to have dedicated staff would've just used React Native. So no jobs were lost, they weren't there in the first place. The places that have dedicated Swift/Java devs can now be more ambitious in what they build.
Really? I’ve worked with plenty of companies that had separate native iOS & Android teams. I don’t know any that use a compatibility layer. Unless by compatibility layer, you mean a web view.
React native is an obstacle compared to what clear Swift/Kotlin code may produce. Swift is very powerful and Kotlin, in all honesty, is the first reasonable and very useful thing to come to the JRE ecosystem (save for Scala, which is, well, quite complex still).
Myself turned some python code to Swift, and keep doing so, without trouble or pressure. Of course, I've been doing fair amount of systems programming for 20 years now, so not sure what to advice newcomers. But this approach to dev DOES work for me very well.
Sounds like the advice to newcomers is to not worry about trying to learn a programming language. There already is an llm to program for you, and do it better than you could, so just learn how to talk.
So now you have two vibe coded applications you don’t understand. I’m not an advocate of making “job security” decisions but this definitely goes to red flag territory. Was it your job to maintain the RN codebase or do you have other functions there as well? I’m not sure I would keep a native noob on a vibed native codebase. What is your take?
People routinely decompile and recompose existing binaries, and if you use "obfuscation" in your app it's still a small bump.
In today's age, IP is no longer a tangible concept that gives any advantages in software. What differentiates two businesses isn't their IP, it's their relationships and their moat.
Most vendors that had protected proprietary IP are now irrelevant within their vertical. What saves them are the protection provided by patents, which is public.
Isn't ZDR only the case if you "opt out" through a setting? Lots of opportunities to make a mistake here, or for the LLM provider to play games. You could be unaware of the setting. The provider could reset the setting upon subscription lapse/renewal, application update, model release, etc. A developer could accidentally use their personal subscription (w/ setting on) on a work codebase.
Also what's the timing on this setting's effectiveness? What if before you knew to "opt out" you used the agent for a refactor and your entire repo got sucked up in inference? But then you opt out the next day? Is it too late?
The mistakes you describe are only possible if the company doesn’t really think there’s proprietary IP in the codebase.
If a company really believed there’s valuable IP in code, there would at a minimum, ban laptops or ban code on laptops[0], provide and maintain a centrally managed LLM gateway[1] that handles authentication, billing and model choice, have MDM to prevent you from using your own Claude login, etc.
[0]: For example when I worked at Google, the proprietary google3 codebase cannot exist on laptops because there are no tools to download it to your laptop.
I'd wager many software startups out there would consider their code valuable IP (even if in the AI era it's not), and don't have these types of IT controls in place. Startups I worked at gave you an email account, github access to their private repos, and that was that.
Heck, you don't even need to mix up a personal and business AI subscription. For the vast majority of folks one day their IDE "updated" and a bunch of AI features suddenly became available. Free, no sub needed. A dev starts using them (because, why not?) and lo and behold the company's code got shipped out in an inference call and is now scheduled to be in the next training run. Oops.
You are merely describing companies that aspire to consider their code valuable IP, not companies that actually do so.
IDE updated? It’s the company IT’s job to perform testing before distributing those updates. And also their job to use whatever managed settings to disable those unmanaged AI features.
How's that any different from, say, Windows updating and backing up the company's code to OneDrive?
Actions speak louder than words. If the company doesn't even supply and require work devices, they don't effectively consider their code to be valuable IP.
That’s the case with a personal subscription directly with OpenAI or Anthropic, but enterprise customers are opt-in, AFAIK.
And there are solutions around it from other providers and model routers. OpenRouter lets you explicitly say on a per-request basis you don’t want to be routed to a provider that trains on your input, for example.
Definitely agree. Most developers could build a basic Twitter or Facebook clone. The hard part is getting the users, content, and relationships that make the product worth coming back to.
True, but shops are exposing everything to Claude or Open AI. It's akin to outsourcing all manufacturing to subcontractors in China. That was cheaper, but extremely short-sighted. Now so many products have cheap Chinese knock-offs that are nearly the same as the originals because the subcontractors made both.
I think probably GPT 5.5, or 5.6 Sol - it was ~ 2 months ago.
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.
Yes uniffi created swift and kotlin bindings. The app I did with this is just a sudoku game https://www.puzzlesight.com . Before AI I would have reached for something like Flutter to avoid doing all work twice but with AI doing two apps makes more sense.
Okay, makes sense, the whole thing looks and screams vibe coded. On a beefy machine, navigating between your website pages takes 2-3 seconds. So still a long way to go with AI.
Next up, designing an even higher level language which will be used by LLMs to compile to high level languages like kotlin or swift. Just store instructions for LLMs in repos.
That Shopify employs 3,000 engineers is astounding.
I was rejected after a fairly basic ML interview at Shopify and when I asked for feedback I was told someday I could become a machine learning engineer.
I don’t think the interviewer read my resume or understood my responses as this was after working for several years in ML roles - staff applied ML and scientist.
Why is it astounding? They have one of the biggest e-commerce applications in the world. A mobile app for shoppers. A payment system and mobile wallet app. A shipment tracking system. Tax and small business software. They have their own lending arm with its own software. They have multiple frameworks for other development teams to make super customizable e-commerce sites. They support Remix and Tailwind among other software. They have brick and mortar POS systems.
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.
I think Amazon is very much on another level in terms of scale. Not trying to be negative about Shopify — they have a very large system to maintain - but Amazon is just on another level.
My 2 cents on this as a fellow RN dev & contributor.
- The performance gains in native compared to RN (new architecture) are minimal for normal UIs (except games)
- The most valuable feature which RN have is OTA updates, this has been a game changer for us and many fast moving companies. Ability to release and iterate at light speed. On native you are on the mercy of the app stores for review.
- Silos of bugs on native > When you go native you might encounter bugs which appear only on either platform.
- The project management of native teams is not always in sync - The teams often drift apart bevy iOS team might need 2 weeks just to make the app compatible with the new iPhone Fold (Duo) or Android team might encountered a blocker. Keeping them in sync for new features is really hard.
As an iOS Engineer that has been fighting the battle against every C-level type who brings up the subject of a shared codebase my whole career, I feel very validated.
Not sure why someone would say it was a wrong decision. Why would they even need to do this if LLMs make coding easier. They are likely chasing the things I advocate for: direct access to latest APIs from each platform, platform specific UI, UI that behaves correctly on each platform without chasing down edge case solutions (also said as ui that looks and feels "right"), and a bonus of separate developer pool to hire from that knows the ins and outs of the platform without needing to hire a developer to know all three- react, iOS, and Android.
> Not sure why someone would say it was a wrong decision.
Writing almost anything with javascript sucks ass to begin with. Writing native code with it is even more painful. Most javascript engines don't even have any decent model of parallelism. It takes zero imagination to see the problem here
The problem with everything being single threaded isn't so much that you want to do a lot of parallel processing, but that you don't want to have the occasional fat loop cause the whole engine to start stuttering. If you want butter smooth scrolling while there's (for example) a lot of dynamic content moving around, you want very precise control of the threading so you can get the gnarly stuff done without causing hitches that don't feel right.
The browser, iOS, and Android all use a main thread separate from the thread responsible for scrolling animations.
However, I think it's true that controlling threading in order to perform gnarly work in a separate thread is more ergonomic on mobile than in JS/React.
You'd need to create a Promise that wraps a Web Worker, which would be an unusual thing to use. I don't think most apps need such control over threading in the browser.
Why would they need to worry about hiring for specific skills at all? As AI progresses, isn't the only skill that matters that you can drive it effectively (which encompasses testing and review) without needing oversight?
Shopify is moving its mobile apps from React Native back to native Swift and Kotlin. With the main cost of native gone, the benefits of staying close to platform APIs and first-party tooling win out. This has been my ethos. That native is better than shared.
Your argument was you've argued your whole career for native. The article argues only very recently the cost equation has changed. Your argument reads like you are not taking into account the broader context or the passage of time.
I'll put it this way, my argument was pro native. And in the context of the article, if a large company had unlimited resources, they would choose native. I'm not discussing the business case for it, but the end result of it being the better option. It can be seen as "Shopify tried Reactive Native and left it behind the second they could after sinking resources into it for 6 years".
Time and progress have overtaken them. At the time they were likely correct but I certainly wouldn’t bother with react native any more when the LLMs have gotten so good
My argument is that platform specific codebases is the right course of action. My point is that consumers can tell, the product is better, and developers are happier working on native codebases.
You're looking at it from iOS side only, and for a US company that would be the last platform they'd ever drop.
It was a different picture out of the Apple garden, when a company only brings their next major feature to iOS because they couldn't be bothered to hire the same headcount on two development teams and their CEO uses an iPhone anyway.
We had that discussion about a decade ago with a company rep that didn't realize 70% of their EU users were on Android yet their play store app didn't have the feature they were planning to promote.
Basically, better was the enemy of good for most companies.
Correct, I advocated for the solution that produced the best outcome for user experience, code and architecture simplicity, and prevented having to rewrite an app in the future in native. Which has been validated here.
The android shortfall is a real one but I also pushed for hiring native android developers too.
We'll have to wait and see if the extra maintenance / bugs / attack surface is justified. This an announcement of future direction so vindicated is certainly premature.
If you weren't arguing against the business case, what were you arguing with the C-level types about? I don't think I have ever heard a case for react that wasn't centered around shared codebases mean fewer resources/cost/time to deliver a feature.
> developers are happier working on native codebases.
Agents are happier working on any codebase, but ultimately Shopify and other companies want iOS native app level quality without the huge cost of hiring many native iOS / Android devs.
LLMs and Agents deliver on getting a native app out at lower cost, higher quality, faster all at once.
I think everyone is trying to tell you your skills as an iOS native dev have been commoditised and Shopify and others don't need to hire anymore native devs to find this out.
I don't see how your job being completely commoditised and cannibalised by LLMs replacing your job is some how vindication?
This is just like saying "we won the argument", but what did you actually "win"?
Yea, I hear that. I'm content with winning the argument and truthfully, I think they will find they need to hire iOS engineers because we do more than write Swift. There are whole ecosystems of knowledge to go from a product idea, sit in meetings with many stakeholders, and implement the actual thing everyone wants. All they got here was a 1-to-1 implementation of their current app which was born of engineers working through real constraints. It says nothing of new features that have to play nice with other pillars of the company.
Not sure why you are defining my vindication. Its purely rooted in native is the better solution for mobile apps. Which they are using. Not sure how that makes it the opposite.
FWIW, the native app specialists are in some sense the most invalidated here. Shopify decided they couldn't afford your skill set and didn't change their mind until you could be replaced with an LLM.
Really the whole concept of technology specialization is the thing in jeopardy. It no longer appears to work to make a career out of deeply learning something obscure. Agent-farming generalists appear to be the ones who own the future right now (if, heh, not the agents themselves).
My validation is that platform specific codebases is what is the right course of action. The c-level decision is that they want the cheapest route to consumers. My point is that consumers can tell, the product is better, and developers are happier working on native codebases.
I'd challenge you to determine which of the top app store(s) apps are react native vs not -- plenty of app store awards have gone to react native apps -- bad software is bad software. plenty of you ios devs write shit software. I've done this job almost 40 years and no language or platform has ever prevented people from building shitty software or for that matter gotten in the way of writing good software. good engineers can figure it out.
source: ios dev since it was possible -- I am not even pro react native, I am just pro merit based arguments -- you aren't making any
Challenge not accepted but deferred to the article where one of the largest business wants to sit at the intersection of native apis without a a middle layer for the sake of saving money. Put another way, given unlimited resources, native wins out over shared.
Same here. Glad I stuck with native iOS development. I still haven’t switched to SwiftUI though (except for some small stuff). Still sticking with UIKit here.
I agree w/ advising people to move off React Native, though I think the story that "LLM enabled an otherwise too-expensive migration to consider" is not correct.
I say this because I was part of a migration from a mid-size React Native app to a Swift/Kotlin native app redo. I did the majority of the technical work on it. The majority of the work occurred before January 2026 and without LLM code assistance, though later features in the app definitely used some.
For anyone considering this, I'd say that the migration is definitely worth considering without even taking LLM assistance into consideration. The continued React Native tax of unnecessarily difficult upgrades, impedance mismatch w/ underlying core frameworks, and incredibly uneven library quality just cause your business to really spend a lot of time shepherding the tech over the finish line. It's pretty wonderful to be back in the world of "build, compile, ship, be sure". One thing as a fundamental principle that I think the Shopify article 'gets' at, is the importance of the feedback cycle - investing time in our integration test story very early on both helped w/ my cycle times, and later in providing guardrails for LLM assistance.
All to say that this decision is worth considering without even taking LLM assistance into account.
> The continued React Native tax of unnecessarily difficult upgrades,
My very first experience of RN was having to update an app to handle the mandatory change to 64 bit APKs
Which required a massive update not only to several dependencies but also xcode, iOS frameworks, the weird objective C caches that get smuggled into node_modules, _as well as_ all the rigmarole or making the 64 bit APK build work
I experienced the same issues but went the other way and migrated from React Native to React. Still one codebase but none of the issues. Performance was better too even though half the code stayed the same.
We don’t hold on to a decision just because it was successful at the time. When a core assumption changes, we’re willing to go back and ask whether it’s still the right call. LLMs changed one of the core assumptions behind our 2020 decision, so we reevaluated our mobile stack from first principles.
Thanks Mustafa! This was a great article—I'm curious, did you consider the non-technical / organizational costs in keeping the two codebases in sync as a separate factor? Do you foresee more organizational overhead as part of this decision? How are you planning to manage that? E.g. small implementation difference between the iOS and Android app increasing the support burden or bug burden and causing duplicated team effort.
Perhaps. I can absolutely see that being more attractive especially with things like the Duo where, I assume, SwiftUI gives you a number of things "for free".
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)
Your assumptions are very outdated. App Store review times are typically < 24 hours and have been for the last couple of years. And KMP makes cross-platform a real thing now, rather than hacking a web view into a native shell, which was always the worst possible user experience.
I'm afraid you are the one out of date here. App Store Review times have ballooned in the last few months. Marco Arment talked about this publically (on the ATP podcast) about how his app was stuck in review for over 2 weeks IIRC and I've seen 2 days as the minimum review time in the last few months with some taking a week or more.
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.
This is only anecdotal, but I had a review on a brand new app turned around in ~6 hours 2 days ago. A lot of it has always been luck of the draw, though, granted.
I agree it's anecdotal but that's all I have to go off and global averages don't help me at all. The problem it's a complete crap-shoot. You have no way of knowing if you are going to get a quick turnaround or a long one, it has zero bearing on if it's a new app or update or the size of the update, it's completely random. I cannot plan around random which is why I've opted for web-tech-based apps (Capacitor) with OTA updates so I can get fixes out just as quick as I could get webapp updates out.
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.
Yes, that's fair. I'd argue, though, that the training required to get your team up and running should be fairly minimal - Kotlin is a very easy language to pick up, especially for people coming from TS - and will pay off dividends in the medium to long term.
You get all of those, to some extent, if you use React Native. You still need to do reviews for significant changes due to app store rules but you can OTA update most changes without waiting on a review. Even web support is there.
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.
> I can absolutely see that being more attractive especially with things like the Duo where, I assume, SwiftUI gives you a number of things "for free".
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.
I'm sorry but that data does not at all square with my experience. I'm seeing 2 days+ as the average and I haven't seen sub-24hrs in months. I oversee ~20 apps and I can tell you iOS review times have been trending upwards for the last few months.
Apologies, I used to use appreviewtimes .com [dead], which scraped tweets and was pretty accurate, but is dead now. I posted what seemed to be a decent replacement, but will take your word it’s not.
Edit: was going to update the earlier comment but just hit the 2 hr mark.
For all I know it is accurate for them but I encourage you to hover on the bars and see the min/max. That's where the issue is. I wrote more about it here [0] but the TL;DR is that it's wildly inconsistent, sometimes it can take a few hours or <12 hours and sometimes it can take a couple days. It's impossible to plan around and nothing drives me crazier than having a fix written but waiting for Apple to get around to reviewing it.
Definitely makes sense for a large org with massive resources (such as Shopify) to do this. But for everyone here pondering what to use for their startup or a smaller project, there are still important trade-offs. In the past few years I've launched multiple cross-platform Flutter apps and multiple native iOS and Android apps using Jumpstart iOS and Android (native templates from the GoRails guys which leverage web views from your Jumpstart Rails server). The latter gave me web, iOS and Android out of the box and was vastly less costly to build, even with AI. For entrepreneurs who like Ruby on Rails, Jumpstart is my favorite for launching rapidly, and since the mobile apps are easy-to-modify iOS and Android projects, it's designed so you can either add more custom Hotwire Native Bridge Components or just write Swift and Kotlin to replace functionality with native code. Eventually you could write away all of the Jumpstart webview stuff, but you'd only do that if you had more runway, like if you have plenty of time or you start making lots of money. I've worked for clients whose ideas failed--not because of my code, of course. :)
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.
I’m surprised we aren’t seeing it more already. LLMs suddenly make it reasonable to maintain multiple native apps. I’d love to see this start to supplant Electron and its ilk on the desktop.
Any education required for engineers to switch to native or the agents are handling the details on their own? Wondering if architecture or the new languages require ramp up.
They created a mess in 2020 and hopped on over to a job at FAANG and now a fresh batch of Waterloo graduates want to do the same - maintaining somebody else's turds is beneath a Waterloo graduate on his way to becoming a manager who never touches code ever again :)
Yeah. No way we’re getting the full story. It probably goes something like this… we lost native engineers when we switched to React then we lost the engineers that were supporting react recently and won’t be replacing them because stock market. Therefore we’ll switch back to native and go with under skilled engineers using llms. This will work until we have a code base model collapse
It seems like Shopify has fallen into a trap thinking that more complexity costs nothing because of AI. In the age of AI we have to embrace the same principle as before that complexity needs to be tamed, not multiplied. Even as humans struggled with complexity, from what I see now AI struggles very much the same. Hence I don't think this will age well.
Another scary thing is with AI it's easy to let complexity get out of hand to the point where a human manually writing code is basically impossible. Even though AI might seem capable of handling the complexity, you'll start noticing all these weird bugs pop up all over your codebase.
Models have gotten a lot better at generating native iOS apps. The main appeal of RN was being able to leverage your web devs for mobile dev. that's what I did at my last company. And it's fine for a startup, but eventually you want dedicated native engineers bc each platform really deserves its own technical masters who can optimize for it.
But now that all code is generated, there's little upside to having an RN app... just start native. Your devs are barely going to be writing code anyway.
Nobody is talking about the real advantage of RN: Being able to release to the App Store without having to go through a review. That's so massive. Getting a bug fix out to users instantly, sneaking in optimizations, etc..
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.
I’ve worked with both native and cross-platform. I think the mentality of being able to make changes quickly without much review often comes from cross-platform, especially when the developers come from a web background.
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.
> "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.
Totally depends on your business model too. We have clients that often require quick changes for compliance reasons, and they need to ensure all users of our apps are congruently updated. That’s not easy without OTA.
It can download Javascript (or other interpreted language, or config data), but you generally can't download and execute new compiled native code on iOS, due to iOS code-signing/executable-memory restrictions.
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)
Pardon my ignorance but can't an iOS app host a WASM runtime without being a browser? And if so it doesn't need to be an interpreted language necessarily.
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.
Sure you can choose not to adopt React’s reactive paradigm and manage state directly but using JavaScript. My understanding was that in RN, JavaScript code manipulates C++ objects in the C++ part of RN, which then calls host platform code to create views and render.
Precisely. That has always been prohibited both by technical measures and by the App Store review guidelines. Especially on Apple, but also on Google Play / Android as well.
This is true in a very real sense – models can help you build native apps very quickly, no question. But how do you keep them from drifting apart from one another as you add/change features or design? Right now, there isn't much tooling for this.
React Native's advantage of having a single source of truth for code hasn't quite gone away yet, imo.
You create a source of truth which defines all the features and requirements. This can be UI tests, MD files, database, diagrams, whatever that fits your use case.
I've only read about it from it showing up on hn[1][2], but you can use slick to convert your swiftui to jetpack compose for a andriod build from the ios source of truth
i think you would have your coding agent work on both code bases at the same time. You could also task with generating identical tests for each platform. It's easier for a model to keep up with that kind of tedium than a human. Plus you can just tell the model to keep re-doing things until you're happy and it won't quit.
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.
the problem is that single-source advantage gradually falls away as you develop your software into something that feels good to use on each platform. and once you have a quality product you're left with perfunctory coupling that makes it harder to adopt the latest platform features
But the screens should look different, right? That's the point of building separate iOS vs. Android versions is to make each version "native" to its platform. The feature-set should be the same, but the interfaces can diverge.
You always still needed a specialist per-platform even if most of the code was RN or KMM[0]. But I agree - a thousand not-great mobile apps sprang from this idea.
[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.
> The main appeal of RN was being able to leverage your web devs for mobile dev.
> 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.
If you put every company that needs/has an app on a spectrum, there is a line somewhere that roughly divides them into two groups: where Electron/React Native/etc. makes sense or not. It's just a normal engineering decision: solving problems given limited resources. Companies have different problems and different resources.
I think people in the tech community have probably also noticed that it's rather popular to have an absolute opinion on the goodness or badness of these tools. There's some magical thinking borne from ignorance that everyone just ought to go native or that React Native is the best thing ever to be used everywhere or that AI makes this line disappear entirely.
I think these takes serve little value and distract from what’s interesting, and what the subtitle to this article says: that this line is moving due to AI. And I think that’s probably right.
And the “makes sense or not” part can change based on a bunch of factors.
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).
The main cost of two engineering teams shipping identical products in my opinion isn't the cost of those extra engineers, it is in the product and organizational challenges of keeping those two products that need to be identical in sync. I am very bullish on coding agents but would be wary of this turning into a mess.
But here's the thing, across operating systems the products should not be identical.
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 took "identical" as in feature wise. The user should be able to accomplish the same things, no matter what platform they're using.
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.
The solution is to make the common features a part of a statically-linked library that you can pull into your apps. A web app is, IMO, never the answer when you want to address multiple audiences. It is bad for accessibility (because 99.999 percent of web app developers never consider accessibility) and it doesn't solve the problem that web apps are trying to solve (having 8 code bases all that have to remain in sync) because you will inevitably need your code to handle platform-specific differences, standards/conventions and whatnot.
I don't know iOS so I can't say, but a good UX does depend in part on platform expectations and every system historically been different. The compromises mean the each have good reason for what they do (sometimes anyway), but switching is hard.
There is an implication here that the back button is a microcosm that represents the differences holistically but it's not. It's a small one-off exception that doesn't even affect the design choices made for the various apps. As I open up app over app on my Android (Audible, Spotify, ChatGPT, etc.), they all have clear in-app "back" functionality where needed. No apps I have installed rely on the Android back button exclusively. Also, none of these apps have any design elements that follow Android's design language.
The back button works at its best when it closes an app and it restores the one that opened the previous one. There could be no in app back button to do that. However the back button used to be an always available hardware button or a touch one on the bottom bezel. It's optionally visible now (I'm on an old Android phone so I'm not up to date with the latest OS) or a gesture, right? So app designers must design as if it does not exist.
> keeping those two products that need to be identical in sync
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.
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.
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.
The result of that native platform APIs side project involving six devs converting the app's major user workflows?
- 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
> it is in the product and organizational challenges of keeping those two products that need to be identical in sync.
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.
The capabilities of Android and iOS don't meaningfully differ for the purposes of Shopify; Shopify doesn't need LIDAR. Most large brands throw the UI design patterns of the platforms out the window in favor of their own UI guidelines.
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.
They vary in terms of architectural patterns and ui widgets. RN tries to prevent a single interface, but you quickly reach the point where it becomes a pain. You can use Expo to help, but their libraries are unstable.
Yeah, massive parts of our community and ecosystem miss that something can be right today, and wrong tomorrow, and having to change along with your users and needs is OK. You'll never be able to anticipate what the business needs in the future, so stop pretending your software design can be done once and then just coast on that, because that's typically not how a software project should be run long-term or even medium-term.
The problem with tomorrow is sunk costs. There are many places I wish we had made a difference decision in the past - but we need to balance that with cost to make changes when what we have works okay.
There's also a recency bias, where you ignore how valuable some decision was in the past and ignore the fact that you maybe wouldn't even get to the place you are if "you made a different decision in the past".
I can't count how many times I've said "this is really bad, I it is worth rewriting to fix all the issues", only to discover that there were good reasons for all the past decisions and so we end up with the same mess as before - except that now I know what it must be that way.
Not always, but very often people in the past had good reason for what they did.
Those are the comments that should persist in the code. I hate when the AI edits and removes my "why" comments. I want the refactor to make it less messy but keep why it's that kind of mess.
I just put a comment in yesterday for this very reason - there was a flag I had set to false, and then looking at the library docs for something else thought maybe it should be true but that doesn't work how I would have implemented it if I had created the library and written the docs how I 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.
In my experience it comes from the business and people who think if we need to touch the same code twice in the same month it is somehow a moral failing of some kind.
> 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.
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.)
I think you contradicted yourself. If a tool provides better value for the time spent for a company, I don’t understand how you can call it objectively bad.
You can say it’s objectively bad from a technical perspective, but clearly that’s only one part of the equation.
I think they were speaking as a user. These tools create inferior products. (Still not technically objective, but true nonetheless.)
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.
I am so tired of existing react/electron applications being compared against imaginary, hypothetical "native" applications.
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.
It's always the preference of people defending bad decisions to compare them to doing nothing.
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.
The app not existing would unironically be better in so many instances, though. The web version doesn’t take up 1GB of disk space, install persistent services, send you push notifications by default, and it’s trivial to block ads in comparison.
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.
Hard agree. Day by day, I become more exhausted with "apps" as they are currently delivered, with native being slightly better than cross-plaform, but not good.
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.
Yup. Now we have a choice of either using a terrible website with popovers and cookie bars (never remembering the choices) or apps that have insane onboarding, and bombard you with ads through notifications, with zero benefit.
I'm not the OP, but my understanding (and I agree) is that it can seem like a better value when a subset of factors are considered (ones that IT can measure, biases in IT against Apple etc.) and it leads the company into making a choice that is worse for them overall.
It's objectively bad because of how hot my phone is.
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.
What really grinds my gears is Microsoft replacing native apps with Electron. Trillion dollar company who is so cash strapped they have no choice but to punt to the easy development path.
The thing that makes Microsoft's case particularly annoying is that they have demonstrated how they can develop half-decent Electron apps with VS Code, but have simply elected not to with anything that's not VS Code.
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.
Also they bloated it to death. VSCodium gets you the same solid core app without the oodles and oodles of useless "features" Microsoft has bolted to it.
Turns out I was mistaken. Outlook was rewritten for Webview, not Electron. So still took a native application and turned it into web nonsense, but I got the specifics wrong.
Regardless, there are a bunch of new visual glitches in the release, with regressed performance all over the place.
What's extra egregious there is I do understand the logic because developing for Windows is such a fucking nightmare, that they're also responsible for.
Nuance is always a thing. Native apps are faster and better most of the time. Electron and React Native wouldn't annoy me so much if they were used with small apps where it's not worth over-optimizing.
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.
I would rather have the opposite? I don't want 10 people making small apps that use Electron. I would rather that be used for bigger apps where the overhead is negligible.
> These tools are bad, objectively! They give inferior user experiences, and waste resources (ever more important now with RAM prices what they are).
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.
I don't have any actual experience with React Native and Electron, but with that caveat out of the way I personally think tools get far too much blame that should be on developers.
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.
> React can render at more than 60fps if necessary, and if the code isn't shit.
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.
Yeah, obviously your average React app has no need to render anywhere near that frequently. The ones I've worked on will generally only render as a response to user action, server event or polling.
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.
FYI I've been building an app, Android first, and discovered the magic of Kotlin Multiplatform. The LLM modularized everything so that it's substantively the same code base, but with Swift only where it's needed. Still working through it, but it seems like a great and underrated platform to build on.
This is one of those “oh gosh” posts at first glance, then you actually think about it, and it’s 100% correct. Python, Node exist to save the precious commodity of developer time. Once that’s no longer precious, best value comes from purified custom Rust, no attack surface from huge libraries, optimized performance for the specific task on all possible hardware.
Windows desktop native is WinUI 3 and Windows App SDK, for better or for worse. No amount of Rust and tokens will recreate everything you get out of the box with that stack. Native needs to feel native.
The last time Windows UI felt native was maybe Windows XP. Maaayyybe 7, if we are generous. It also has to do with sluggish or no feedback by UI widgets, due to the trend of flat everywhere.
not sure why you're getting downvoted. but if you're building even very popular applications, it is quite easy to see how LLMs are very well suited for this type of consistency job.
- they follow instructions quite well.
- are tireless at doing mechanical ports between languages and frameworks.
Then why aren't people doing that? Microsoft has as much access to cheap tokens as any software company around, right, so you'd think they would be leading the way.
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.
I didn't downvote but I'd expect downvotes for a completely unnuanced thought terminating cliche that ignores everything in the thread. AI fanaticism doesn't help but lots of people don't get downvoted for that alone.
A well built native app can still serve as a vector for harvesting personal data in ways you cannot control. A web app is inherently superior because of its security envelope.
A badly made native app is worse than a well built react-native app. There are plenty of anti-patterns that will ruin your native app.
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.
> A badly made native app is worse than a well built react-native app. There are plenty of anti-patterns that will ruin your native app.
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.
> 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.
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.
> For a while it seemed that having deeply held, nuance-free opinions about technologies was a sign of being wise and experienced
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.
Using cross-platform web technology is absolutely a nuanced engineering decision that is the right one for many businesses. What is categorically bad is bundling a standalone browser runtime for every single service, wasting user’s storage and memory when you could just have a website in a browser.
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.
That decision is easy: do users leave bad reviews for bundling a few hundred MB of Chromium?
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.
> Much of Hacker News seems to be incapable of understanding the average user doesn't care about memory use at all, beyond a few extreme examples.
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.
That's true, but greater efficiency isn't going to sell more software if the users don't know they need it.
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.
It's funny how folks can't even get that number right. Depending on how much you care to optimize, Electron adds 50 to 80 MB to your application. Those multi hundreds of megabyte apps? Yeah that's not because of electron, that's things like "we couldn't be bothered to actually think about the assets we bundled in". 100 uncompressed 16 bit PNG? Sure why not. 20MB worth of fonts because we don't like the built in ones and no we've never heard of subsetting? Let's go. 50MB worth of .json data files that we couldn't be bothered to gzip first? Who's going to notice!
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.
First off, RAM is not app size, and second, the point of having RAM is literally so it's there to be used. Sure, Chrome is absolute nonsense, but Electron is not Chrome, and an Electron app using 300 MB in memory where data needs to be uncompressed and directly accessible when your computer (including your phone) has gigabytes of the stuff to work with is just... irrelevant? That's pretty much pretending there's a problem for the sake of wanting a problem.
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.
Sure, cross-platform frameworks were great. I do think LLMs are changing the game, however. If you have a robust set of tests, it's much easier to maintain native versions of an app, compared to the past.
Apart from the hassle that OSes put in the way of PWAs (intentionally, but that's another topic), a local Node app simply has a different kind of system access compared to a web app.
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.
Is everyone wrong, or is there more to it than you can see from where you stand?
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.
These takes are also a bit premature. Wait until the new apps have rolled out and users are happy.
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.
There’s risk to doing anything. There’s risk to doing nothing. A bit off topic but my perception is that organizations bias towards doing something more often than they should.
Absolute opinions are simple and travel better on media.
"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 think this is something we’ll see AI very meaningfully impact — the threshold needed for “Get this thing working on a tech stack we might not be familiar with” has gone waaaaaaay down.
It's worrying to say the least. Today it's "get this working", tomorrow it's "can it also do XYZ?", next week it's "we have a 40% spike in crashes, you MUST resolve this IMMEDIATELY!"
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.
Yeah. It’s also far too tempting and far too easy to keep adding features if you don’t make yourself disciplined about it (which is okay if you’re in a position to control that, not so good if it’s the higher-ups demanding it).
I first learned about the shopify app when I saw a purple "shop" checkout button. Next, I got an email saying that if I wanted to track my package I needed to download an app. No thank you. I don't want your app on my phone. I don't want to browse other stores in the shop app. I want to see my package and its status without enjoying a new "social shopping experience" or whatever.
I now avoid buying things from anyone who use the dreaded purple "shop" button.
I've been trying to minimise the number of apps I have. Every app needs to be justified in that I actually need it, and there is simply no way it could have been provided as a website.
Never bought anything that used Shopify and never will. As a Canadian, Lutke is just a pathetic individual and I simply refuse to use anything he touches if I can avoid it.
And I'm just sitting here looking at the Codex desktop mac app wondering why a list, a chat window and textbox require a 579 MB download (compressed) and 4 GB of RAM.
If 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.
Which is also, or at least has also been a culture thing, because of the
"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."
Is it? I looked at the source but it doesn't appear to be react. It has a React API but also a "vanilla js" API and when I looked at the code it seems to be doing everything by hand:
A multi-billon dollar company dropping quarters (performance/ux) to pick up pennies (development savings from not maintaining a native app) never made mathematical sense to me.
[ aside: Meta founded the development of RN and they don't even strictly use it; plus, any troubles/hacks they need, they can make to the Framework itself ]
Sorry not sorry RN was always the wrong choice, and I've made my money shipping React since 2013. Every RN project I've had to join has been a junk show and there is no way they operate more efficiently than 2 native teams. Don't even start me on Expo. Kotlin and Swift are nice, and ObjC/Java are still approachable IDK why people act like native is a big ask. I see people are in their feels already but I'm so glad so see Shopify stop carrying the RN banner, this makes giving the right advice to my clients easier.
So, instead of paying humans twice for the same thing, Shopify will pay corporations to burn the planet a little bit more, waste water and energy - to build the same thing twice. Just because. There's no tech reason to do it. "LLMS are better now". There's no low level optimisations, no blockers, no app shortcomings, it's a shopping app for Christ sake.
Instead of optimising, creating more with less, they will create the same with more.
Yeah, that's smart.
Super smart.
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
Ridiculous, the amount of energy saved from a faster native application over how ever many million users will be far greater than the amount spent to generate the tokens to do so
Yeah, with iOS for example, you typically need very little third party dependencies for functionality. The main ones are things like analytics, crash reports, etc
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.
It's a developer decision. But I'd say it's easier to not use dependencies on native because there are more capable system API. I don't use any in my iOS apps, and only one dependency in 20 macOS apps.
I was excited to hear some details about how LLMs are changing big companies' workflows. This is a fairly straightforward problem and good on them for discussing it. My first gut reaction is that there is no way I would let LLMs write a significant amount of my codebase. And then I remembered that not invented here (NIH) is a problem I have. If I let it decide what code I ship, I am making the same mistake as writing all my code from scratch. When I find myself worrying about alignment, that is what rigorous computer security policy is for. If it's not catching serious bugs written by LLMs it's not catching bugs written by people. Treating my own code as if it was written by someone else is just another part of computer programming.
I'm sitting here at my desk overlooking Cordova Street. The street that Apache Cordova is named after. I've seen this debate for almost two decades now.
Teams jump on the latest cross-platform framework assuming that it will reduce headcount cost at the expense of having a lowest-common denominator app on each platform.
The latter is true but the former is false.
What ends up happening is that teams start as 20 iOS engineers & 20 Android engineers. They adopt something like React Native. Then you end up with a team of 20 product engineers and 20 tooling and framework engineers.
I've seen that countless times in the last two decades.
> I'm sitting here at my desk overlooking Cordova Street. The street that Apache Cordova is named after. I've seen this debate for almost two decades now.
The debate has been taking place on the actual street?
That wasn't the starting point for the webview app DX.
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?
I've dumped all cross-platform frameworks as well. I tried many of them but they just weren't good enough, even for simple stuff. There were always glitches and teething problems that marred the overall quality compared to the native version.
I'm currently maintaining versions for both iOS and Android.
How do you stay motivated to do this?! I've tried to start my app in React Native multiple times, but it always sucks, so I finally started learning Swift. I'm already not sure how I'll stay motivated to learn Kotlin too, and rebuild the whole app again.
I can see the case for shared core libraries and then platform native views. This is best done in one programming language. Can Swift, Rust or .NET work here?
Yes, native .NET without MAUI is great for that. I have my app running with MvvmCross and two native UIs on iOS and Android since 2018, with hundreds of thousands of installs.
Yes, though its worth noting the goal of Cordova was to not exist. In the eyes of the project the web itself is the cross-platform solution but at the time Browser progress was stagnant and Cordova helped move things forward by offering device functionality using open web standards. Cordova was never intended to be a "cross-platform productivity multiplier". The north star of the Cordova project was for browsers to get the device functionality that native platforms offered, such as geo-location, accelerometer, contacts, camera, etc.
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.
This is probably the end now. People don't debate anymore whether they should write only in assembly vs. in C. Sometimes new abstractions emerge and they replace something completely. This time the abstraction was LLM.
AI dramatically reduces the cost of writing code (especially when you have a reference), so the scale between native and cross-platform is going to tilt more towards native now compared to before.
But I'm curious what their update will be in a year or two. Because these costs don't reduce as dramatically with AI (unless you fully give up control and vibe code it):
Before I even opened the article I knew the reason was because LLMs don't need abstractions. React Native was always about making app construction easier for people who don't want to learn ObjC or Swift. If you're not writing or even reviewing the code yourself, this is unneeded overhead.
For a while I've been wondering why people are even bothering with high level languages if you aren't even gonna read the code.
I agree as well. To the point i have a feeling that maybe after some time people will just start writing bigger programs which were in these high level languages like swift, java etc in Rust or C++(except for the potential memory risks).
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.
Bragging about "using agents to code pre-GPT" is quite the corporate flex... weren't they notoriously bad back then? Might as well say, "We've been doing spreadsheets with quantum computing since 2016"
I would not say they were bad, mostly just primitive compared to what we have today. I can only presume they are talking about GitHub Copilot which was released before ChatGPT. I believe at the time it was little more than “spicy autocomplete.” Yet it could be surprisingly capable, e.g. I recall this blog, also pre-ChatGPT: https://medium.com/data-science/github-copilot-crushes-data-...
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.
I'm skeptical. Pre-ChatGPT the models didn't understand tool calls or file editing so you couldn't really do targeted edits. So I really am not sure what they mean by this.
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.
The GP misquoted the article. They actually wrote:
> 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.
I use Shopify app every day, multiple times a day to run my business and it has always been buggy and inconsistent for me on Android, and I don't expect this will make it any better, especially with more AI in the mix, but we shall see.
Who wants to bet there still won't be a dark mode?
I'm not totally following the part about the simulator(s), probably because I haven't actually done mobile development before.
> When simulator interaction is needed, the CLI can connect to them via a remote mode and drive the UI via commands without having to inspect the layout or the accessibility tree. This enables blazing-fast performance and E2E tests.
I think I'm not following. Don't you still need to test the accessibility tree and layout in the actual layer the user will interact with?
I have done some iOS development and still couldn't follow what the article was saying about the simulator. I'm actually quite interested in it, because (in my experience at least) verifying that the UI works as expected is quite painful with current LLMs and the developer tools available.
They talk about building a CLI and keeping business logic isolated, ok fine, but do they still run the simulator and take screenshots to verify their work?!
indeed it's not totally clear to me if they do or not, my question too! OK, good to know it's not just something I was confused about because of lack of context!
It’s a reasonable tradeoff. Shopify uses Rails, and there’s been a long history of discussion around E2E testing in the Rails community.
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.
On theweb, not surprised that Rails switched from kind of encouraging people to use as many browser-automated tests (under whatever name) as possible , to trying to discourage people from using any. Rails way really likes being absolutist.
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 remember their blog post claiming how much of a win it was to move over to react native and maintain high performance. They even listed their performance metrics. At that time I was a mobile developer for an e-commerce business and the metrics they were proud to share were unacceptable on our native apps. Here they are coming full circle
That would be a huge mistake if we expect many more hardware and OS running them efficiently than just iOS and Android.
Best is to have an IR.
Now maybe that IR can be turnt into native code. But we shouldn't be constrained.
As an incoming framework author, SwiftUI is problematic for instance because it has a programming model which is dated.
And I don't particularly enjoy the language either. Looked fine at first and then got more complex than I feel is needed.
oh yeah, disclaimer: I write UI frameworks and dabble in PLs.
It is virtual dom like.
We don't have access to a stable underlying element like we would with plain UIKit.
You can build declarative models without this virtualdomness. But SwiftUI was created during the react boom so they went with the Zeitgeist, understandably.
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).
This is such a clueless take, and I see it surprisingly often. Declarative UI does not inherently mean virtual DOM nor does it "automatically" mean slower than UIKit.
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.
Yes, declarative UI is just an abstraction of imperative code. :)
The rest is properties of the internal implementation.
The VDOM way obfuscates the internals more. Doesn't let you control rendering appropriately.
It is so because the diffing and reconciliation algorithm have to be able to remove any subtree of views/nodes from the UI tree.
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.
Just like any engineering and business decision, this is a tradeoff.
I probably don't see things from the same vantage point.
Can't help but notice a trend however. What if this accelerates, especially with AI being an enabler?
I think it'll become a trend at larger, well-capitalized companies and startups, but not universally. The article mentions hundreds of engineers have worked on Shopify's RN apps, so they're well positioned to maintain two native codebases with agents and practically infinite token spend. Migration will be a harder sell for resource-constrained businesses.
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.
Can React Native become a sort of Compiler which compiles to natives (Android/Apple) now that AI can help in that direction as well? I don't know much about mobile ecosystem though.
LOL, flutter/dart are pretty awesome and we have yet to encounter something that needed improvement.
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?
It's interesting that they don't mention Kotlin Multiplatform or any sort of shared core logic between their iOS and Android apps. Seems like maybe the apps are fully independent codebases but with shared specifications and tests? They say that agents:
> Dramatically reduced the cost of maintaining parity between platforms through shared specifications, tests, and review checkpoints
I've used Kotlin Multiplatform on a mobile project built back before AI coding took off, and it was super nice to have shared core logic between the apps and there weren't really any downsides on the Android side, but on the iOS side it was definitely an extra layer that didn't feel fully native.
Speaking personally, JVM toolchain bits like Gradle being involved is a turnoff and has kept me away from KMP. Last I checked support wasn't really there yet, but I'd much rather go the other direction and use Swift Package Manager and the associated toolchain on Android.
I work on an open source app that uses a shared swift core for the iOS and android apps and I think it's awesome. I think having all your business logic in swift is great.
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.
In the age of LLMs, I get why you would dump portablity in favour of close-to-the-metal Swift and Javascript codebases. However I don't really understand the need for Kotlin- surely thats just an unnecessary complication and performance hit?
Java can still be used but it's no longer the recommended choice for Android apps. For any new Android apps nowadays you start with Kotlin and Jetpack compose (made by Google).
In fact, I think Google's been saying this for 6-7 years already.
Kotlin compiles to the same JVM bytecode that Java itself does. There is no performance hit. And from a developer's perspective, no it is not a "complication", Kotlin is a much more pleasant and efficient language to program in than Java (in my opinion, and that of many others).
Wish they explained more. Even though I'm mostly native iOS its seems react native is better stack for AI and iteration (hot refresh etc) - the main reason pretty much all AI vibecoding app were implemented via expo/react native.
I also believed that finally this year react native got mature enough with improved tooling and performance to the point that it started to being 'boring' technology.
There's a section linking to a more in depth article:
"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."
Yesterday, just before bedtime, I pointed Astra at our Electron Desktop app, and asked it to write me a native Swift app for iOS.
The electron app has 750 unit tests and 50 something integration tests. It also had access to the electron app via mcp and could click around and inspect it. I also gave Astra read only access to the backend code.
It worked for 3 hours and delivered a nearly feature complete port. Today, I found in manual testing 3 bugs and 1 performance issue, all of which it fixed afterwards. To fix the performance issue , it made several different builds and profiled them with Xcode.
At around 12:30 I had a full native app port of our product on my iPhone and iPad and could show it to my crew. It even did portrait and landscape correctl!
Needless to say, that I was flabbergasted. On one hand, I love it , I can build now all those cool stuff, but on the other hand, its a complete devaluation of my craft. I kinda tell myself that I was still the one setting up a proper env for it and that not everyone can do it. but thats coping. Freaking coping… and I know it
Truth is the Shopify app is simple enough to get right by a model. Lots of things hare simpler to get right in native code, so it is to be reiterated - a lot of interpreter code/libs is going down the drain, along with the devs that write it. These are not needed anymore.
And, in all honesty, the difficult part with many projects is the bootstrap, the scaffolding, not the continuous dev. Agentic dev. made this a piece of cake.
I agree with this but not just React, React-Native. There's many libraries I no longer have a need for. I've made several JS 3d apps just asking the LLM to write the 3D code from scratch. AFAICT they usually shed 2meg of library and run 1.5x to 3x faster as the LLM will do the optimal thing for the situation.
The most interesting part to me here was the whole helix thing + how they split business logic and UI just so AI agents could drive/test state via a CLI. I hope they do a deeper blog post on just that. I’m surprised they are making “decouple state from UI” sound like something groundbreaking when that’s kind of been the foundation for any sane/testable app for a LONG time.
The promise of React Native was easing development burden from the web app to the native app. It makes sense if they are just using coding agents to cut out the framework and just go native.
That was my thought when I saw the headline and then reading the article confirms this is the inflection point per their own words. Very interesting.
I'm an user; I have zero or near zero development and programming knowledge, so this take of mine might be complete nonsense.
But I think this is perhaps one of the first AI developments I actually like. Transitioning an app from React Native or any web technology to native code has the distinct advantage that the native version should be much more economical in its use of resources.
I'm tired of hearing about RAM and other components hiking their prices while at the same time RAM sizes of ~8 GB are considered too small because things like Electron apps are wasteful in their consumption of resources. Now, with more native apps, we might get full circle: leaner apps thanks to agentic development. Maybe someday 8 GB of RAM could be considered enough once again. Truly interesting.
Yep. First time I "wrote" a native iPhone or Mac app in about 9 years was recently. I've written plenty of C, C++, Rust, etc code but always found Swift and ObjC to be uniquely bad, and Apple's UI frameworks and tooling are terrible. So one way or another wanted it to mostly not be my problem. First that was RN's job, now it's Claude's job.
React native isn't a terrible idea, its fundamental issue is that Apple does not allow for JIT compilation on iOS. So that means your app's js logic will be an order of magnitude slower than what you would get in the browser.
I made this argument at my previous company a year ago and was shouted down by most of the mobile engineers. I have since departed, but knowing how much Shopify's engineering blog is worshipped there they will now say this is the future.
I wonder why not Kotlin Multiplatform. I’ve been using LLMs to build with KMP for about 10 months and it’s a delight and you can use native Swift UI when you want to. It seems to be the best of all worlds.
Well the thing is that the server code is basically Java, and the only bad thing about Java is writing it but since I don’t have to write it, it’s actually a really solid option. Then you have shared UI (don’t use WASM for web though it’s terrible, I use React for the web frontend) but you can switch to some or all native components when you need to on any platform. So for example I needed native components for secure storage and passkeys and did that by mixing in some swift on iOS and using a JNI native bridge on macOS and Windows.
I created a standardised bootstrap for all our projects here starting from the KMP wizard:
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.
I forsook RN years ago. I am not a huge fan of the JavaScript ecosystem in the first place, and the UX of RN apps is not the best. Instead, I adopted Kotlin Multiplatform (shortly after their memory management overhaul). I haven't been disappointed. As coding agents have come along, they are really good at writing both Swift and Kotlin, and I get to write all the business logic once. UI can either be shared with CMP, which is quite good, or platform-specific.
Most of the costs of switching have yet to be borne: user issues with untested code, maintenance issues with code few understand, and the strategic dependency on coding LLM's, which will change in character after providers go public and need revenue to fit reasonable stock multiples. All only get worse with time unless they're addressed proactively.
I think in the end, we should just be writing some prototyping language, then let AI translate into target/native development language of the said platform.
Code and optimization is going to be a niche moving forward
I think the most interesting part of this story is actually the Playwright-style “driver” that they built into their new apps to support faster verification by the agents.
Hopefully they will write more about that in the future.
I've always been wary of React Native, because my impression is that it hides nuances of the underlying framework. You may be fine implementing 90% of your app but then need that last 10% and may get stuck.
But then I'm also wary of the recent trend by Google to create higher level frameworks on top of native Android APIs. It seems that these days for every Android API family, there is a Google framework that gives you a higher level API. I don't really understand it - is Google admitting that the quality of native Android APIs has eroded? Do they think developers are too inexperienced to deal with native Android APIs?
I'm also not sure I understand the how reasonably large companies consider two native apps to be too expensive. A startup may have a hard time funding both and may need to choose, but an established business should consider not only costs but also the better quality of user experience that native apps provide - that has to count for something.
Surely the decision comes down to whether they have the expertise to build native apps.
I know JS and I know models still write a lot of garbage JS. I don’t know Swift so a model writing Swift all LTGM. Garbage is still there, I just can’t see it.
The solve isn’t another agentic harness. I need to learn more.
Lots of faster/cheaper justifications. I believe that part. If the quality bar is “web devs prompt models” then that’s a worry.
Native is the new React?! I could never drink the React Native cool aid due to background in performance optimization. Agents gave us the way to go native with less effort. Compilation is a good feedback loop for the agentic workflow as well.
Yea, I have started using c++ for some of the stuffs previously used python for. When agents is doing the grunt work, better to go even closer to machine.
They don't say anything in the post. But hotwire native supports pushing ui elements to ios and android. I imagine that might be part of the reason. I haven't built anything substantial with hotwire native though so I am not sure on all of the edge cases.
This is exactly the decision we have made (though we didn't start with native). It just makes a lot more sense to make native apps and customize to take advantage of different native capabilities. AI essentially makes this a lot easier, and the end result just feels a lot nicer.
We made the same change for our patient app last month, took 2 months to rewrite from react-native to two mobile apps, but we had the PoC in under a week.
Interestingly Apple approved it very quickly, which I was afraid of given such a huge rewrite.
As things get more complicated and you need to worry about performance, where every millisecond counts, it makes sense to go to native: React Native and Flutter. These kinds of technologies are really good in terms of building faster and building one app which can work across. Where that deep performance might not be of a bigger concern, or you need to go build components natively and then expose them through React Native. I think, with AI, now building even a native app is faster, so moving back to native can make sense if you have a team which can understand how things work.
Few of the biggest reasons for "migration" to the likes of React Native, and web-views et cetera, were "lack of talent", and not getting that talent fast, and for cheap, et cetera, while of course terming that as innovation, embracing the future, and "that's where the game is at" et cetera. Now with the LLMs that is mostly sorted. So if anything I'd be able to see the eradication of the Electron infestation in my lifetime. But then I see the very tools these LLMs are accessed with i.e harnesses (and of course mostly made by the LLM houses) are made of Electron or similar things (sometimes a Frankenstein like mix). And even today Claude Code shows up as `2.x.yyy` for process name ffs! So if anything, this is getting worse.
Then they say:
> We decided to switch from native to React Native in 2020 for three reasons:
> Stop building the same features twice
> Allow developers to work across the stack
> Spend less time chasing feature parity and more time shipping value
Totally!
Is there some kind of shame in just saying:
- we didn't want to hire more people
- we didn't want to pay those salaries
- we fired a lot of engineers with move to react native/hybrid in mind
- we could reuse the frontend devs (aka "full stack" folks) with or without some extra whippings ensuring they grok the bare minimum they'd need to build for mobile and test in on mobile.
The rendering layer and APIs differ significantly between iOS and Android. Agents currently do not know how to test the UI, at least in my experience. I would be scared to do that migration right now.
I came here to say this. I also prefer fully native apps but this is the elephant in the room. If most of your web code can be re-used on native, that's a ton of tokens you won't have to pay for.
When companies can afford to build a native app but instead use a WOSE (write once suck everywhere) toolkit, it’s because they don’t care about the user experience.
With latest AI models, we will most likely see shift back to just fully Native apps even for smaller teams.
This is type of stuff that AI models do really well, if you get a particular feature or even a bigger app change done in one platform, you can just tell Opus or Fable to replicate to the other platforms and in almost all cases it will just do it as well as most human teams would have done it.
In my limited experience, in h2 this year, LLMs were kind of shit at building Mobile apps. I had to switch TO react native because the flutter app it built me was a horrible buggy mess and I couldn't debug it myself because I don't speak dart. At least with react native I can kind of get in the weeds if needed
when you are large enough to allocate sufficient resource, you should go native, if not, go flutter/react native etc. Its very simple decisions I guess.
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
Your data is out of date. React Native performs within spitting distance of raw native now because in the last 2 years... it basically became native - it's now false dichotomy
It's not. RN has always used native widgets (with a custom renderer) but the JS code itself is purely interpreted.
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.
The underlying problem is that it's difficult to make a principled decision. So, it's ripe for SEO mining and such fuzzy takes happen.
The meta point of the article, I agree with though. The line is moving and AI makes having multiple platforms with code specific to them faster. Getting them right is still difficult.
The shared specs and tests seem like a big part of making this work. I'd be interested in a follow-up after a few months of shipping new features on both platforms. Does keeping behaviour consistent still take much coordination, or have the agents reduced that work too?
Even a single person can now build/maintain native apps. It's literally a day of effort for an experienced dev working with the best current models to port an app to a new native platform. Maybe another day or two to walk through wiring up all the test harnesses needed to prove the app is working well without a human having to click everything. Until recently you'd still have to spend a bunch of time on making sure the UI looked and felt right, but models now have good enough vision capabilities to where even that can mostly be automated.
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.
I have not coded any mobile apps, I understand the downsides of using react native/electron due to them being web apps but what about things like Kotlin multi platform or flutter? Aren't this frameworks supposed to allow your to have 1 codebase and the apps be truly native instead of web apps?
I think any framework that aims to support desktop and mobile frome the same code per view/screen is doomed to either make one of those two awkward to use, or alternatively become itself very complex to use.
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).
React Native apps are not webview based like Electron, they use native components. Arguably it is more native than flutter, which uses its own components designed to mirror native ones on Android and iOS.
wow, what about electron.js the bloated cross-desktop GUI, can LLM either totally modernize wxWidgets(to avoid Qt's license mess), or create some light-weight cross platform GUI widgets to make GUI easy on windows/macos/linux that is not resource heavy?
This is obvious in hindsight. I expect most companies that move fast and care about performance to abandon React Native. Code is cheap now, and the tradeoff of having a single codebase and only hiring React devs basically isn't there anymore.
Missing out on flawless App Intents integration could be business risk for Shopify once people get used to doing everything from a central chat interface, including shopping. I guess it's the real reason for the switch.
What I want to know is if the agents are so good that they can convert React Native code to native with amazing efficiencies along the way, what's stopping them from improving React Native itself?
Translating code from one language/framework to another is easy for AI to do, as it does not involve solving any novel problems. Making improvements to existing complex codebases is much harder.
I suspected we would start seeing these types of blog posts. Code is becoming low level, where people do not care what language, it is written in anymore. The cost of moving from one to another is becoming low.
There's Kotlin Multiplatform too, you can either have the UI for IOS also done in Kotlin, or just have the logic shared in Kotlin and make the IOS UI in Swift.
this motivates me to rewrite my Flutter app in Swift. I gave up on deploying the app to Android because of their 20 testers requirement at that time (not sure if its still true).
As the builder of a post-AI, cross-platform native app building framework like React Native, I 100% believe this to be a backwards move.
I've written up a load of thoughts about that here[1], but in summary for the Shopify case, they're basically going to be spending a ton more than they have to by switching back to multiple apps and I'd predict another swing back to better cross-platform tooling in the coming years.
> they're basically going to be spending a ton more than they have to by switching back to multiple apps
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.
I don't think its purely fashion here. React Native always incurred a bit of a performance & UX penalty, but many people decided that this tradeoff was worth it for the increase in product development velocity.
LLMs change the tradeoff and organizations would be remiss to not reconsider previous decisions.
This is what happens when you have too much cash on hand. You start wasting it and doing dumb things. Like rewriting entire apps in two different languages.
What I find interesting is how AI has changed the cost of maintaining two native apps enough that a decision that made no sense a few years ago is worth revisiting now
using React Native you end up having to drop into native code to do anything interesting or optimized, so it feels kind of pointless to not just use the platforms directly
“We debated between gradually migrating to native (brownfield) versus rebuilding them from scratch (greenfield)… However, this time greenfield emerged as a clear winner for the following reasons”
“To solve this problem, we built a system called Helix that takes a more gradual approach. It doesn't expect the first output to be correct, and builds a loop where an imperfect attempt simply cannot move forward until it becomes a good result.”
If this is driven by proper engineering then hats off! Supposedly a simpler app has already been migrated and they are working on migrating the main app using this approach. I don’t even know how I can be a cynic here… because the technology is good enough and so are the engineers I don’t know how management or executives could ruin it.
“…product quality people expect today. This isn’t just the same apps rewritten in different languages. We’re rebuilding them so both humans and agents can understand, test, and change them quickly.”
If this was written using AI and human-edited, you missed a spot.
This article makes more sense if you remove the self congratulatory verbiage from it, and the cost rationale which I believe is zero.
Most orgs used REACT native becuase they simply didnt have the interest or talent to build mobile apps using native tech. Many many companies outsource the entire thing for the same reason.
So NOW that its been many years, and LLMs are there to help them they arent simply AFRAID to build a native mobile app anymore.
Thats the entire article. The rest is utter nonsense and bullshit.
Most large tech companies are just job programmes, i've seen so much effort, time, cost go into things that are truly unimportant.
React Native gives you (with asterisks) - one "source" for things to go wrong (as it sits on top of the native implementations of the UI + Native APIs). You are writing at that source level, and that filters down to the native builds. I am WELL aware to do certain things on each platform you need to get your hands dirty, but most apps are just serialising JSON from a database and displaying it.
AI writes very buggy, sloppy code.
They've decided - instead of containing that code to 1 surface, they would now have 2 surfaces they throw slop on top of.
I look forward to the 2027 version of this where they've gone back
And on top of that, they're losing the ability to ship hotfixes over the air and will always be at the mercy of apple & google to deliver their updates.
Isn't it silly that this even needs to be a conversation? Shouldn't we be able to write in any language we want and have the bindings for it to work cross platform? And shouldn't AI aid in building those cross-platform tools?
Maybe React Native isn't the right choice - but two tech stacks for virtually identical interfaces is dumb. Three stacks if you include browsers.
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.
I develop iOS and Android apps and all the apps I have in App/Play Store are native. I did try React Native a few years ago but I just didn’t like how much extra bloat I had to include as third party dependencies.
Plus now with iPhone Duo which has so much variation in layout, I don’t think React Native would work well for it.
I mean it sounds nice but they never say _why_. "AI removes a lot of the burden" is not a _why_. I was hoping to read about some of the shortcomings of React Native, but it seems like they're doing it just because they can. I remember Airbnb had a post about switching off of React Native years ago that actually had some solid reasoning behind it.
With cheap/fast code, it's easy to support multiple software stacks since most of the abstract engineering problems are already solved.
Code - especially straightforward low-level code - is so cheap and easy to write now that some people are building their own version control systems, game engines, and other low-level tooling.
Thus, some of the most demanding, human-centric work in software dev right now - where we now spend more time than coding - is in technical PM, UI/UX, devops, and overall architecture. The decision-making and design aspects of the job.
Its interesting that the move is back to native and not towards a technology better suited to delivering the same experience on multiple devices from one codebase.
I'm certain that small startup Shopify could not afford to build native applications before AI became a thing. Thank god Sam Altman stole all the information in the world so that small family companies like this can finally have software too.
oh fuck my life, we're back to this circa 2000 default of having incompatible binary UIs frameworks across various different platforms, with different OEMs shitting the bed at various different times and Apple free to arbitrarily force its hardware and OS into CI. I felt we were so close to unification in 2011.
And that's not even discussing the heresy of app stores. Curse smartphones for ever happening.
The article itself comes from AI ? It says twice why they switched from Native to React Native in two distinct paragraphs at the beginning. The rest sounds also AI slop jargon.
There's quite a bit of research out there showing that application performance has a material impact on checkout conversion rate, so a single platform optimization potentially improves checkout for millions(?) of storefronts.
Google research from a decade ago that might as well been that their bot did not want to wait for pages to load. The performance difference between React native and a web wrapped in an app is pretty much zero today.
> 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.
I wish more companies would just focus on webapps. It's infuriating how many services try to push an app on you when it's completely unnecessary. The other day I went to a restaurant that had an app. Not a fast food chain, a nice full-service place. No, I'm not going to download an app to order dinner.
This is probably biased by the specific multi-platform apps I've worked on, but my default assumption is that sooner or later, any non-trivial multi-platform app will need to reach for something that doesn't already have a KMP library and that, on Android, might require compiling native code via the NDK. Rust has a way bigger library ecosystem than KMP. So I figure one might as well do the cross-platform core in Rust and add that FFI boundary early, but managed by something like uniffi-rs. And, I've seen it work in a few real projects now, with just a little build system friction up front. So in what sense is Rust uncompetitive for this use case?
KMP can call into native libraries easily. C FFI is not a competitive advantage.
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.
In that case, Kotlin makes even more sense especially with Kotlin Native, and Rust is unnecessary.
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.
Agreed, the whole of the Javascript / TypeScript ecosystem has caused a slop hellscape of workarounds, half-backed fixes and have exposed short-comings in the ecosystem.
Perhaps these languages do not work well as they are not designed to run efficiently on mobile devices. Now that we have libraries such as SwiftUI and Jetpack Compose, React Native no longer makes sense to use.
Now we should also move away from Electron to better alternatives such as Kotlin Multi-Platform or fully native libraries on each platform; because of LLMs.
So disagree. The benefits you get from leveraging a framework as as important today as they have ever been -- strong frameworks, fewer tokens, faster progress.
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!
I've been around long enough to see this argument come and go under a lot of different names. This time it's AI. Maybe AI really does change the economics. But this post doesn't demonstrate it.
Talk to me in a year.
The side-by-side comparisons? Whoopty do. It's different code. Of course agents can produce two implementations that look the same today. That's not the hard part.
The hard part is keeping them the same.
Feature parity isn't an implementation cost. It's a divergence cost. It accrues over years across experiments, analytics, accessibility, edge cases, bug fixes, platform behavior, and a thousand little decisions which current agents aren't great at tracking.
Agents can write code fast but they aren't a panacea.
The load-bearing sentence in the whole post is this:
"Shared specifications, tests, and review checkpoints dramatically reduced the cost of maintaining parity."
Okay. For how long? By how much? Got any numbers to share? How will these hold up under contact with customer?
You haven't maintained parity yet. You've built prototypes. You're making a claim about a cost that compounds over time based on what it costs at t=0.
The other thing missing is the counterfactual. They keep comparing this rewrite to what a rewrite would have cost before coding agents. But what if you point those same agents at the existing RN codebase?
If agents make software development cheaper, they make RN development cheaper too. And now you're modifying one implementation instead of generating, testing, reviewing, and reconciling two.
The tooling section makes this even stranger. They find that agents are bad at driving simulators, so they pull business logic out of the UI, make it runnable headlessly, and expose a CLI.
That's a good idea! Do that!
But that's an architecture change, not an argument for native. You can make an RN codebase agent-friendly without rewriting five apps.
Then you get to "Preventing slop," which is probably the most important section in the post. Just pointing an LLM at the codebase doesn't work. They had to build Helix, with ordered checkpoints, test proofs, visual diffing, adversarial reviewers, and human gates.
So what they've actually demonstrated is that Shopify has enough engineering resources and agent infrastructure to make maintaining two codebases look economically plausible.
Maybe it is! For Shopify.
That's a much narrower claim than "AI changes the economics of cross-platform development."
And where are the numbers?
For a post about reevaluating costs from first principles, there's remarkably little cost data. Engineer hours? Review time? Defect rates? Parity failures? Agent spend? Ongoing maintenance? Anything?
They even say RN performance isn't the problem. "React Native apps can be fast. Ours are."
So there's no product crisis here. No performance crisis. There's an internal cost argument, with no numbers, being used to justify rewriting five apps used by millions of merchants.
And in isolation I'd probably just shrug and say: Shopify made a bet. Let's see how it goes.
But it's harder to view it entirely in isolation when they brought Tailwind on yesterday too.
Shopify used to be one of the great stewards of the broader ecosystem. What worries me about the recent direction isn't any single technology choice. It's the appearance that, following the recent tech leadership changes, we're starting to see decisions driven more by the preferences of the people now making them than by demonstrated technical merit.
Maybe that's an unfair read. I hope it is. But posts like this don't help, because if you're going to make a sweeping technical argument for a major change, show the evidence.
The part I actually find convincing is much less exciting: Shopify is tired of paying the upstream tax. They've spent years working on RN performance, improving the framework, dealing with dependencies and upgrades, etc.
Fair enough. That's a real cost. Being an RN framework developer or dependent is -- or has been -- awful -- it's like trying to fly a kite in a hurricane. The web team has been super disciplined and also ridiculously slow. The RN team changes apis in .. questionable ways with regards to compatibility
But it's not new, and it has very little to do with LLMs.
And let's not get me started on taking this kind of dependency for your business on companies who still don't have any idea how much to charge for their tools and are all operating (on a per token basis) at a loss. They're swapping some framework dependency for dependency on coding models whose capability, pricing, and terms they don't control.
None of this means they're making the wrong decision. Maybe they're right. Maybe in three years this looks obvious.
But that's exactly the point.
Come back in a year and show me parity bugs, engineering hours per feature, experiment drift, accessibility regressions, review burden, model spend, and how much human work it takes to keep the implementations aligned.
Right now they've shown that AI makes rewrites cheaper.
That also means that ruby becomes less important in their (rails) stack since they move to Swift and Kotlin specifically. Quite interesting considering problem-man DHH ("why are people upset at me shooting at wolves and comparing this it to Roma and Sinti" - and even aside from the connection on his blog to humans, I don't think everyone agrees at gunning down wolves in the first place) is part of the Shopify bromance team.
In hindsight that also explains why they laid off so many ruby devs in the last two years. Now if only someone could have told the ruby core team that companies pursue their own interests ... perhaps then they would not have led to the fiasco about a year or so ago. (And prior to that, the silly 100k downloads restriction at rubygems, aka "after that point we no longer allow you to remove your own code", whereas Microsoft github has no such restrictions in place. What are these people smoking?)
Numbers from GPT Astra - Shopify has 3000 engineers as of 2026
- Google Chrome when released in 2008 conservatively had ~ 60 engineers.
- GTA 5 in its credits had 150 software engineers. Surprising even to me who has had many an experience of being in a bloated FAANG team, this 150 includes GTA Online!
In a sane society, Shopify’s opinion on anything engineering related would be thrown into rubbish because they seem to have managed to complicate a simple app into requiring thousands of engineers and now maybe millions in cloud spending to Frontier labs. This is unfortunately not an isolated case, Spotify for one has the same issue, idk what “engineering” Spotify is doing, it’s the worst app I’ve used in my life.
When Chrome 1.0 came out in 2008, it only ran on Windows, and it couldn't do basic things like print or export to PDF, didn't have any accessibility, didn't work in RTL languages, and didn't have any graphics acceleration, among other limitations. Don't get me wrong, it was a marvelous piece of engineering - but it was extremely incomplete. By the time it was what we think of as a modern, complete browser, they had many hundreds of engineers working on it.
Also, you're comparing the number of engineers working on one product, to the number of engineers working at Shopify across their entire company today, which includes far more than just one app.
You're entitled to your opinion that Shopify is a poor app or that it's overengineered, but clearly it's not simple. That's just a fact. If it looks like a simple app to you, that's because you're not seeing most of it.
It's like looking at the YouTube mobile app as someone who watches videos and saying that the app frontend looks simple. You're only seeing 5% of the app. The other 95% is for video creators and advertisers, and it is decidedly NOT simple. I think that's the same here.
And it was a fork.
Rubbish. Most of the stuff you’re listing is handled by OS and frameworks themselves, you don’t need hundreds of SE to handle RTL or a11y. I work in one of those companies, most people just regurgitate existing shit into another form of shit and collect salary (not complaining, as I’m one of them, but let’s be honest).
The original Edge had to switch over to Chromium because it was hard to build a compliant accessible browser from scratch and this is Microsoft we are talking about.
> ...this is Microsoft we are talking about.
Exactly!
More seriously, it not just about building a compliant web browser engine, it is about tracking the dominant browser engine which introduces their own "standards" along the way too.
Microsoft could have easily continued to invest in maintaining their browser engine, but it would have to be comparable to what Google is doing, and yet they'd always be perceived as "behind" due to non-dominant position they have.
I'd say strategically they do not want to invest in tech that's not winning (in marketshare), so when they are not dominant, they'll instead adopt and extend (not just web browsers, look at WSL too).
We live in a time now where libraries are free and plentiful and pretty good. It is easy to forget that this was not the case for the vast majority of time that computers have existed.
Chrome’s original design definitely predates our current rich ecosystem. Plus, V8 and Chrome’s performance profile are demanding enough that there would be a pretty high bar for those dependencies anyway.
This is plain wrong. For a browser, a11y doesn't just get handled by the OS automatically. In general, claiming a11y is easy or will be done by someone else is bordering on evil.
Spotify has progressively gotten much worse over the last 15 years, all while the size of their engineering team has ballooned.
I am very unsurprised by this outcome.
People wonder why good software becomes bad, and it’s because the people who were good at engineering are often outmaneuvered by corporate-politics savvy people in a growing company. One of the best political moves in a company is to have a lot of people under you.
A couple years ago, an engineer I know who has always been a very poor performer and lacks initiative, but is friendly and non-confrontational, was hired by GitHub. It would not have been hard for GitHub to find a much better engineer, but this person would be an easy person to keep under a manager on a team who wouldn’t leave or make waves. That can be more important to some managers than skills.
Sometimes I wonder what the tech ecosystem would look like without the ZIRP era.
I look back over 15 years and with the exception of increased smart phone usage, everything else still looks mostly familiar. Maybe a bit more slick, but also slower and buggier despite having much better hardware.
There hasn't been a qualitative leap in software (as was in the 90s). Just larger SaaS companies. Without ZIRP would it have been any different?
I have the impression that for hiring this is fundamentally the most important aspect: Finding a prospect that is just skilled enough for the position without being a risk to the person who is hiring them.
When it comes to number of engineers, always keep in mind that it costs more engineers to maintain (and understand) software than the initial development push.
>Spotify has progressively gotten much worse over the last 15 years, all while the size of their engineering team has ballooned.
Spotify or Shopify?
Spotify, the comment I replied to drew a comparison from Shopify to Spotify.
I think I’ll start a company called Shpoptify.
I’ll subscribe to your Sphoophtify service immediately
Can’t wait for Sphpoophteefy+ premium subscription to be released!
Probably both
> One of the best political moves in a company is to have a lot of people under you.
This is why I’m sceptical of “AI will kill corporate jobs”. A big company has no profit sharing for successful departments. Everyone is trying to get budget to hire because it makes them feel important.
Any book recommendations, that is not satire, about navigating the political landscape?
Spotify had a good app when it came out, p2p and UDP custom networking...
The mythical man-month ;)
This is wrongheaded in so many ways.
To start -- how many of those 3,000 engineers do you think work on the mobile app? And even among those who work on the app -- do you think they're all working on user quality-of-life and just can't get it right? And it's a $175BB company -- do you think it's worth that much based on the quality of its mobile app?
i will bet 175 billion dollars people like that guy are bikeshedding types
You're comparing a company (Shopify) to an application (Google Chrome). A better comparison would be the number of engineers at Google (90,000 [1]) vs Shopify, or the number of developers actually working on the mobile application instead of any other area (website, backend database, internal systems and processes, infrastructure management and maintenance, etc.).
[1] https://www.linkedin.com/posts/rpandey1234_its-mind-bending-...
People who has not run software at scale have no idea what it takes to run it at scale. Google chrome is 60 engineers at launch but google same company has more than 100k engineers. Building first version was always easy and only gotten easy, scaling software was always hard and it is still hard.
PS - Spotify i can't defend the product sucks.
I am quite curious about what people hat so much about Spotify. I made some excursions the last few years to competitors like Tidal and Apple Music but I just found myself coming back because the Spotify mobile app experience (and desktop) was just plain better.
I wonder what gripes people have.
I wonder how many of the 100k+ enginners at Google work on that "simple" text box that shows you relevant websites to the input text.
I'm guessing that maybe 4 of them maintain that in their "20% time", while the 99,996 other engineers are:
"The best minds of my generation are thinking about how to make people click ads." -Jeff Hammerbacher
It’s not that much about scalling software, as scalling software on highly concentered nodes. Distribution downstream can be its own hell, admittedly, but otherwise having fully independent copy of software copies that run in local terminal is a no-brainer if all that matter is running software at scale.
What are we talking about here - Spotify or Shopify ?
If Shopify - and you are concerned about their engineering teams, please consider that Shopify's revenue grew from roughly $205 million in 2015 to $11.56 billion in 2025, reflecting an explosive compound annual growth rate (CAGR) of over 45% across the past decade. Market validates !
I have nothing to add about Spotify - I use it to listen to music and it works well for me !
Shopify works well for me but it used to push nonsense like podcasts or audio books that I had no interest in, with no way for me to hide them. I just want to listen to music.
Upon looking just now, seems like they have been relegated to their own tabs now, which is great.
I can’t tell if we’re trolling at this point with the mixing up of Shopify and Spotify
> GTA 5 in its credits had 150 software engineers. Surprising even to me who has had many an experience of being in a bloated FAANG team, this 150 includes GTA Online!
Just so it is said: my understanding is it's really easy to not end up on the credits list for games despite having worked on it. I don't know if contractors end up on there for example, at least beyond some team leads or the like. I don't know R*'s policies though, I've heard stories of people not being in credits because they, for example, changed jobs near the end of the development.
I get your overall point though
Video games are much easier than what Shopify do which will be a long tail of business cases and local permutations for all the countries they operate in.
Commercial software is usually a simple core and a long tail of business exceptions
That’s different difficulties.
Like comparing a climb and along run. Sure both require some physical abilities, but in the first case any error and the collapse mean dead end bringing progress to zero, while the second one you can rest on the side any time and still have the miles behind you accomplished.
It's externally mandated difficulties vs internally created ones. I think the latter should always be easier, because you can change the requirements.
In the corporate software world, especially anything to do with the web both front and back, most people really don’t know what they are doing. The goal is hiring/firing and agile.
Compare that to companies that release actual software products. The goal is product release at high enough quality. There are real performance and security targets to achieve.
Your typical corporate developer, on the other hand, does not have release targets. The actual goal is compatibility with the industry least common denominator expectations and retaining employment. This is why so many people are needed to do the work and why the result is so slow and bloated.
What's an "actual software product" and why don't you think web products count as them?
I'm a full stack web developer. I've worked for startups and F500 companies. There is always a push for release targets. The less technical the leadership, the stricter the release targets (its hard to sell a critical refactoring to management when they cant sell a shiny new feature or kpi to their own boss). We've kept our teams pretty lean too.
We still aim for high quality, and performance and security.
I do agree that many people dont really know what theyre doing and are kinda just winging it, especially with AI at the helm, and many companies are likely overstaffed, but I dont think theres a correlation between headcount and slow/bloated software. Any team of any size can make slow and bloated software.
If you are selling the code as the product, it could be said to be an “actual” software product, rather than a mechanism for selling other products, or software as a substrate for some other business.
Those other businesses aren’t any less valid, of course. They just aren’t software businesses. They are businesses that (quite sensibly) use software.
They'll be mostly involved with the parts that make money. I worked in a similar situation as one of about 5 people keeping the core infrastructure of the product working, meanwhile about 500 people optimized the ads
How is life at Google nowadays?
Oh you said 500, not 5000, my bad.
Comments like these make me wonder if people don't understand the difference between engineering and business.
That’s what they said about Elon firing 80% of Twitter’s staff. But X is doing pretty well.
For some definition of pretty well which doesn't include human user numbers, revenue, profit, or ratio of humans to bots
Pretty well from an engineering perspective. But they've lost so many advertisers because it's intentionally not very moderated.
The site is currently running, yes. Don't forget it went down quite often immediately following the mass firing though. They seem to have fixed that.
There was certainly a ton of bloat to trim, but the haphazard "just pick 80% of the people and fire them" was incredibly stupid. Should have chosen whoever was producing the bloat, at least.
Twitter was never a profitable business. You actually renforce his point.
(Maybe that was intended I might have missed some irony here)
I'd be shocked if a ton of contractors haven't worked for X since then
most people don’t. that’s why they are employees.
Add to it that they need a compiler team for a Ruby JIT, due to the language choice to run an heavy load server infrastructure.
And now we learn they use Swift and Kotlin to replace React with. So they are not replacing it with Ruby. I think they've hit the limits on Ruby (like twitter had on Scala).
P.s.: I find Kotlin "an acceptable typed-Ruby" with an industrial strength VM (the JVM) and two compiles to native stories (KMP and GraalVM-native).
I wonder how many of those are there to consult with customers and help them build their stores.
One word: Ottawa. There's a lot of engineers, most of them underemployed.
>what “engineering” Spotify is doing, it’s the worst app I’ve used in my life.
Engineering is app usability. Theres no other possible thing an engineer might do. Chrome ofc has infrastructure to distribute a binary. Spotify of course having a global content delivery network for terabytes of music. Hey GANG CAN WE WOKK OUT WHAT THESE ENGINEERS MIGHT BE DOING?????? WHY HASNT JIM STORAGE ENGINEER IMPLEMENTED A UI REFRESH YET!!!!
Shopify supports multiple countries both as a buyer/seller. I assume there is all kind of customizations needed to comply with each country weird rules. Are all of these software engineers doing core engineering? Probably not. But they are probably tagged as software engineers within the organization.
We have no idea how many of these engineers work on the mobile app. This comment is somehow both AI slop and human slop.
its actually not that weird if you consider that those shopify engineers are probably not even exceeding 150,000 usd on average salary wise
canadian dollar is very cheap so you'd likely see 40~50% more headcounts for the same burn rates you get in USA
i definitely dont think those shopify engineers are going to be retained long term however
We did the same thing - had 90% of it overnight. Then spent a few days in the background tweaking for polish.
Our app is smaller, and has about 15-20 screens. I started at about 12:30am by giving codex a goal and it inventoried every screen based on the react native code, then created android and iOS directories, used maestro (I had already set up this tooling for a previous personal app build a few weeks prior), and had the whole thing working in android and iOS in the morning. Took it about 6 hours while I slept.
The app is way smaller, launches instantly, and the android app is (supposedly) native looking. I say supposedly because I don't use android phones. But it's using Jetpack Compose and Kotlin.
And I don't know Swift or Kotlin. I honestly don't see the point of React Native anymore. I know Expo is doing very cool agentic stuff, but I'm just not sure why I'd need any of it when I can write a native app.
How are you evaluating the Android build if you don’t use Android and you don’t know Kotlin?
We have people on the team that are android users. I just meant that I don't want to evaluate whether it feels "native" as I personally am not an Android user.
You just install it on your phone and use the app.
Maintainability concerns are entirely overblown by people who don't use agentic AI to develop large mobile apps, but anyway give their opinion as if they had that experience.
I put in a few hundred hours, and I reached the same conclusion as Shopify. With reviews from other models and then a manual QA pass the result is fully usable.
I work as a professional app developer. And I find this take to be naive.
Most of the time when I review code from AI, there is always something to improve.
It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.
The maintenance is not only the burden on the human and LLM. With too many moving parts, it becomes harder and harder to build and verify the correctness of future features. Yes you can write test for this and that, but it didn’t need to exist in the first place.
The second problem is correctness issues. Especially the edge cases. You cannot just manually test out a race condition on a phone! Sometimes it happens! Sometimes it doesn’t! If it leads to a visible signal like a crash, then yes, you can try to reproduce it. But there are a lot of these that are “silent” and would just lead to bad experiences.
We already had a software quality crisis! And I think such views only exacerbate the situation! Quality matters!
And this is not an anti-AI stance. I vibe code personal projects where I don’t even look at the code. But when I use AI as a professional engineer, I act like a professional. Because these products do have an impact on people’s lives.
All true (and thanks for posting a concrete example rather than "LLMS suck"). But my take is that none of this is much different than before times when I had teams of developers creating applications. They would often make similar mistakes which I would either need to catch or which would flush out in the field. Where it seems that LLMs are not excellent is where the person driving it is also the senior domain expert so can immediately spot pitfalls. But typically using humans to develop software this was really not often the case. Those people get promoted so they're no longer cutting the code. Under that scenario (replacing subordinate humans) I find the current models are either on-par or somewhat better (specifically because the models can also act like a peer senior dev, discussing approach options etc).
I agree with you! And I’m not trying to romanticize the past! Humans/me wrote slop too.
I think we are over-indexing on speed of delivery. I think this is a mistake. The alpha is in speed and quality.
Currently, my experience is that human + AI can write software faster and with better quality than either party can do alone.
> It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.
I understand this, but I just can't bring myself to care. I've been doing professional software work for almost two decades. These sorts of improvements/time savers are great without AI. With AI? Whatever. It's fine.
When the underlying lib has an issue, it'll be quicker to debug with the whole thing in context.
So exactly what value are you adding, then?
I take the specifications from the customer and type them into the AI
You do realize that letting the LLM produce more output means that maintenance will be more expensive? I can easily see a world where claude and gpt are producing more tokens to sell you more tokens.
This is not as obvious as many naively believe.
It depends on how hard to maintain the code added is, how likely it needs to change in the future, and most importantly on the cost.
If reviewing and manually improving the code takes hours, the cost may already be in the thousands.
That buys you a lot of AI usage, roughly a few months of continuous work.
You have to balance this with the chance that the suboptimal code the AI generated is actually fine and maintainable enough, and also the chance that during further work on that code a model might implement the same optimization on its own.
Just the other day I burned through my 5h quota twice in a row because I had opus spawn a review session on a medium sized PR and I don't know what happened but I told it to summarize to me and it said it spent 100M tokens throughout 50 subagent sessions.
And more recently its been recommending that i install this new browser called Aside. I did, and it almost felt like I was installing malware so I Uninstalled it fairly quickly (it also was not a great browser)
I feel like theres collusion somewhere.
The models will only get better and inference cost will go down.
I don’t see any reason to think the same thing that happens with all tech won’t happen here.
So you don't use agentic AI to develop a large mobile app and you think my take is naive?
I also used to work full time as a Android developer for five years, and I'm pretty sure I know better than you about the quality of my app that I work on everyday.
No where did I say we don’t do agentic dev!
Years of experience doesn’t mean much! I will challenge you on ideas. And the idea you are sharing is dangerous and unprofessional.
Especially at scale. e.g., we process more than 3.5 billion orders annually! This is serious business. Edge cases are common.
Same result here just using plain Opus 4.8+. I had a web ap with a PWA approach. Now I have an iOS app written in Swift/SwiftUI and an Android app in Kotlin in the appstores. I do not know how to code a single line of Swift or Kotlin. You just test the app and iterate with the AI over it until it is stable and does what it should.
> You just install it on your phone and use the app.
Some people on the cybersecurity side are starting to cry....
Are there cybersecurity concerns in the frontend? I would have thought you have to assume the client is untrusted and only do security work on the backend
1. Not storing secrets properly or using hardcoded secrets
2. Wild use of webviews/iframes sometimes easily propagates as XSS in phones
3. Incorrect client-side OAuth 2.0 configuration e.g. with schema-based redirect URLs.
4. Not supporting high-enough API versions, which may prevent some OS-related weaknesses
5. The list is actually very long. Just few top of my mind.
My favourite is a logout button with a logout API that fails. (Not a huge pratical concern, I admit, because it's a local attack.) Nobody ever notices because it still shows the logout screen, which hides the API error toast (if errors were even displayed). The still valid refresh token stays in sessionStorage (or even localStorage) while the app displays "logged out". (Bonus points if you cleared the access token in the error handler but not the refresh token, and on page reload you ask the user to log in again despite having a valid token.)
Or a login form that gets hidden after login, but clears the username and password only when you click "login back in". (Bonus points if the backend also enforces a 5min session timeout "for security".)
Storing private secrets in your public client is easy to avoid for anyone halfway competent. We are all professionals here.
Turn on the secrets scan in GitLab, and put in your release checklist to have the AI audit the usage of secrets in your app, and this is basically guaranteed not to occur.
I doubt current models even make such a mistake in the first place, and particularly so if you use reviews at all.
WebViews are not an inherent problem, it's the system browser embedded in your app.
Where it gets tricky is if your use case involves authentication in the browser. Together with the authentication in your app this is the one area where you need to focus on security.
The case where a SDK update is needed to prevent weaknesses of the OS seems rather unlikely.
Doing anything right on web is 10x harder and more complex. The problem is the browser, once you use it to deliver anything you have to buy into all of it’s bullshit. CORS, XSS, headers, caching. All that just goes away (outside your backend API, if you even need one) when you ship a native app
Fantastic answer thank you
Nailed it. Assume your client is compromised and/or malicious regardless of how it was built.
If your clients are compromised then what's even the point of backend security. Users will login and do legitimate actions while their compromised client does whatever behind their back, while still looking normal. And the backend can't tell the difference.
This is the most naive take on security ever. For the backend, you assume your client is compromised, but you still don't want to allow your client to be compromised.
I have been getting these comments often here, including concerns about my non existent backend's security.
Last time, when I pointed out that the attack surface for mobile apps is typically very small, some users started to talk about zero day vulnerabilities in the OS's media handling, as if it was a concern for my app implementation.
I found the concerns again wildly overblown.
But what if someone discovers a iOS 0day worth several million dollars and burns it to compromise your app specifically? /s
They better start a proper hydration regime because they'll be crying a lot.
Why? The api has to be secure. Mobile os keeps the app safe. Where is the attack surface?
You don’t believe how often people leave secrets in the app or use webviews and iframes badly, misconfigure OAuth in client side and so on. There are many issues where secure API does not help.
That's a recipe for regressions as the amount of surface you have to cover with "just...use the app" gets bigger and bigger.
You can write more automation to test it. But that's also how you end up with ever-growing test run times.
There are much better ways that aren't just "throw out the LLM" either. You just need to be more focused on throughput. Requiring manual validation can pretty rapidly require more hours than just sanity-checking code by hand, even (and I'm not advocating that for every use case, either.)
I can't afford manual QA passes if I'm gonna go as quickly as I want to.
> You just install it on your phone and use the app.
OP says they don't have an android phone...
No, they said they don't use android so don't know the native UX. You can test your app on the platform and confirm that the functionality all works, but how well it adheres to the platform's design language is subjective and hard to say if you aren't used to the platform.
Android studio has a emulator
I used the emulator - but just like I can use an iOS app for 30 seconds and tell you whether it feels native or not, I can't do the same for Android, since I'm not a daily user of Android phones.
And in the past, I didn't care because when I was manually building the app, I would just do my best with react native. But now that I can actually sweat the details (with the help of agents), I do want to hear from android users and use as many OS-native APIs and features.
I missed that.
I'd order a cheap Android phone to have a device in hand instead of working only with the simulator.
Others on our team use Android phones. So when I said that we spent the next few days actually polishing it, that's where others came in, providing feedback when they used it.
I could only sweat the details on liquid glass, etc because I'm a daily iOS user.
I am using Gemini as well as Opus on a somewhat small project in React Native and I can not imagine this thing being able to build the whole thing on its own without it being a dumbpster fire.
Can you share some details of how you work? What models? What harness?
We use CC with Fable(Opus before that) continuously on a rather large project, everything is tested, we maintain high verified test coverage, we ship features x10 faster than when we started(pre Claude-everything era 2-3 years ago). I never worked with RN before and I ship features now. LLMs allowed us to find issues within RN itself, that thanks to some patches, improved lower end Android experience by a lot. We just use all the Claude defaults with claude.md that evolved over last year.
I use Codex and Claude Code desktop apps. I generally use only the SOTA, now Astra and Fable 5.1, Opus 5 when Fable runs out.
I don't know if Gemini is suitable.
I had few issues with my native iOS app, the results are just decent after a few iterations, the models do what I ask them to do. Where do you see the problem?
The LOC for my app is now at almost 200k + 110k lines of test code.
"the models do what I ask them to do"
what the fuck are you talking about
> Opus
> Are there cybersecurity concerns in the frontend? I would have thought you have to assume the client is untrusted and only do security work on the backend.
I hate software engineering now.
Damn, we really gotta get rid of the vibe coders. Bad things are on the horizon if we keep encouraging these naive habits.
How do you propose getting "rid" of "Vibe coders" (which I'm assuming you're pooling me into?)
Severe financial liability for security breaches, severe enough that, for instance, companies which leak 1m+ user data are driven to bankruptcy
[yes, this would also get rid of the previous generation of 1000-JS-lego vibers]
Yes, what type of "engineering" is this? "I click the button and I see if it works or not" holy shit.
> You just install it on your phone and use the app.
That‘s how you check functionality but that’s not how you get the bugs in the code.
That's the part covered by the other model's review. That together with manually verifying the functionality results in output that works.
If you don’t know the language you can’t evaluate if the models really found bugs.
That’s like translating a text to another language without knowing the language
This is wildly overblown. I've been working with agents for a good while, read tens of thousands of generated Python and the language factor is actually the part they get right that humans don't.
Remember the first step to fixing any problem is admitting you have a problem.
If you are blind, you cant see anything wrong, if you are deaf uou cant hear anything is wrong.
Seriously! What a bonkers thing to claim. "I had codex use maestro so I assume it made Android work well and idiomatically".
It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem, which makes me feel fear in my heart when I imagine the first "production is down" page coming in. I already hated mobile because it's so much harder to maintain than web (and I don't do any spyware or IAP so no benefits for me there); this yolo approach would give me constant dread.
It shows that at least some software development is moving away from code and to product management instead. I'm not passing judgement on that; I actually think that's great for a lot of software. It is interesting to see the shift happening though and will be fun to see if the general quality of software noticeably changes over the next few years.
> It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem,
As much as I dislike it, I think that's the future of _all_ non-critical software (think social media, crms, CI, food delivery etc). Leadership in many companies is explicitly asking employees to have multiple agents running through the day and that will lead to this.
Read this for example: https://www.uber.com/in/en/blog/efficient-software-factory/ . A very useful system, I am sure. But when you have AI at every layer from code to review to triaging, rest assured AI is the only know who knows your system. And you better hope it's not telling you that something is load bearing during an incident.
I answered elsewhere that I don’t personally use Android phones but we have people on our team that do. Which is why I don’t want to personally claim that it feels native.
But yes we are having real Android users test it.
So it’s quite the contrary. I care MORE what real users say. I can only guarantee that the app does things when I tap. So I’m not trusting the agent on UX, only on functionality. But whether it feels native, I am relying on those users in our team.
That's much better than my original, perhaps unfair, read. Thanks for the additional info.
I still would feel scared operating an established product off a newly changed stack the team isn't familiar with though.
> this yolo approach would give me constant dread.
When you’re completely ignorant, there’s nothing to be afraid of.
I wrote every single line of the react native app we ported, and maintained it for 9 years. So suffice to say, I'm familiar with the code.
But I am going to always prioritize the user experience over a developer (like myself)'s need for satisfaction to see code. And a pure native app is _always_ going to behave better than react native.
This gives me a chance to do that.
> And a pure native app is _always_ going to behave better than react native.
Maybe iOS is better about consistency, but I've used enough horribly made Android apps that I would not expect one that's vibe coded to behave better than a professionally made react native version.
Maybe. Android might still be a mess, fair point.
>So suffice to say, I'm familiar with the code.
You are familiar with the React Native code, you are not familiar with the Swift or Kotlin code, and likely nobody on your team is, since the AI wrote all of it for you.
First “production is down” page means you just tell codex production is down and to fix it.
Presumably a sarcastic post, but this is actually going to be how things are done soon. I had a box that OOMed and needed to be rebooted every few weeks. It was a disaster recovery standby box so figuring out what was going on never rose to the top of my priority list. So I asked Claude to dig into it (proxying the commands it wanted to run through me) and in an hour it had diagnosed the problem, fixed it, and taught me a bunch about memory usage in our system on modern kernels.
Not sarcastic. I have a moderately successful app and I haven’t once looked at the code (though I am capable, so far atleast). The only time I open Xcode is if I have to modify signing certificates. I did set up a slack workflow with a “fix it” button that basically tells Codex to fix the issue, run comprehensive tests, manually UI test for that particular issue with computer use and then deploy it.
Equal parts very cool and very scary to me
It is. For my day job, I’m a software engineering director and I probably won’t have a job in under five years. For low to medium complexity apps, even Codex before Astra was capable of doing it completely by itself from scratch. For testing I would bring up the app after each atomic change and then manually try it out. I also use my own app heavily multiple times a day and I have found dozens of issues but I just ask Codex to fix it on the spot.
ITT: people dealing with realities.
Remember Chinese accounts on US Facebook say data centers are bad.
And people say AI isn't taking SWE jobs...
While I mostly agree with you, this is the kind of thing that might not have been done if the AI couldn't do the heavy lifting.
They had previously chosen React Native because it was easier for programmers to keep it updated, since it was really just 1 codebase. With AI, those same programmers can do the more difficult version, keeping the native apps updated separately.
So did it kill a job, or did it make it possible for the existing programmers to do it better?
It's the kind of thing that is really hard to determine in general, but here, it really does sound like they only made the change because it became possible with existing resources. They would not have done it otherwise.
That's an example of AI growing the sector that can lead to more jobs. Because suddenly a lot of tasks that weren't economically viable are now going to be in demand. Custom software for small businesses, platform specific optimized code instead of cross platform software, etc...
This is a type of project that likely wouldn't have been done before AI
Of course it would. Supply and demand. Some companies would decide not to bother. Others would decide it was worthwhile. The limited pool of supply (app developers) would be distributed across demand.
> Some companies would decide not to bother
Sounds like you agree
I agree that AI is suppressing developer wage growth and taking real jobs. The opposite argument is being made elsewhere in the thread, and I think that argument is wrong.
>> Some companies would decide not to bother. Others would decide it was worthwhile.
The parent's point is that AI lowers the cost/benefit ratio drastically, by reducing the cost. So companies that would have shied away from projects like this pre-AI are now pulling the trigger without much hesitation.
> The parent's point is that AI lowers the cost/benefit ratio drastically, by reducing the cost.
…as long as Claude is still subsidized…
And what a lot of people seem to miss is that with AI, there is going to be (already is?) orders of magnitude more software in this world. I'm sure a lot of jobs will be eliminated, but new jobs will be created as well. Hopefully enough to balance things out, but we'll see.
The optimistic outlook:
Just like this has made Web devs into Mobile devs, so could Mobile devs leverage AI to work in Web shops.
I'm not an optimist but there could be an increase of available apps being created which would still keep people employed. Theoretically the cost of creating an iOS app for a company without an engineering team dropped from several hundreds of thousand to a few thousand or hundreds, which could be paid out to a freelancer with AI. More people would go into freelancing for industries which were not contemplated before due to cost.
But I'm not an optimist.
This is an incredibly boring task. Nothing new, just rewrite everything to just see it all rewritten again in 1 year. Perfect for LLMs and something humans shouldn't do.
While I agree with that statement -- that is also a lot of jobs. We have a lot of humans -- not every single developer sits in the innovation seat. The fewer the jobs available the less employable humans.
I think that rewrite - if AI enabled - owes its thanks to the legion of individuals who put their code up on the internet in the first place.
Weird times.
Unfortunately theres no thanks to the suppliers of training data. US courts made sure there’s no recompense for them, and likely never will be.
Seems similar to eminent domain, but without limitations.
> This is an incredibly boring task.
We all want super exciting jobs. But plenty have boring jobs like this. Between not having a job or having a boring job that pays well, the choice is obvious for many of us.
Are you defending doing boring work?
I personally never minded doing migrations. I guess I don't really have to anymore though. Weird.
The problem is that in many companies doing migrations would be the only job, thus now there is none.
This is just not true. In the olden times (pre-claude) devs were constantly asking to do full rewrites of legacy code. This kind of project is exactly the kind of work I've trained for and have loved to do for the last 15 years as a mobile dev.
This app has 15/20 screens, an app this small wouldn't employ many people to begin with. Before there was one guy (op) maintaining it in react native and now he maintains it native. I don't see much change tbh.
It ported overnight. I don't think it would create from scratch without a lot of hand holding.
Previous company I worked for would have (and did) hire dedicated swift/java mobile developers to build and maintain ios and android native versions (largely porting functionality from an existing web application)
Not anymore.
What's more likely (as others have said) is that the other thousand companies that can't afford to have dedicated staff would've just used React Native. So no jobs were lost, they weren't there in the first place. The places that have dedicated Swift/Java devs can now be more ambitious in what they build.
That's fairly rare. Most companies would use a compatibility layer instead.
Really? I’ve worked with plenty of companies that had separate native iOS & Android teams. I don’t know any that use a compatibility layer. Unless by compatibility layer, you mean a web view.
React native is an obstacle compared to what clear Swift/Kotlin code may produce. Swift is very powerful and Kotlin, in all honesty, is the first reasonable and very useful thing to come to the JRE ecosystem (save for Scala, which is, well, quite complex still).
Myself turned some python code to Swift, and keep doing so, without trouble or pressure. Of course, I've been doing fair amount of systems programming for 20 years now, so not sure what to advice newcomers. But this approach to dev DOES work for me very well.
Sounds like the advice to newcomers is to not worry about trying to learn a programming language. There already is an llm to program for you, and do it better than you could, so just learn how to talk.
Once you understand how to write a program get someone else to write it - Perlis.
[1] Epigrams in Programming:
https://engineering.yale.edu/academic-study/departments/comp...
React native is broadly an inferior option.
LLMs made it way worse https://ashishb.net/tech/react-native/
I assume having Kotlin and Jetpack Compose makes it much easier than it was back around 2020?
So now you have two vibe coded applications you don’t understand. I’m not an advocate of making “job security” decisions but this definitely goes to red flag territory. Was it your job to maintain the RN codebase or do you have other functions there as well? I’m not sure I would keep a native noob on a vibed native codebase. What is your take?
And there's no proprietary IP in your company's app that you don't mind being sucked up into the training data?
> there's no proprietary IP in your company's app
For most app that concept is "gone".
People routinely decompile and recompose existing binaries, and if you use "obfuscation" in your app it's still a small bump.
In today's age, IP is no longer a tangible concept that gives any advantages in software. What differentiates two businesses isn't their IP, it's their relationships and their moat.
Most vendors that had protected proprietary IP are now irrelevant within their vertical. What saves them are the protection provided by patents, which is public.
Are you saying you don’t trust ZDR claims from inference providers?
They don’t care about your code. There’s more and better data on the public web.
Isn't ZDR only the case if you "opt out" through a setting? Lots of opportunities to make a mistake here, or for the LLM provider to play games. You could be unaware of the setting. The provider could reset the setting upon subscription lapse/renewal, application update, model release, etc. A developer could accidentally use their personal subscription (w/ setting on) on a work codebase.
Also what's the timing on this setting's effectiveness? What if before you knew to "opt out" you used the agent for a refactor and your entire repo got sucked up in inference? But then you opt out the next day? Is it too late?
The mistakes you describe are only possible if the company doesn’t really think there’s proprietary IP in the codebase.
If a company really believed there’s valuable IP in code, there would at a minimum, ban laptops or ban code on laptops[0], provide and maintain a centrally managed LLM gateway[1] that handles authentication, billing and model choice, have MDM to prevent you from using your own Claude login, etc.
[0]: For example when I worked at Google, the proprietary google3 codebase cannot exist on laptops because there are no tools to download it to your laptop.
[1]: For example Claude code supports having a gateway: https://code.claude.com/docs/en/llm-gateway-connect
I'd wager many software startups out there would consider their code valuable IP (even if in the AI era it's not), and don't have these types of IT controls in place. Startups I worked at gave you an email account, github access to their private repos, and that was that.
Heck, you don't even need to mix up a personal and business AI subscription. For the vast majority of folks one day their IDE "updated" and a bunch of AI features suddenly became available. Free, no sub needed. A dev starts using them (because, why not?) and lo and behold the company's code got shipped out in an inference call and is now scheduled to be in the next training run. Oops.
You are merely describing companies that aspire to consider their code valuable IP, not companies that actually do so.
IDE updated? It’s the company IT’s job to perform testing before distributing those updates. And also their job to use whatever managed settings to disable those unmanaged AI features.
How's that any different from, say, Windows updating and backing up the company's code to OneDrive?
Actions speak louder than words. If the company doesn't even supply and require work devices, they don't effectively consider their code to be valuable IP.
Is Microsoft mining their customers' backup files looking for source code to ingest into their model training pipeline?
Of course the company can still consider their code to be valuable IP.
That’s the case with a personal subscription directly with OpenAI or Anthropic, but enterprise customers are opt-in, AFAIK.
And there are solutions around it from other providers and model routers. OpenRouter lets you explicitly say on a per-request basis you don’t want to be routed to a provider that trains on your input, for example.
As other have mentioned, the code isn't the valuable part. But also there are alternatives now to these LLM providers.
The value of most companies/apps are in the relationship with the customers, so it's the database, not the code.
Definitely agree. Most developers could build a basic Twitter or Facebook clone. The hard part is getting the users, content, and relationships that make the product worth coming back to.
Frankly there’s more likely to be proprietary IP in the server side code than in mobile apps.
True, but shops are exposing everything to Claude or Open AI. It's akin to outsourcing all manufacturing to subcontractors in China. That was cheaper, but extremely short-sighted. Now so many products have cheap Chinese knock-offs that are nearly the same as the originals because the subcontractors made both.
Codex with what model?
I think probably GPT 5.5, or 5.6 Sol - it was ~ 2 months ago.
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.
This has been my conclusion as well. Agentic workflows drops the effort level in keeping two native code bases in sync.
Same conclusion here. My current preferred setup is native for iOS and Android with common core in rust exposed through uniffi
I was surprised by your comments and then you do Rust to be called via Java or Kotlin and Swift?
What does your app do?
Yes uniffi created swift and kotlin bindings. The app I did with this is just a sudoku game https://www.puzzlesight.com . Before AI I would have reached for something like Flutter to avoid doing all work twice but with AI doing two apps makes more sense.
Okay, makes sense, the whole thing looks and screams vibe coded. On a beefy machine, navigating between your website pages takes 2-3 seconds. So still a long way to go with AI.
Next up, designing an even higher level language which will be used by LLMs to compile to high level languages like kotlin or swift. Just store instructions for LLMs in repos.
I hate to break it to you, but we already have it: it's called PHP
That Shopify employs 3,000 engineers is astounding.
I was rejected after a fairly basic ML interview at Shopify and when I asked for feedback I was told someday I could become a machine learning engineer.
I don’t think the interviewer read my resume or understood my responses as this was after working for several years in ML roles - staff applied ML and scientist.
So maybe that tells you something.
Why is it astounding? They have one of the biggest e-commerce applications in the world. A mobile app for shoppers. A payment system and mobile wallet app. A shipment tracking system. Tax and small business software. They have their own lending arm with its own software. They have multiple frameworks for other development teams to make super customizable e-commerce sites. They support Remix and Tailwind among other software. They have brick and mortar POS systems.
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.
Plus they have an Amazon-scale infrastructure to manage...
I think Amazon is very much on another level in terms of scale. Not trying to be negative about Shopify — they have a very large system to maintain - but Amazon is just on another level.
My 2 cents on this as a fellow RN dev & contributor. - The performance gains in native compared to RN (new architecture) are minimal for normal UIs (except games) - The most valuable feature which RN have is OTA updates, this has been a game changer for us and many fast moving companies. Ability to release and iterate at light speed. On native you are on the mercy of the app stores for review. - Silos of bugs on native > When you go native you might encounter bugs which appear only on either platform. - The project management of native teams is not always in sync - The teams often drift apart bevy iOS team might need 2 weeks just to make the app compatible with the new iPhone Fold (Duo) or Android team might encountered a blocker. Keeping them in sync for new features is really hard.
As an iOS Engineer that has been fighting the battle against every C-level type who brings up the subject of a shared codebase my whole career, I feel very validated.
They specifically say in the post how React Native was the correct decision and that it worked well for them.
Now it's a different situation as implementation has become incredibly cheap.
Not sure why someone would say it was a wrong decision. Why would they even need to do this if LLMs make coding easier. They are likely chasing the things I advocate for: direct access to latest APIs from each platform, platform specific UI, UI that behaves correctly on each platform without chasing down edge case solutions (also said as ui that looks and feels "right"), and a bonus of separate developer pool to hire from that knows the ins and outs of the platform without needing to hire a developer to know all three- react, iOS, and Android.
> Not sure why someone would say it was a wrong decision.
Writing almost anything with javascript sucks ass to begin with. Writing native code with it is even more painful. Most javascript engines don't even have any decent model of parallelism. It takes zero imagination to see the problem here
how much parallelism are you writing in your frontends?
The problem with everything being single threaded isn't so much that you want to do a lot of parallel processing, but that you don't want to have the occasional fat loop cause the whole engine to start stuttering. If you want butter smooth scrolling while there's (for example) a lot of dynamic content moving around, you want very precise control of the threading so you can get the gnarly stuff done without causing hitches that don't feel right.
The browser, iOS, and Android all use a main thread separate from the thread responsible for scrolling animations.
However, I think it's true that controlling threading in order to perform gnarly work in a separate thread is more ergonomic on mobile than in JS/React.
You'd need to create a Promise that wraps a Web Worker, which would be an unusual thing to use. I don't think most apps need such control over threading in the browser.
I mean, why would they admit to it being the wrong decision. Its a business.
Why would they need to worry about hiring for specific skills at all? As AI progresses, isn't the only skill that matters that you can drive it effectively (which encompasses testing and review) without needing oversight?
Because we are not there yet and you can't oversee something you don't know
> worked well for them
yeah because they don't care about a top notch user experience.
You should read the article. You'd realize that you're not actually vindicated by its contents.
I read it. They chose native over shared. Hence vindicated.
Derp. Read it again.
Shopify is moving its mobile apps from React Native back to native Swift and Kotlin. With the main cost of native gone, the benefits of staying close to platform APIs and first-party tooling win out. This has been my ethos. That native is better than shared.
Your argument was you've argued your whole career for native. The article argues only very recently the cost equation has changed. Your argument reads like you are not taking into account the broader context or the passage of time.
I'll put it this way, my argument was pro native. And in the context of the article, if a large company had unlimited resources, they would choose native. I'm not discussing the business case for it, but the end result of it being the better option. It can be seen as "Shopify tried Reactive Native and left it behind the second they could after sinking resources into it for 6 years".
Everyone always knew native was better if dev cost weren't a factor
Go back in time and read the react-native vs native debates. Many react advocates claimed otherwise
Time and progress have overtaken them. At the time they were likely correct but I certainly wouldn’t bother with react native any more when the LLMs have gotten so good
I don't see why you would, unless your argument for your whole career has been that LLMs make this easy.
My argument is that platform specific codebases is the right course of action. My point is that consumers can tell, the product is better, and developers are happier working on native codebases.
You're looking at it from iOS side only, and for a US company that would be the last platform they'd ever drop.
It was a different picture out of the Apple garden, when a company only brings their next major feature to iOS because they couldn't be bothered to hire the same headcount on two development teams and their CEO uses an iPhone anyway.
We had that discussion about a decade ago with a company rep that didn't realize 70% of their EU users were on Android yet their play store app didn't have the feature they were planning to promote.
Basically, better was the enemy of good for most companies.
Correct, I advocated for the solution that produced the best outcome for user experience, code and architecture simplicity, and prevented having to rewrite an app in the future in native. Which has been validated here.
The android shortfall is a real one but I also pushed for hiring native android developers too.
We'll have to wait and see if the extra maintenance / bugs / attack surface is justified. This an announcement of future direction so vindicated is certainly premature.
They're right when it makes business sense, which is also about cost and why Shopify didn't do it before.
I'm not arguing the business sense. Two sides can be right which is why I advocated for native development. Which is vindicated here.
If you weren't arguing against the business case, what were you arguing with the C-level types about? I don't think I have ever heard a case for react that wasn't centered around shared codebases mean fewer resources/cost/time to deliver a feature.
In other words your team also resigned the next day ?
> developers are happier working on native codebases.
Agents are happier working on any codebase, but ultimately Shopify and other companies want iOS native app level quality without the huge cost of hiring many native iOS / Android devs.
LLMs and Agents deliver on getting a native app out at lower cost, higher quality, faster all at once.
I think everyone is trying to tell you your skills as an iOS native dev have been commoditised and Shopify and others don't need to hire anymore native devs to find this out.
I don't see how your job being completely commoditised and cannibalised by LLMs replacing your job is some how vindication?
This is just like saying "we won the argument", but what did you actually "win"?
Yea, I hear that. I'm content with winning the argument and truthfully, I think they will find they need to hire iOS engineers because we do more than write Swift. There are whole ecosystems of knowledge to go from a product idea, sit in meetings with many stakeholders, and implement the actual thing everyone wants. All they got here was a 1-to-1 implementation of their current app which was born of engineers working through real constraints. It says nothing of new features that have to play nice with other pillars of the company.
> I think they will find they need to hire iOS engineers because we do more than write Swift.
Shopify isn't hiring any mobile engineers.
Probably because the agents were hired first and took the job already.
That is the point of the job being literally commoditized and cannibalised, they hire less or close to 0.
Your quixotic 'vindication' means nothing and has the opposite effect.
Not sure why you are defining my vindication. Its purely rooted in native is the better solution for mobile apps. Which they are using. Not sure how that makes it the opposite.
probably because every react native app they've used feels like shit
FWIW, the native app specialists are in some sense the most invalidated here. Shopify decided they couldn't afford your skill set and didn't change their mind until you could be replaced with an LLM.
Really the whole concept of technology specialization is the thing in jeopardy. It no longer appears to work to make a career out of deeply learning something obscure. Agent-farming generalists appear to be the ones who own the future right now (if, heh, not the agents themselves).
My validation is that platform specific codebases is what is the right course of action. The c-level decision is that they want the cheapest route to consumers. My point is that consumers can tell, the product is better, and developers are happier working on native codebases.
I'd challenge you to determine which of the top app store(s) apps are react native vs not -- plenty of app store awards have gone to react native apps -- bad software is bad software. plenty of you ios devs write shit software. I've done this job almost 40 years and no language or platform has ever prevented people from building shitty software or for that matter gotten in the way of writing good software. good engineers can figure it out.
source: ios dev since it was possible -- I am not even pro react native, I am just pro merit based arguments -- you aren't making any
Challenge not accepted but deferred to the article where one of the largest business wants to sit at the intersection of native apis without a a middle layer for the sake of saving money. Put another way, given unlimited resources, native wins out over shared.
If only LLMs had been invented at the beginning of your career, you would have been right all along!
Same here. Glad I stuck with native iOS development. I still haven’t switched to SwiftUI though (except for some small stuff). Still sticking with UIKit here.
what they should've done is written logic etc.. in rust and use mobile app just for native layers, so they can still share code.
I agree w/ advising people to move off React Native, though I think the story that "LLM enabled an otherwise too-expensive migration to consider" is not correct.
I say this because I was part of a migration from a mid-size React Native app to a Swift/Kotlin native app redo. I did the majority of the technical work on it. The majority of the work occurred before January 2026 and without LLM code assistance, though later features in the app definitely used some.
For anyone considering this, I'd say that the migration is definitely worth considering without even taking LLM assistance into consideration. The continued React Native tax of unnecessarily difficult upgrades, impedance mismatch w/ underlying core frameworks, and incredibly uneven library quality just cause your business to really spend a lot of time shepherding the tech over the finish line. It's pretty wonderful to be back in the world of "build, compile, ship, be sure". One thing as a fundamental principle that I think the Shopify article 'gets' at, is the importance of the feedback cycle - investing time in our integration test story very early on both helped w/ my cycle times, and later in providing guardrails for LLM assistance.
All to say that this decision is worth considering without even taking LLM assistance into account.
> The continued React Native tax of unnecessarily difficult upgrades,
My very first experience of RN was having to update an app to handle the mandatory change to 64 bit APKs
Which required a massive update not only to several dependencies but also xcode, iOS frameworks, the weird objective C caches that get smuggled into node_modules, _as well as_ all the rigmarole or making the 64 bit APK build work
It was completely miserable
I experienced the same issues but went the other way and migrated from React Native to React. Still one codebase but none of the issues. Performance was better too even though half the code stayed the same.
We don’t hold on to a decision just because it was successful at the time. When a core assumption changes, we’re willing to go back and ask whether it’s still the right call. LLMs changed one of the core assumptions behind our 2020 decision, so we reevaluated our mobile stack from first principles.
What we found led us back to native.
Yes, AI have changed the game, and now you can build and maintain two separate projects in Swift & Kotlin instead of one on React
If AI can make any language do anything, why move away from React Native ?
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.
Others mention quicker startup of the app, more native-look, less head-ache w/ RN.
Thanks Mustafa! This was a great article—I'm curious, did you consider the non-technical / organizational costs in keeping the two codebases in sync as a separate factor? Do you foresee more organizational overhead as part of this decision? How are you planning to manage that? E.g. small implementation difference between the iOS and Android app increasing the support burden or bug burden and causing duplicated team effort.
This is not the author. It's very likely Farhan Thawar, head of eng at Shopify
Thanks for the write-up. I'm curious if there's a shared core between the iOS and Android apps (e.g. KMP or Rust), and if so, what that looks like.
Also, any plans to open source Helix?
I suspect we'll see a lot of large orgs doing this in the next year.
Perhaps. I can absolutely see that being more attractive especially with things like the Duo where, I assume, SwiftUI gives you a number of things "for free".
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)
Your assumptions are very outdated. App Store review times are typically < 24 hours and have been for the last couple of years. And KMP makes cross-platform a real thing now, rather than hacking a web view into a native shell, which was always the worst possible user experience.
Apple has started automating them a while ago so a lot of them are indeed <24 hrs. I wouldn't say they are wrong though.
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.
When it takes longer than 36h, just revoke and submit again. It's probably just stuck in some queue.
Or https://developer.apple.com/contact/app-store/?topic=expedit... - I've had good results from their expedite tool.
I'm afraid you are the one out of date here. App Store Review times have ballooned in the last few months. Marco Arment talked about this publically (on the ATP podcast) about how his app was stuck in review for over 2 weeks IIRC and I've seen 2 days as the minimum review time in the last few months with some taking a week or more.
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.
This is only anecdotal, but I had a review on a brand new app turned around in ~6 hours 2 days ago. A lot of it has always been luck of the draw, though, granted.
I agree it's anecdotal but that's all I have to go off and global averages don't help me at all. The problem it's a complete crap-shoot. You have no way of knowing if you are going to get a quick turnaround or a long one, it has zero bearing on if it's a new app or update or the size of the update, it's completely random. I cannot plan around random which is why I've opted for web-tech-based apps (Capacitor) with OTA updates so I can get fixes out just as quick as I could get webapp updates out.
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.
It's also dependent on when you file. My reviews seem to come back around 2-3 AM Eastern; I presume they're overseas contractors.
Doesn't KMP assume your team is comfortable working in Kotlin?
Well, it assumes the model is.
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, that's fair. I'd argue, though, that the training required to get your team up and running should be fairly minimal - Kotlin is a very easy language to pick up, especially for people coming from TS - and will pay off dividends in the medium to long term.
You get all of those, to some extent, if you use React Native. You still need to do reviews for significant changes due to app store rules but you can OTA update most changes without waiting on a review. Even web support is there.
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.
> I can absolutely see that being more attractive especially with things like the Duo where, I assume, SwiftUI gives you a number of things "for free".
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.
https://www.runway.team/appreviewtimes
I'm sorry but that data does not at all square with my experience. I'm seeing 2 days+ as the average and I haven't seen sub-24hrs in months. I oversee ~20 apps and I can tell you iOS review times have been trending upwards for the last few months.
Apologies, I used to use appreviewtimes .com [dead], which scraped tweets and was pretty accurate, but is dead now. I posted what seemed to be a decent replacement, but will take your word it’s not.
Edit: was going to update the earlier comment but just hit the 2 hr mark.
For all I know it is accurate for them but I encourage you to hover on the bars and see the min/max. That's where the issue is. I wrote more about it here [0] but the TL;DR is that it's wildly inconsistent, sometimes it can take a few hours or <12 hours and sometimes it can take a couple days. It's impossible to plan around and nothing drives me crazier than having a fix written but waiting for Apple to get around to reviewing it.
[0] https://news.ycombinator.com/item?id=49645559
Definitely makes sense for a large org with massive resources (such as Shopify) to do this. But for everyone here pondering what to use for their startup or a smaller project, there are still important trade-offs. In the past few years I've launched multiple cross-platform Flutter apps and multiple native iOS and Android apps using Jumpstart iOS and Android (native templates from the GoRails guys which leverage web views from your Jumpstart Rails server). The latter gave me web, iOS and Android out of the box and was vastly less costly to build, even with AI. For entrepreneurs who like Ruby on Rails, Jumpstart is my favorite for launching rapidly, and since the mobile apps are easy-to-modify iOS and Android projects, it's designed so you can either add more custom Hotwire Native Bridge Components or just write Swift and Kotlin to replace functionality with native code. Eventually you could write away all of the Jumpstart webview stuff, but you'd only do that if you had more runway, like if you have plenty of time or you start making lots of money. I've worked for clients whose ideas failed--not because of my code, of course. :)
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.
Still loving flutter over here!
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.
I’m surprised we aren’t seeing it more already. LLMs suddenly make it reasonable to maintain multiple native apps. I’d love to see this start to supplant Electron and its ilk on the desktop.
Any education required for engineers to switch to native or the agents are handling the details on their own? Wondering if architecture or the new languages require ramp up.
Definitely, we invested in ramping up teams on native before going all in.
Did you switch to SwiftUI or UIKit?
They created a mess in 2020 and hopped on over to a job at FAANG and now a fresh batch of Waterloo graduates want to do the same - maintaining somebody else's turds is beneath a Waterloo graduate on his way to becoming a manager who never touches code ever again :)
So it goes.
Yeah. No way we’re getting the full story. It probably goes something like this… we lost native engineers when we switched to React then we lost the engineers that were supporting react recently and won’t be replacing them because stock market. Therefore we’ll switch back to native and go with under skilled engineers using llms. This will work until we have a code base model collapse
It seems like Shopify has fallen into a trap thinking that more complexity costs nothing because of AI. In the age of AI we have to embrace the same principle as before that complexity needs to be tamed, not multiplied. Even as humans struggled with complexity, from what I see now AI struggles very much the same. Hence I don't think this will age well.
Another scary thing is with AI it's easy to let complexity get out of hand to the point where a human manually writing code is basically impossible. Even though AI might seem capable of handling the complexity, you'll start noticing all these weird bugs pop up all over your codebase.
I'd say that was even a goal of the AI companies. It's not in their interest to generate human-maintainable code
We should understand the complexity we are adding but having LLMs as a tool does also make managing the complexity easier.
Always relevant - https://grugbrain.dev/
Yeah the problem is AI would improve exponentially and can do work 24/7
any engineering problem is just 'when' and 'how much' at that point
Yeah but engineering is still subject to failure modes, AI can't circumvent that short of formal proofing (which nobody really wants to get into)
Models have gotten a lot better at generating native iOS apps. The main appeal of RN was being able to leverage your web devs for mobile dev. that's what I did at my last company. And it's fine for a startup, but eventually you want dedicated native engineers bc each platform really deserves its own technical masters who can optimize for it.
But now that all code is generated, there's little upside to having an RN app... just start native. Your devs are barely going to be writing code anyway.
Nobody is talking about the real advantage of RN: Being able to release to the App Store without having to go through a review. That's so massive. Getting a bug fix out to users instantly, sneaking in optimizations, etc..
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.
Over the air updates is SO valuable with react-native. Being able to ship hotfixes instantly to our users has saved our asses multiple times.
I’ve worked with both native and cross-platform. I think the mentality of being able to make changes quickly without much review often comes from cross-platform, especially when the developers come from a web background.
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.
> "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.
[0]: https://github.com/cashapp/zipline
Totally depends on your business model too. We have clients that often require quick changes for compliance reasons, and they need to ensure all users of our apps are congruently updated. That’s not easy without OTA.
This is so true, and I'm surprised that Shopify didn't mention it or that they don't use OTA updates.
Are you saying a native app can't make an http request and update the code they JIT?
It can download Javascript (or other interpreted language, or config data), but you generally can't download and execute new compiled native code on iOS, due to iOS code-signing/executable-memory restrictions.
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)
Pardon my ignorance but can't an iOS app host a WASM runtime without being a browser? And if so it doesn't need to be an interpreted language necessarily.
I am fairly certain this is against Apple's policies. In principle you're not supposed to change the functionality of your app without review.
i don't see any difference between wasm and js? If react native apps can be updated with js, wasm should be allowed.
I think updating js without review is also against policy.
It's a grey area.
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.
Yes, it could, but then you would have re-invented React Native. But in WASM.
Yeah, but to my understanding that’s not what Shopify is doing.
Doing so would require the app to have the business logic written in JavaScript. Apple only allows JIT’ing JavaScript using JSC.
This seems to be a weaker claim than "RN is needed to do this", but practically speaking it might amount to that.
Sure you can choose not to adopt React’s reactive paradigm and manage state directly but using JavaScript. My understanding was that in RN, JavaScript code manipulates C++ objects in the C++ part of RN, which then calls host platform code to create views and render.
Precisely. That has always been prohibited both by technical measures and by the App Store review guidelines. Especially on Apple, but also on Google Play / Android as well.
This is true in a very real sense – models can help you build native apps very quickly, no question. But how do you keep them from drifting apart from one another as you add/change features or design? Right now, there isn't much tooling for this.
React Native's advantage of having a single source of truth for code hasn't quite gone away yet, imo.
You create a source of truth which defines all the features and requirements. This can be UI tests, MD files, database, diagrams, whatever that fits your use case.
I've only read about it from it showing up on hn[1][2], but you can use slick to convert your swiftui to jetpack compose for a andriod build from the ios source of truth
link to project: https://github.com/skiptools/skip
[1] https://news.ycombinator.com/item?id=41384144 [2] https://news.ycombinator.com/item?id=46706906
i think you would have your coding agent work on both code bases at the same time. You could also task with generating identical tests for each platform. It's easier for a model to keep up with that kind of tedium than a human. Plus you can just tell the model to keep re-doing things until you're happy and it won't quit.
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.
I don't understand the question. If the model built both apps why wouldn't it also be building the new features on both platforms at the same time?
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?
the problem is that single-source advantage gradually falls away as you develop your software into something that feels good to use on each platform. and once you have a quality product you're left with perfunctory coupling that makes it harder to adopt the latest platform features
Android and iphone emulator MCP, model compares screens, flags is theres drift? Something like that I’d guess
But the screens should look different, right? That's the point of building separate iOS vs. Android versions is to make each version "native" to its platform. The feature-set should be the same, but the interfaces can diverge.
I think the whole native thing is more for better performance, debugging ease and dependency reduction rather than seeking variation in UIs.
Tests? Not being flippant, but that strikes me as the new surface to maintain to get what RN used to offer
"GPT-8 Galaxia - figure out where our iOS and Android apps show different doohickeys and fix them"
> You're completely right to call me out on this. Here's the real smoking gun: the iDoohickey isn't a real API interface on iPhone
You always still needed a specialist per-platform even if most of the code was RN or KMM[0]. But I agree - a thousand not-great mobile apps sprang from this idea.
[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.
> a thousand not-great mobile apps sprang from this idea.
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.
Hello! As I'm on Android, thank you for your service.
> The main appeal of RN was being able to leverage your web devs for mobile dev.
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
> The main appeal of RN was being able to leverage your web devs for mobile dev.
> 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.
If you put every company that needs/has an app on a spectrum, there is a line somewhere that roughly divides them into two groups: where Electron/React Native/etc. makes sense or not. It's just a normal engineering decision: solving problems given limited resources. Companies have different problems and different resources.
I think people in the tech community have probably also noticed that it's rather popular to have an absolute opinion on the goodness or badness of these tools. There's some magical thinking borne from ignorance that everyone just ought to go native or that React Native is the best thing ever to be used everywhere or that AI makes this line disappear entirely.
I think these takes serve little value and distract from what’s interesting, and what the subtitle to this article says: that this line is moving due to AI. And I think that’s probably right.
And the “makes sense or not” part can change based on a bunch of factors.
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).
The main cost of two engineering teams shipping identical products in my opinion isn't the cost of those extra engineers, it is in the product and organizational challenges of keeping those two products that need to be identical in sync. I am very bullish on coding agents but would be wary of this turning into a mess.
But here's the thing, across operating systems the products should not be identical.
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 took "identical" as in feature wise. The user should be able to accomplish the same things, no matter what platform they're using.
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.
The solution is to make the common features a part of a statically-linked library that you can pull into your apps. A web app is, IMO, never the answer when you want to address multiple audiences. It is bad for accessibility (because 99.999 percent of web app developers never consider accessibility) and it doesn't solve the problem that web apps are trying to solve (having 8 code bases all that have to remain in sync) because you will inevitably need your code to handle platform-specific differences, standards/conventions and whatnot.
Why does Shopify need to use Apple's or Google's branded design language in their app?
Because if I’m an iOS user and used to that and you give me a conventional Android app UX, I’m going to feel that as jank.
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.
What specifically are the ux differences?
I don't know iOS so I can't say, but a good UX does depend in part on platform expectations and every system historically been different. The compromises mean the each have good reason for what they do (sometimes anyway), but switching is hard.
I've used both in the past 2 years and can tell you these particular systems aren't meaningfully different in any way that affects third party apps.
I'm only familiar with iOS and this is the type of question that an LLM could answer better than this specific human.
There is an implication here that the back button is a microcosm that represents the differences holistically but it's not. It's a small one-off exception that doesn't even affect the design choices made for the various apps. As I open up app over app on my Android (Audible, Spotify, ChatGPT, etc.), they all have clear in-app "back" functionality where needed. No apps I have installed rely on the Android back button exclusively. Also, none of these apps have any design elements that follow Android's design language.
The back button works at its best when it closes an app and it restores the one that opened the previous one. There could be no in app back button to do that. However the back button used to be an always available hardware button or a touch one on the bottom bezel. It's optionally visible now (I'm on an old Android phone so I'm not up to date with the latest OS) or a gesture, right? So app designers must design as if it does not exist.
I agree. Design as if it doesn't exist incidentally is also how they design for iOS where it doesn't exist.
Also, the back 'button' is mostly a thing of the past in Android and it's more similar to iOS now with the predictive back gesture.
The Android back button is legacy.
> keeping those two products that need to be identical in sync
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.
This is a great point that I wish the Shopify article went into in more depth! Would love to hear if they considered this
I believe they have a more in-depth posting that talks about it
https://shopify.engineering/shop-app-migration
The blog post doesn't mention the personnel-related challenges with having two native platform teams working on the app.
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
The result of that native platform APIs side project involving six devs converting the app's major user workflows?- 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
Agree to a point, but human resource is literally the main cost in most businesses, so there's that
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
Very true, especially when there are different turn around times and review policies for the various app stores, things can get out of sync quickly
Assuming they have a robust feature flag and experiment pipeline in place they are trying to solve a much more complicated version of this
> it is in the product and organizational challenges of keeping those two products that need to be identical in sync.
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.
The capabilities of Android and iOS don't meaningfully differ for the purposes of Shopify; Shopify doesn't need LIDAR. Most large brands throw the UI design patterns of the platforms out the window in favor of their own UI guidelines.
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.
> Most large brands throw the UI design patterns of the platforms out the window in favor of their own UI guidelines.
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.
They vary in terms of architectural patterns and ui widgets. RN tries to prevent a single interface, but you quickly reach the point where it becomes a pain. You can use Expo to help, but their libraries are unstable.
Yeah, massive parts of our community and ecosystem miss that something can be right today, and wrong tomorrow, and having to change along with your users and needs is OK. You'll never be able to anticipate what the business needs in the future, so stop pretending your software design can be done once and then just coast on that, because that's typically not how a software project should be run long-term or even medium-term.
The problem with tomorrow is sunk costs. There are many places I wish we had made a difference decision in the past - but we need to balance that with cost to make changes when what we have works okay.
There's also a recency bias, where you ignore how valuable some decision was in the past and ignore the fact that you maybe wouldn't even get to the place you are if "you made a different decision in the past".
I can't count how many times I've said "this is really bad, I it is worth rewriting to fix all the issues", only to discover that there were good reasons for all the past decisions and so we end up with the same mess as before - except that now I know what it must be that way.
Not always, but very often people in the past had good reason for what they did.
Those are the comments that should persist in the code. I hate when the AI edits and removes my "why" comments. I want the refactor to make it less messy but keep why it's that kind of mess.
Too Soon often we thought those were obvious and didn't comment. Meanwhile there are detailed comments about things nobody cares about.
I just put a comment in yesterday for this very reason - there was a flag I had set to false, and then looking at the library docs for something else thought maybe it should be true but that doesn't work how I would have implemented it if I had created the library and written the docs how I 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.
As relevant today as it was 26 years ago: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
See also: Chesterton's Fence
In my experience it comes from the business and people who think if we need to touch the same code twice in the same month it is somehow a moral failing of some kind.
Another factor is design.
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.
> 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.
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.)
I think you contradicted yourself. If a tool provides better value for the time spent for a company, I don’t understand how you can call it objectively bad.
You can say it’s objectively bad from a technical perspective, but clearly that’s only one part of the equation.
I think they were speaking as a user. These tools create inferior products. (Still not technically objective, but true nonetheless.)
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.
I am so tired of existing react/electron applications being compared against imaginary, hypothetical "native" applications.
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.
It's always the preference of people defending bad decisions to compare them to doing nothing.
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.
The app not existing would unironically be better in so many instances, though. The web version doesn’t take up 1GB of disk space, install persistent services, send you push notifications by default, and it’s trivial to block ads in comparison.
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.
Hard agree. Day by day, I become more exhausted with "apps" as they are currently delivered, with native being slightly better than cross-plaform, but not good.
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.
Yup. Now we have a choice of either using a terrible website with popovers and cookie bars (never remembering the choices) or apps that have insane onboarding, and bombard you with ads through notifications, with zero benefit.
I'm not the OP, but my understanding (and I agree) is that it can seem like a better value when a subset of factors are considered (ones that IT can measure, biases in IT against Apple etc.) and it leads the company into making a choice that is worse for them overall.
It's objectively bad because of how hot my phone is.
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.
What really grinds my gears is Microsoft replacing native apps with Electron. Trillion dollar company who is so cash strapped they have no choice but to punt to the easy development path.
The thing that makes Microsoft's case particularly annoying is that they have demonstrated how they can develop half-decent Electron apps with VS Code, but have simply elected not to with anything that's not VS Code.
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.
> they can develop half-decent Electron apps with VS Code,
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.
Also they bloated it to death. VSCodium gets you the same solid core app without the oodles and oodles of useless "features" Microsoft has bolted to it.
Yikes. What apps have they been doing this with?
Turns out I was mistaken. Outlook was rewritten for Webview, not Electron. So still took a native application and turned it into web nonsense, but I got the specifics wrong.
Regardless, there are a bunch of new visual glitches in the release, with regressed performance all over the place.
What's extra egregious there is I do understand the logic because developing for Windows is such a fucking nightmare, that they're also responsible for.
I assure you, developing for competing platforms is also a fucking nightmare... that's something Microsoft has no monopoly on!
And I assure you, developing for Mac is a delight, and Linux is not so bad either. Windows, however, fucking disgrace.
Nuance is always a thing. Native apps are faster and better most of the time. Electron and React Native wouldn't annoy me so much if they were used with small apps where it's not worth over-optimizing.
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.
React Native apps make more revenue than Flutter and Native apps according to Revenue Cat report published on June 3rd, 2026.
https://www.revenuecat.com/blog/engineering/why-react-native...
I would rather have the opposite? I don't want 10 people making small apps that use Electron. I would rather that be used for bigger apps where the overhead is negligible.
> These tools are bad, objectively! They give inferior user experiences, and waste resources (ever more important now with RAM prices what they are).
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.
I don't have any actual experience with React Native and Electron, but with that caveat out of the way I personally think tools get far too much blame that should be on developers.
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.
A shitty developer can create a far worst experience on react then on native.
Most developers cannot make any experience on Native.
Yes but only because they can actually ship the react app
Most enterprises are comprised of a high proportion of shit developers. So you need to work with what you got
> React can render at more than 60fps if necessary, and if the code isn't shit.
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.
Yeah, obviously your average React app has no need to render anywhere near that frequently. The ones I've worked on will generally only render as a response to user action, server event or polling.
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.
None of this matters anymore.
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.
Yet, neither ChatGPT desktop app nor Claude Code CLI is native. Mind you these are made by companies with practically infinite tokens.
These apps predated LLMs "getting good".
Both have an enormous number of paying customers and you don't just disrupt that for a language change.
Anthropic literally rewrote the whole runtime CC is based on in another language. And even then they still not dared to migrate it away from React.
Zig -> Rust is straightforward and is a good advertisement for their model.
React -> Rust is ambitious and the models aren't there yet.
Soon.
FYI I've been building an app, Android first, and discovered the magic of Kotlin Multiplatform. The LLM modularized everything so that it's substantively the same code base, but with Swift only where it's needed. Still working through it, but it seems like a great and underrated platform to build on.
You're not emitting the code yourself anymore. The platform ease of use for humans no longer matters as much (if at all).
Preference for a native feel, solid software, bugfree code, compile/develop velocity, LLM friendliness.
We're in a brand new world.
I'm building an app that targets Android, iOS, Windows, Mac, Linux. There's no way I'm going to be maintaining 5 different codebases, even with LLMs.
This is one of those “oh gosh” posts at first glance, then you actually think about it, and it’s 100% correct. Python, Node exist to save the precious commodity of developer time. Once that’s no longer precious, best value comes from purified custom Rust, no attack surface from huge libraries, optimized performance for the specific task on all possible hardware.
Windows desktop native is WinUI 3 and Windows App SDK, for better or for worse. No amount of Rust and tokens will recreate everything you get out of the box with that stack. Native needs to feel native.
The last time Windows UI felt native was maybe Windows XP. Maaayyybe 7, if we are generous. It also has to do with sluggish or no feedback by UI widgets, due to the trend of flat everywhere.
not sure why you're getting downvoted. but if you're building even very popular applications, it is quite easy to see how LLMs are very well suited for this type of consistency job.
- they follow instructions quite well.
- are tireless at doing mechanical ports between languages and frameworks.
- Can understand a new ecosystem quite well.
Then why aren't people doing that? Microsoft has as much access to cheap tokens as any software company around, right, so you'd think they would be leading the way.
I'm sure these things are in the plans from upper management.
we'll know when the next layoffs hit.
they probably are but have some patience.
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.
I didn't downvote but I'd expect downvotes for a completely unnuanced thought terminating cliche that ignores everything in the thread. AI fanaticism doesn't help but lots of people don't get downvoted for that alone.
A well built native app can still serve as a vector for harvesting personal data in ways you cannot control. A web app is inherently superior because of its security envelope.
A React Native app would have all the same access to your personal data that a native app would
That isn't a web app.
A badly made native app is worse than a well built react-native app. There are plenty of anti-patterns that will ruin your native app.
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.
> A badly made native app is worse than a well built react-native app. There are plenty of anti-patterns that will ruin your native app.
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.
I think they also got sick of supporting those open source libraries.
> 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.
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.
> For a while it seemed that having deeply held, nuance-free opinions about technologies was a sign of being wise and experienced
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.
Strong opinions considered harmful
Strong opinions tightly held
I try as hard as I can to have strong opinions, loosely held
Blind conviction without nuanced considered harmful.
Using cross-platform web technology is absolutely a nuanced engineering decision that is the right one for many businesses. What is categorically bad is bundling a standalone browser runtime for every single service, wasting user’s storage and memory when you could just have a website in a browser.
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.
That decision is easy: do users leave bad reviews for bundling a few hundred MB of Chromium?
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.
Much of Hacker News seems to be incapable of understanding the average user doesn't care about memory use at all, beyond a few extreme examples.
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.
> Much of Hacker News seems to be incapable of understanding the average user doesn't care about memory use at all, beyond a few extreme examples.
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.
That's true, but greater efficiency isn't going to sell more software if the users don't know they need it.
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.
Bad reviews?
Haha. I completely replace the software with a non Electron alternative if available.
Who cares, unless you pay?
A one star review, on the other hand, can have a material impact on the search ranking and consequently my revenue.
I stand corrected. I will leave one star reviews from now on.
It's funny how folks can't even get that number right. Depending on how much you care to optimize, Electron adds 50 to 80 MB to your application. Those multi hundreds of megabyte apps? Yeah that's not because of electron, that's things like "we couldn't be bothered to actually think about the assets we bundled in". 100 uncompressed 16 bit PNG? Sure why not. 20MB worth of fonts because we don't like the built in ones and no we've never heard of subsetting? Let's go. 50MB worth of .json data files that we couldn't be bothered to gzip first? Who's going to notice!
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.
Are you defending Electron apps? The audacity :)
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.
First off, RAM is not app size, and second, the point of having RAM is literally so it's there to be used. Sure, Chrome is absolute nonsense, but Electron is not Chrome, and an Electron app using 300 MB in memory where data needs to be uncompressed and directly accessible when your computer (including your phone) has gigabytes of the stuff to work with is just... irrelevant? That's pretty much pretending there's a problem for the sake of wanting a problem.
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 =)
I could not disagree more.
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.
Sure, cross-platform frameworks were great. I do think LLMs are changing the game, however. If you have a robust set of tests, it's much easier to maintain native versions of an app, compared to the past.
Apart from the hassle that OSes put in the way of PWAs (intentionally, but that's another topic), a local Node app simply has a different kind of system access compared to a web app.
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.
Is everyone wrong, or is there more to it than you can see from where you stand?
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.
its sad that the only reason warranting this switch is AI.
I would have loved to see some performance benchmarks on some critical app flow.
These takes are also a bit premature. Wait until the new apps have rolled out and users are happy.
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.
There’s risk to doing anything. There’s risk to doing nothing. A bit off topic but my perception is that organizations bias towards doing something more often than they should.
Agreed. I felt the same way when a long time ago when Airbnb made a big deal of going back to native.
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.
Well written and good perspective
Absolute opinions are simple and travel better on media.
"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 think this is something we’ll see AI very meaningfully impact — the threshold needed for “Get this thing working on a tech stack we might not be familiar with” has gone waaaaaaay down.
It's worrying to say the least. Today it's "get this working", tomorrow it's "can it also do XYZ?", next week it's "we have a 40% spike in crashes, you MUST resolve this IMMEDIATELY!"
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.
Yeah. It’s also far too tempting and far too easy to keep adding features if you don’t make yourself disciplined about it (which is okay if you’re in a position to control that, not so good if it’s the higher-ups demanding it).
I first learned about the shopify app when I saw a purple "shop" checkout button. Next, I got an email saying that if I wanted to track my package I needed to download an app. No thank you. I don't want your app on my phone. I don't want to browse other stores in the shop app. I want to see my package and its status without enjoying a new "social shopping experience" or whatever.
I now avoid buying things from anyone who use the dreaded purple "shop" button.
Thank you for coming to the HN comment section and sharing your brave story
I've been trying to minimise the number of apps I have. Every app needs to be justified in that I actually need it, and there is simply no way it could have been provided as a website.
true absolute cancerous bs
Never bought anything that used Shopify and never will. As a Canadian, Lutke is just a pathetic individual and I simply refuse to use anything he touches if I can avoid it.
And I'm just sitting here looking at the Codex desktop mac app wondering why a list, a chat window and textbox require a 579 MB download (compressed) and 4 GB of RAM.
I'm working to solve this...
An entire copy of libreoffice, for one.
Dropping React and going back to raw JavaScript next?
I am still mourning pre-React GitHub. Maybe rose-tinted glasses, but it was so pleasant to use
I would attribute that more to culture.
For example https://diffs.com/ is built in React and it's basically instant.
I would attribute it to physics.
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.
Which is also, or at least has also been a culture thing, because of the
"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.
You'd be wrong, diffs is vanilla js with a react wrapper.
Is it? I looked at the source but it doesn't appear to be react. It has a React API but also a "vanilla js" API and when I looked at the code it seems to be doing everything by hand:
https://github.com/pierrecomputer/pierre/blob/main/packages/...
... albeit using React inspired terminology like props and hydration.
Dropping Javascript and going back to native yea
I don't think UI frameworks will go away any time soon. They solve a very different problem from React Native.
A multi-billon dollar company dropping quarters (performance/ux) to pick up pennies (development savings from not maintaining a native app) never made mathematical sense to me.
[ aside: Meta founded the development of RN and they don't even strictly use it; plus, any troubles/hacks they need, they can make to the Framework itself ]
What if you could have both great performance and UX for each platform AND a single codebase?
Sorry not sorry RN was always the wrong choice, and I've made my money shipping React since 2013. Every RN project I've had to join has been a junk show and there is no way they operate more efficiently than 2 native teams. Don't even start me on Expo. Kotlin and Swift are nice, and ObjC/Java are still approachable IDK why people act like native is a big ask. I see people are in their feels already but I'm so glad so see Shopify stop carrying the RN banner, this makes giving the right advice to my clients easier.
So, instead of paying humans twice for the same thing, Shopify will pay corporations to burn the planet a little bit more, waste water and energy - to build the same thing twice. Just because. There's no tech reason to do it. "LLMS are better now". There's no low level optimisations, no blockers, no app shortcomings, it's a shopping app for Christ sake. Instead of optimising, creating more with less, they will create the same with more. Yeah, that's smart. Super smart.
> Just because. There's no tech reason to do it.
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
Ridiculous, the amount of energy saved from a faster native application over how ever many million users will be far greater than the amount spent to generate the tokens to do so
Can someone explain the waste water thing to me, because unless they’re separating it into H2 and O2 how is it possible for water to be wasted?
It's the cost of water processing and delivery, infra (plumbing) maintenance, chemical treatment...
quality ragebait
Not mentioned but this also gets them away from what now seems monthly npm supply chain attacks.
Big win for security
You don't have to ditch cross-platform building entirely just to escape dependency hell
No, but it’s a nice bonus
Do you even escape dependency hell this way?
Yeah, with iOS for example, you typically need very little third party dependencies for functionality. The main ones are things like analytics, crash reports, etc
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.
It's a developer decision. But I'd say it's easier to not use dependencies on native because there are more capable system API. I don't use any in my iOS apps, and only one dependency in 20 macOS apps.
I was excited to hear some details about how LLMs are changing big companies' workflows. This is a fairly straightforward problem and good on them for discussing it. My first gut reaction is that there is no way I would let LLMs write a significant amount of my codebase. And then I remembered that not invented here (NIH) is a problem I have. If I let it decide what code I ship, I am making the same mistake as writing all my code from scratch. When I find myself worrying about alignment, that is what rigorous computer security policy is for. If it's not catching serious bugs written by LLMs it's not catching bugs written by people. Treating my own code as if it was written by someone else is just another part of computer programming.
The one topic that is almost not addressed in this post is: what happens to the React Native developer team?
Technologies are never the issue. The people is.
I'm sitting here at my desk overlooking Cordova Street. The street that Apache Cordova is named after. I've seen this debate for almost two decades now.
Teams jump on the latest cross-platform framework assuming that it will reduce headcount cost at the expense of having a lowest-common denominator app on each platform.
The latter is true but the former is false.
What ends up happening is that teams start as 20 iOS engineers & 20 Android engineers. They adopt something like React Native. Then you end up with a team of 20 product engineers and 20 tooling and framework engineers.
I've seen that countless times in the last two decades.
> I'm sitting here at my desk overlooking Cordova Street. The street that Apache Cordova is named after. I've seen this debate for almost two decades now.
The debate has been taking place on the actual street?
We practically heckled and threw rotten tomatoes across it at each other.
I’m curious who was across the street from whom, I’m assuming Nitobi was one.
That wasn't the starting point for the webview app DX.
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?
I've dumped all cross-platform frameworks as well. I tried many of them but they just weren't good enough, even for simple stuff. There were always glitches and teething problems that marred the overall quality compared to the native version.
I'm currently maintaining versions for both iOS and Android.
How do you stay motivated to do this?! I've tried to start my app in React Native multiple times, but it always sucks, so I finally started learning Swift. I'm already not sure how I'll stay motivated to learn Kotlin too, and rebuild the whole app again.
I can see the case for shared core libraries and then platform native views. This is best done in one programming language. Can Swift, Rust or .NET work here?
We're doing it with PHP... we call it SuperNative (https://nativephp.com/blog/supernative)
Yes, native .NET without MAUI is great for that. I have my app running with MvvmCross and two native UIs on iOS and Android since 2018, with hundreds of thousands of installs.
A Rust implementation of this idea is Crux: https://redbadger.github.io/crux/
Pretty sure I've seen you either at B-Sides or Polyglot... Small world...
I'll most likely be at Polyglot. I did a very small part to help organize one of the very early ones.
I'm looking forward to the next one in October.
Yes, though its worth noting the goal of Cordova was to not exist. In the eyes of the project the web itself is the cross-platform solution but at the time Browser progress was stagnant and Cordova helped move things forward by offering device functionality using open web standards. Cordova was never intended to be a "cross-platform productivity multiplier". The north star of the Cordova project was for browsers to get the device functionality that native platforms offered, such as geo-location, accelerometer, contacts, camera, etc.
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.
This is probably the end now. People don't debate anymore whether they should write only in assembly vs. in C. Sometimes new abstractions emerge and they replace something completely. This time the abstraction was LLM.
AI dramatically reduces the cost of writing code (especially when you have a reference), so the scale between native and cross-platform is going to tilt more towards native now compared to before.
But I'm curious what their update will be in a year or two. Because these costs don't reduce as dramatically with AI (unless you fully give up control and vibe code it):
1. Reading code
2. Manually testing code
1. AI will read the code
2. AI will manually test code
And so the mobile app development wheel turns. All of this has happened before, and all of this will happen again.
Before I even opened the article I knew the reason was because LLMs don't need abstractions. React Native was always about making app construction easier for people who don't want to learn ObjC or Swift. If you're not writing or even reviewing the code yourself, this is unneeded overhead.
For a while I've been wondering why people are even bothering with high level languages if you aren't even gonna read the code.
> React Native was always about making app construction easier for people who don't want to learn ObjC or Swift.
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 agree as well. To the point i have a feeling that maybe after some time people will just start writing bigger programs which were in these high level languages like swift, java etc in Rust or C++(except for the potential memory risks).
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.
Bragging about "using agents to code pre-GPT" is quite the corporate flex... weren't they notoriously bad back then? Might as well say, "We've been doing spreadsheets with quantum computing since 2016"
I would not say they were bad, mostly just primitive compared to what we have today. I can only presume they are talking about GitHub Copilot which was released before ChatGPT. I believe at the time it was little more than “spicy autocomplete.” Yet it could be surprisingly capable, e.g. I recall this blog, also pre-ChatGPT: https://medium.com/data-science/github-copilot-crushes-data-...
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.
I'm skeptical. Pre-ChatGPT the models didn't understand tool calls or file editing so you couldn't really do targeted edits. So I really am not sure what they mean by this.
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.
The GP misquoted the article. They actually wrote:
> 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.
Ah, that makes more sense.
I use Shopify app every day, multiple times a day to run my business and it has always been buggy and inconsistent for me on Android, and I don't expect this will make it any better, especially with more AI in the mix, but we shall see.
Who wants to bet there still won't be a dark mode?
I'm not totally following the part about the simulator(s), probably because I haven't actually done mobile development before.
> When simulator interaction is needed, the CLI can connect to them via a remote mode and drive the UI via commands without having to inspect the layout or the accessibility tree. This enables blazing-fast performance and E2E tests.
I think I'm not following. Don't you still need to test the accessibility tree and layout in the actual layer the user will interact with?
I have done some iOS development and still couldn't follow what the article was saying about the simulator. I'm actually quite interested in it, because (in my experience at least) verifying that the UI works as expected is quite painful with current LLMs and the developer tools available. They talk about building a CLI and keeping business logic isolated, ok fine, but do they still run the simulator and take screenshots to verify their work?!
indeed it's not totally clear to me if they do or not, my question too! OK, good to know it's not just something I was confused about because of lack of context!
It’s a reasonable tradeoff. Shopify uses Rails, and there’s been a long history of discussion around E2E testing in the Rails community.
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...
On theweb, not surprised that Rails switched from kind of encouraging people to use as many browser-automated tests (under whatever name) as possible , to trying to discourage people from using any. Rails way really likes being absolutist.
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.
Forgot the source but DHH mentioned it's not all, just most. Still makes sense to have on some scenario, just not all, or the default anymore
Oh okay. "No longer enabled by default" made it sound to me like the suggestion was not to use them at all, glad I misunderstood.
I remember their blog post claiming how much of a win it was to move over to react native and maintain high performance. They even listed their performance metrics. At that time I was a mobile developer for an e-commerce business and the metrics they were proud to share were unacceptable on our native apps. Here they are coming full circle
Before and after LLMs.
Debugging crashes across JS, C++, and native threads costs more than maintaining two codebases.
I believe this will be overall trend in industry. Dropping React Native and Flutter for native
That would be a huge mistake if we expect many more hardware and OS running them efficiently than just iOS and Android. Best is to have an IR. Now maybe that IR can be turnt into native code. But we shouldn't be constrained. As an incoming framework author, SwiftUI is problematic for instance because it has a programming model which is dated. And I don't particularly enjoy the language either. Looked fine at first and then got more complex than I feel is needed.
oh yeah, disclaimer: I write UI frameworks and dabble in PLs.
How is SwiftUI dated? It uses a declarative model. I don’t see UI framework paradigms shifting that much.
It is virtual dom like. We don't have access to a stable underlying element like we would with plain UIKit. You can build declarative models without this virtualdomness. But SwiftUI was created during the react boom so they went with the Zeitgeist, understandably.
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).
This is such a clueless take, and I see it surprisingly often. Declarative UI does not inherently mean virtual DOM nor does it "automatically" mean slower than UIKit.
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.
Yes, declarative UI is just an abstraction of imperative code. :) The rest is properties of the internal implementation. The VDOM way obfuscates the internals more. Doesn't let you control rendering appropriately. It is so because the diffing and reconciliation algorithm have to be able to remove any subtree of views/nodes from the UI tree.
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.
> That would be a huge mistake if we expect many more hardware and OS running them efficiently than just iOS and Android.
Is that something we should be engineering for right now?
Just like any engineering and business decision, this is a tradeoff. I probably don't see things from the same vantage point. Can't help but notice a trend however. What if this accelerates, especially with AI being an enabler?
I think it'll become a trend at larger, well-capitalized companies and startups, but not universally. The article mentions hundreds of engineers have worked on Shopify's RN apps, so they're well positioned to maintain two native codebases with agents and practically infinite token spend. Migration will be a harder sell for resource-constrained businesses.
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.
Can React Native become a sort of Compiler which compiles to natives (Android/Apple) now that AI can help in that direction as well? I don't know much about mobile ecosystem though.
Yep. Flutter has been dead-end for a while. RN won't last through 2027.
LOL, flutter/dart are pretty awesome and we have yet to encounter something that needed improvement.
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?
It's interesting that they don't mention Kotlin Multiplatform or any sort of shared core logic between their iOS and Android apps. Seems like maybe the apps are fully independent codebases but with shared specifications and tests? They say that agents:
> Dramatically reduced the cost of maintaining parity between platforms through shared specifications, tests, and review checkpoints
I've used Kotlin Multiplatform on a mobile project built back before AI coding took off, and it was super nice to have shared core logic between the apps and there weren't really any downsides on the Android side, but on the iOS side it was definitely an extra layer that didn't feel fully native.
Speaking personally, JVM toolchain bits like Gradle being involved is a turnoff and has kept me away from KMP. Last I checked support wasn't really there yet, but I'd much rather go the other direction and use Swift Package Manager and the associated toolchain on Android.
I work on an open source app that uses a shared swift core for the iOS and android apps and I think it's awesome. I think having all your business logic in swift is great.
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.
In the age of LLMs, I get why you would dump portablity in favour of close-to-the-metal Swift and Javascript codebases. However I don't really understand the need for Kotlin- surely thats just an unnecessary complication and performance hit?
That's for the Android version, I would assume
Right- but why not let the LLM program directly in Java?
Java can still be used but it's no longer the recommended choice for Android apps. For any new Android apps nowadays you start with Kotlin and Jetpack compose (made by Google).
In fact, I think Google's been saying this for 6-7 years already.
Because Kotlin is the primary language for Android.
Kotlin compiles to the same JVM bytecode that Java itself does. There is no performance hit. And from a developer's perspective, no it is not a "complication", Kotlin is a much more pleasant and efficient language to program in than Java (in my opinion, and that of many others).
Wish they explained more. Even though I'm mostly native iOS its seems react native is better stack for AI and iteration (hot refresh etc) - the main reason pretty much all AI vibecoding app were implemented via expo/react native.
I also believed that finally this year react native got mature enough with improved tooling and performance to the point that it started to being 'boring' technology.
There's a section linking to a more in depth article:
"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
Vibe-based architectural changes undoubtedly destined for "extreme" success until the next turn of the churn
Yesterday, just before bedtime, I pointed Astra at our Electron Desktop app, and asked it to write me a native Swift app for iOS. The electron app has 750 unit tests and 50 something integration tests. It also had access to the electron app via mcp and could click around and inspect it. I also gave Astra read only access to the backend code.
It worked for 3 hours and delivered a nearly feature complete port. Today, I found in manual testing 3 bugs and 1 performance issue, all of which it fixed afterwards. To fix the performance issue , it made several different builds and profiled them with Xcode.
At around 12:30 I had a full native app port of our product on my iPhone and iPad and could show it to my crew. It even did portrait and landscape correctl!
Needless to say, that I was flabbergasted. On one hand, I love it , I can build now all those cool stuff, but on the other hand, its a complete devaluation of my craft. I kinda tell myself that I was still the one setting up a proper env for it and that not everyone can do it. but thats coping. Freaking coping… and I know it
psychosis
what? why? Do you say I made this up?
I'm still laughing.
Truth is the Shopify app is simple enough to get right by a model. Lots of things hare simpler to get right in native code, so it is to be reiterated - a lot of interpreter code/libs is going down the drain, along with the devs that write it. These are not needed anymore.
And, in all honesty, the difficult part with many projects is the bootstrap, the scaffolding, not the continuous dev. Agentic dev. made this a piece of cake.
This article is about the Shop app (which is a consumer shopping app, kinda like Etsy or Amazon). The Shopify app is a lot more complex actually
I agree with this but not just React, React-Native. There's many libraries I no longer have a need for. I've made several JS 3d apps just asking the LLM to write the 3D code from scratch. AFAICT they usually shed 2meg of library and run 1.5x to 3x faster as the LLM will do the optimal thing for the situation.
The most interesting part to me here was the whole helix thing + how they split business logic and UI just so AI agents could drive/test state via a CLI. I hope they do a deeper blog post on just that. I’m surprised they are making “decouple state from UI” sound like something groundbreaking when that’s kind of been the foundation for any sane/testable app for a LONG time.
https://shopify.engineering/shop-app-migration
follow up with some more technical details and benchmarks
The promise of React Native was easing development burden from the web app to the native app. It makes sense if they are just using coding agents to cut out the framework and just go native.
That was my thought when I saw the headline and then reading the article confirms this is the inflection point per their own words. Very interesting.
I'm an user; I have zero or near zero development and programming knowledge, so this take of mine might be complete nonsense.
But I think this is perhaps one of the first AI developments I actually like. Transitioning an app from React Native or any web technology to native code has the distinct advantage that the native version should be much more economical in its use of resources.
I'm tired of hearing about RAM and other components hiking their prices while at the same time RAM sizes of ~8 GB are considered too small because things like Electron apps are wasteful in their consumption of resources. Now, with more native apps, we might get full circle: leaner apps thanks to agentic development. Maybe someday 8 GB of RAM could be considered enough once again. Truly interesting.
100% with you. I'm fed up of having my M3 36GB run out of memory because I have Chrome, Slack, Discord and Claude all open at the same time
That's why I'm building SuperNative
Yep. First time I "wrote" a native iPhone or Mac app in about 9 years was recently. I've written plenty of C, C++, Rust, etc code but always found Swift and ObjC to be uniquely bad, and Apple's UI frameworks and tooling are terrible. So one way or another wanted it to mostly not be my problem. First that was RN's job, now it's Claude's job.
React native isn't a terrible idea, its fundamental issue is that Apple does not allow for JIT compilation on iOS. So that means your app's js logic will be an order of magnitude slower than what you would get in the browser.
I made this argument at my previous company a year ago and was shouted down by most of the mobile engineers. I have since departed, but knowing how much Shopify's engineering blog is worshipped there they will now say this is the future.
I wonder why not Kotlin Multiplatform. I’ve been using LLMs to build with KMP for about 10 months and it’s a delight and you can use native Swift UI when you want to. It seems to be the best of all worlds.
Not enough community around it. Shopify would have to pioneer a lot more than they would like to get it working for their use case.
I've been out of the app world for ages, always liked kotlin. Can you speak more about multiplatform?
Well the thing is that the server code is basically Java, and the only bad thing about Java is writing it but since I don’t have to write it, it’s actually a really solid option. Then you have shared UI (don’t use WASM for web though it’s terrible, I use React for the web frontend) but you can switch to some or all native components when you need to on any platform. So for example I needed native components for secure storage and passkeys and did that by mixing in some swift on iOS and using a JNI native bridge on macOS and Windows.
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.
Maybe cross platform devkits would not be choosed only becauseof development cost.
I forsook RN years ago. I am not a huge fan of the JavaScript ecosystem in the first place, and the UX of RN apps is not the best. Instead, I adopted Kotlin Multiplatform (shortly after their memory management overhaul). I haven't been disappointed. As coding agents have come along, they are really good at writing both Swift and Kotlin, and I get to write all the business logic once. UI can either be shared with CMP, which is quite good, or platform-specific.
Most of the costs of switching have yet to be borne: user issues with untested code, maintenance issues with code few understand, and the strategic dependency on coding LLM's, which will change in character after providers go public and need revenue to fit reasonable stock multiples. All only get worse with time unless they're addressed proactively.
I think in the end, we should just be writing some prototyping language, then let AI translate into target/native development language of the said platform.
Code and optimization is going to be a niche moving forward
I think the most interesting part of this story is actually the Playwright-style “driver” that they built into their new apps to support faster verification by the agents.
Hopefully they will write more about that in the future.
If they play this right, they can do much more than just ecom and move into agentic templates and start selling slack and jira templates
An Android developer since 2010 here.
I've always been wary of React Native, because my impression is that it hides nuances of the underlying framework. You may be fine implementing 90% of your app but then need that last 10% and may get stuck.
But then I'm also wary of the recent trend by Google to create higher level frameworks on top of native Android APIs. It seems that these days for every Android API family, there is a Google framework that gives you a higher level API. I don't really understand it - is Google admitting that the quality of native Android APIs has eroded? Do they think developers are too inexperienced to deal with native Android APIs?
I'm also not sure I understand the how reasonably large companies consider two native apps to be too expensive. A startup may have a hard time funding both and may need to choose, but an established business should consider not only costs but also the better quality of user experience that native apps provide - that has to count for something.
It's incredibly easy nowadays to drop down to native from react native where you need to.
Surely the decision comes down to whether they have the expertise to build native apps.
I know JS and I know models still write a lot of garbage JS. I don’t know Swift so a model writing Swift all LTGM. Garbage is still there, I just can’t see it.
The solve isn’t another agentic harness. I need to learn more.
Lots of faster/cheaper justifications. I believe that part. If the quality bar is “web devs prompt models” then that’s a worry.
Native is the new React?! I could never drink the React Native cool aid due to background in performance optimization. Agents gave us the way to go native with less effort. Compilation is a good feedback loop for the agentic workflow as well.
Yea, I have started using c++ for some of the stuffs previously used python for. When agents is doing the grunt work, better to go even closer to machine.
They don't say anything in the post. But hotwire native supports pushing ui elements to ios and android. I imagine that might be part of the reason. I haven't built anything substantial with hotwire native though so I am not sure on all of the edge cases.
Technology historians will pin 2026 as the year frameworks died.
I think its more like 2024/5 is the year that existing frameworks were locked in place. At least it feels like that for react.
React popular -> llms get good at react -> llm generated apps default to react
This is exactly the decision we have made (though we didn't start with native). It just makes a lot more sense to make native apps and customize to take advantage of different native capabilities. AI essentially makes this a lot easier, and the end result just feels a lot nicer.
We made the same change for our patient app last month, took 2 months to rewrite from react-native to two mobile apps, but we had the PoC in under a week.
Interestingly Apple approved it very quickly, which I was afraid of given such a huge rewrite.
As things get more complicated and you need to worry about performance, where every millisecond counts, it makes sense to go to native: React Native and Flutter. These kinds of technologies are really good in terms of building faster and building one app which can work across. Where that deep performance might not be of a bigger concern, or you need to go build components natively and then expose them through React Native. I think, with AI, now building even a native app is faster, so moving back to native can make sense if you have a team which can understand how things work.
Few of the biggest reasons for "migration" to the likes of React Native, and web-views et cetera, were "lack of talent", and not getting that talent fast, and for cheap, et cetera, while of course terming that as innovation, embracing the future, and "that's where the game is at" et cetera. Now with the LLMs that is mostly sorted. So if anything I'd be able to see the eradication of the Electron infestation in my lifetime. But then I see the very tools these LLMs are accessed with i.e harnesses (and of course mostly made by the LLM houses) are made of Electron or similar things (sometimes a Frankenstein like mix). And even today Claude Code shows up as `2.x.yyy` for process name ffs! So if anything, this is getting worse.
Then they say:
> We decided to switch from native to React Native in 2020 for three reasons:
> Stop building the same features twice
> Allow developers to work across the stack
> Spend less time chasing feature parity and more time shipping value
Totally!
Is there some kind of shame in just saying:
- we didn't want to hire more people
- we didn't want to pay those salaries
- we fired a lot of engineers with move to react native/hybrid in mind
- we could reuse the frontend devs (aka "full stack" folks) with or without some extra whippings ensuring they grok the bare minimum they'd need to build for mobile and test in on mobile.
The rendering layer and APIs differ significantly between iOS and Android. Agents currently do not know how to test the UI, at least in my experience. I would be scared to do that migration right now.
It is the "why use python" for mobile.
The native apps will definitely be better in terms of performance and UX. However, having 2 codebases means twice the tokens.
The problem isn't tokens but verification that the code works.
If you have enough of a budget, you can ask your agent to spawn two subagent to do independent audits of "your" work.
I came here to say this. I also prefer fully native apps but this is the elephant in the room. If most of your web code can be re-used on native, that's a ton of tokens you won't have to pay for.
When companies can afford to build a native app but instead use a WOSE (write once suck everywhere) toolkit, it’s because they don’t care about the user experience.
With latest AI models, we will most likely see shift back to just fully Native apps even for smaller teams. This is type of stuff that AI models do really well, if you get a particular feature or even a bigger app change done in one platform, you can just tell Opus or Fable to replicate to the other platforms and in almost all cases it will just do it as well as most human teams would have done it.
In my limited experience, in h2 this year, LLMs were kind of shit at building Mobile apps. I had to switch TO react native because the flutter app it built me was a horrible buggy mess and I couldn't debug it myself because I don't speak dart. At least with react native I can kind of get in the weeds if needed
when you are large enough to allocate sufficient resource, you should go native, if not, go flutter/react native etc. Its very simple decisions I guess.
Which is why the topic about what Shopify does should apply to absolutely almost no one.
Who has more people/resources to justifiably throw at their native app than Shopify? Maybe a dozen companies?
React Native is slow.
Hermes VM doesn't even have JIT.
If the majority of your app is native code and only a few places are stitched together via JS code that runs in the Hermes VM, then React Native is suitable for you.
Look at V8 vs. Hermes performance.
We use Flutter; we rarely need to write native code. We have three apps: Symbiote workout app, CalorieCodex, an AI calorie tracker app, and MacroCodex with 17,000+ users, all of them completely free
Your data is out of date. React Native performs within spitting distance of raw native now because in the last 2 years... it basically became native - it's now false dichotomy
I tried it about 2 months ago, btw. No prior experience with Flutter or RN.
mind sharing a link or two on the native code generation bit? I'm far behind from the scene but still curious.
They probably mean that modern RN apps can now use a lot of native widgets. You can look at https://docs.expo.dev/versions/latest/sdk/ui/universal/
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
It's not. RN has always used native widgets (with a custom renderer) but the JS code itself is purely interpreted.
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.
I had one feature in RN and the rest properly native. The day I realized agents were good, I ported that RN to native. Monkey-off-back moment.
The underlying problem is that it's difficult to make a principled decision. So, it's ripe for SEO mining and such fuzzy takes happen.
The meta point of the article, I agree with though. The line is moving and AI makes having multiple platforms with code specific to them faster. Getting them right is still difficult.
The shared specs and tests seem like a big part of making this work. I'd be interested in a follow-up after a few months of shipping new features on both platforms. Does keeping behaviour consistent still take much coordination, or have the agents reduced that work too?
In the history books, this'll be the post indicating the end of writing code as a professional occupation.
A companies with thousands of engineers should simply go native.
Write once, deploy everywhere like React Native mainly benefits small teams and startups who are okay with building 90/10 solutions.
At the shopify's scale, they would want to go advance for every corner of the apps and use cases, and only native allows that.
Even a single person can now build/maintain native apps. It's literally a day of effort for an experienced dev working with the best current models to port an app to a new native platform. Maybe another day or two to walk through wiring up all the test harnesses needed to prove the app is working well without a human having to click everything. Until recently you'd still have to spend a bunch of time on making sure the UI looked and felt right, but models now have good enough vision capabilities to where even that can mostly be automated.
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.
I have not coded any mobile apps, I understand the downsides of using react native/electron due to them being web apps but what about things like Kotlin multi platform or flutter? Aren't this frameworks supposed to allow your to have 1 codebase and the apps be truly native instead of web apps?
I think any framework that aims to support desktop and mobile frome the same code per view/screen is doomed to either make one of those two awkward to use, or alternatively become itself very complex to use.
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).
React Native apps are not webview based like Electron, they use native components. Arguably it is more native than flutter, which uses its own components designed to mirror native ones on Android and iOS.
Hey what about Flutter
wow, what about electron.js the bloated cross-desktop GUI, can LLM either totally modernize wxWidgets(to avoid Qt's license mess), or create some light-weight cross platform GUI widgets to make GUI easy on windows/macos/linux that is not resource heavy?
Working on this problem for the next version of NativePHP Desktop. Have dropped Electron entirely
wxWidgets carries too much legacy. A GTK3 fork maybe? Or a functional clone of QML with some improvements.
maybe gtk4 gui first then ask llm to recreate them natively on windows and macos
no, not gtk4 - they lost their way after v3
https://github.com/vlang/ui2 does just that
How long until LLMs just write machine code?
Direct 1s and 0s
This is obvious in hindsight. I expect most companies that move fast and care about performance to abandon React Native. Code is cheap now, and the tradeoff of having a single codebase and only hiring React devs basically isn't there anymore.
Why not flutter?
Their reasoning makes sense. I'd love to read a follow-up and their thoughts in half a year.
If you expect a story about how this migration to native went from technical PoV, they've already shared this: https://shopify.engineering/shop-app-migration
It sounds pretty solid, so I wouldn't expect anything to change in just 6 months.
Missing out on flawless App Intents integration could be business risk for Shopify once people get used to doing everything from a central chat interface, including shopping. I guess it's the real reason for the switch.
What I want to know is if the agents are so good that they can convert React Native code to native with amazing efficiencies along the way, what's stopping them from improving React Native itself?
Translating code from one language/framework to another is easy for AI to do, as it does not involve solving any novel problems. Making improvements to existing complex codebases is much harder.
I suspected we would start seeing these types of blog posts. Code is becoming low level, where people do not care what language, it is written in anymore. The cost of moving from one to another is becoming low.
There's Kotlin Multiplatform too, you can either have the UI for IOS also done in Kotlin, or just have the logic shared in Kotlin and make the IOS UI in Swift.
I've been out of FE dev from awhile, is React still leading? I feel like Vue might be taking over?
React is still king.
Shopify always comes up but I do t know much about it. Do I interact with Shopify sites without knowing they are Shopify?
this motivates me to rewrite my Flutter app in Swift. I gave up on deploying the app to Android because of their 20 testers requirement at that time (not sure if its still true).
As the builder of a post-AI, cross-platform native app building framework like React Native, I 100% believe this to be a backwards move.
I've written up a load of thoughts about that here[1], but in summary for the Shopify case, they're basically going to be spending a ton more than they have to by switching back to multiple apps and I'd predict another swing back to better cross-platform tooling in the coming years.
[1]: https://nativephp.com/blog/why-not-write-it-twice
> they're basically going to be spending a ton more than they have to by switching back to multiple apps
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.
More code means more people. That's not peanuts
The whole point of this article is that it doesn't. Or at least for the same number of people you can now have way more code.
Is more code the right goal?
The wheel of fashion turns once more.
I don't think its purely fashion here. React Native always incurred a bit of a performance & UX penalty, but many people decided that this tradeoff was worth it for the increase in product development velocity.
LLMs change the tradeoff and organizations would be remiss to not reconsider previous decisions.
got me spinning like a record baby
srsly
Finally some common sense. Time to put electron to rest.
This is what happens when you have too much cash on hand. You start wasting it and doing dumb things. Like rewriting entire apps in two different languages.
What I find interesting is how AI has changed the cost of maintaining two native apps enough that a decision that made no sense a few years ago is worth revisiting now
using React Native you end up having to drop into native code to do anything interesting or optimized, so it feels kind of pointless to not just use the platforms directly
Most apps don’t do anything interesting.
Lol, they bought Tailwind CSS, freaked out, and decided not to touch it at all.
“We debated between gradually migrating to native (brownfield) versus rebuilding them from scratch (greenfield)… However, this time greenfield emerged as a clear winner for the following reasons”
“To solve this problem, we built a system called Helix that takes a more gradual approach. It doesn't expect the first output to be correct, and builds a loop where an imperfect attempt simply cannot move forward until it becomes a good result.”
If this is driven by proper engineering then hats off! Supposedly a simpler app has already been migrated and they are working on migrating the main app using this approach. I don’t even know how I can be a cynic here… because the technology is good enough and so are the engineers I don’t know how management or executives could ruin it.
“…product quality people expect today. This isn’t just the same apps rewritten in different languages. We’re rebuilding them so both humans and agents can understand, test, and change them quickly.”
If this was written using AI and human-edited, you missed a spot.
There's also "Helix rebuilding a screen in the Shopify mobile app using Swift and Kotlin" which sounds like a caption but there is no video or image.
Getting 11% AI on Pangram, which isn’t bad tbh.
if native became easier to tackle with coding agents, react native would have been even more easier to scale. this decision doesn't sit well with me.
Would be nice if Spotify and Notion did the same.
This article makes more sense if you remove the self congratulatory verbiage from it, and the cost rationale which I believe is zero.
Most orgs used REACT native becuase they simply didnt have the interest or talent to build mobile apps using native tech. Many many companies outsource the entire thing for the same reason.
So NOW that its been many years, and LLMs are there to help them they arent simply AFRAID to build a native mobile app anymore.
Thats the entire article. The rest is utter nonsense and bullshit.
Most large tech companies are just job programmes, i've seen so much effort, time, cost go into things that are truly unimportant.
React Native gives you (with asterisks) - one "source" for things to go wrong (as it sits on top of the native implementations of the UI + Native APIs). You are writing at that source level, and that filters down to the native builds. I am WELL aware to do certain things on each platform you need to get your hands dirty, but most apps are just serialising JSON from a database and displaying it.
AI writes very buggy, sloppy code.
They've decided - instead of containing that code to 1 surface, they would now have 2 surfaces they throw slop on top of.
I look forward to the 2027 version of this where they've gone back
And on top of that, they're losing the ability to ship hotfixes over the air and will always be at the mercy of apple & google to deliver their updates.
Isn't it silly that this even needs to be a conversation? Shouldn't we be able to write in any language we want and have the bindings for it to work cross platform? And shouldn't AI aid in building those cross-platform tools?
Maybe React Native isn't the right choice - but two tech stacks for virtually identical interfaces is dumb. Three stacks if you include browsers.
The move to native makes sense.
Also, human developers and AI make different types of mistakes, and take different approaches to debugging. I'm not saying they shouldn't have done that, it's just that a more human-involved approach with AI filling the gaps would probably be a saner bet than 90% AI with some human interference.
Here's an example of why:
https://blog.coredump.cx/p/recursion-into-madness
I develop iOS and Android apps and all the apps I have in App/Play Store are native. I did try React Native a few years ago but I just didn’t like how much extra bloat I had to include as third party dependencies.
Plus now with iPhone Duo which has so much variation in layout, I don’t think React Native would work well for it.
Does that mean no more react native skia sponsoring?
I mean it sounds nice but they never say _why_. "AI removes a lot of the burden" is not a _why_. I was hoping to read about some of the shortcomings of React Native, but it seems like they're doing it just because they can. I remember Airbnb had a post about switching off of React Native years ago that actually had some solid reasoning behind it.
https://medium.com/airbnb-engineering/sunsetting-react-nativ...
Article is too long to summarise but basically they outgrew it tech- and org-wise.
The article failed to provide reasons on they why move back to native.
Other than LLMs can do it tokenmaxxing exercise.
If you build with electron in the age of LLMs, you should change career
Makes sense in the LLM age.
With cheap/fast code, it's easy to support multiple software stacks since most of the abstract engineering problems are already solved.
Code - especially straightforward low-level code - is so cheap and easy to write now that some people are building their own version control systems, game engines, and other low-level tooling.
Thus, some of the most demanding, human-centric work in software dev right now - where we now spend more time than coding - is in technical PM, UI/UX, devops, and overall architecture. The decision-making and design aspects of the job.
Exciting times.
This is probably one of the things that excites me most about AI.
Companies can now just afford to maintain a hundred different native apps, rather than settle for a write once, run anywhere approach.
Its interesting that the move is back to native and not towards a technology better suited to delivering the same experience on multiple devices from one codebase.
Thanks to coding agents, there is no reason not to
May be a good decision.
Native. Metal. Remove the abatraction layers
We're only where we are in the world of computing because of abstraction layers
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
While Meta's Whatsapp just dropped native Windows client for Electron
Lack of vision?
Lack of a sane desktop app framework from Microsoft.
Heck Microsoft wrote their own damn start menu in React native, and VS Code in Electron.
Web based mobile made sense pre AI. It is just simpler now to use different languages and have AI implement features across the board.
im not a fan of react native per se , but this reasoning does not add up.
they are going to "delete an app" because they got some LLM to slop out 2 apps?
The architect who wrote that is batshit and will be unemployed after this blows up in his face.
i think many ppl don't understand this news
IMHO...
if you have a large org, a large app, lots of revenue and $$$ and resources...
it makes sense to do fully native now.
if you're a startup, you don't have the resources and $$$, you stick to RN
you can obviously have AI maintain both, but that is a cost. double maintenance = more $$$ on tokens
so many people are being doomer about this, but most people are also not Shopify
I'm certain that small startup Shopify could not afford to build native applications before AI became a thing. Thank god Sam Altman stole all the information in the world so that small family companies like this can finally have software too.
They are admitting React was a shtty choice for a mobile app if they have a choice.
I think what they’re actually admitting is if they have more resources to throw at native.
This is non-starter math for small companies.
Can’t wait for the blog post mentioning move back to react native or other cross platform framework.
Let’s see their app size (and heap)
I guess expect no new features on mobile until their token budget gets through all the screens?
I don’t understand why building an app twice is a big deal in the first place if that’s a core part of your business
Like wouldn’t you want to invest in platform specific expertise long term?
It’s not like this is a small company or it’s just a dinky side project off of the main business
Who could have guessed it!
A side effect of perceived LLM Generated code is now easier to just make it write native I guess.
oh fuck my life, we're back to this circa 2000 default of having incompatible binary UIs frameworks across various different platforms, with different OEMs shitting the bed at various different times and Apple free to arbitrarily force its hardware and OS into CI. I felt we were so close to unification in 2011.
And that's not even discussing the heresy of app stores. Curse smartphones for ever happening.
… from React “Native”
Cool story but what's the token spend?
"native" shouldn't be capitalized in the title
The article itself comes from AI ? It says twice why they switched from Native to React Native in two distinct paragraphs at the beginning. The rest sounds also AI slop jargon.
Why on earth is Shopify not just a web wrapped in an app like most apps? I mean, they implement most of that stuff for the desktop anyway.
Seems like you've never had to worry about accessibility in hybrid apps...
There's quite a bit of research out there showing that application performance has a material impact on checkout conversion rate, so a single platform optimization potentially improves checkout for millions(?) of storefronts.
Google research from a decade ago that might as well been that their bot did not want to wait for pages to load. The performance difference between React native and a web wrapped in an app is pretty much zero today.
> It doesn't expect the first output to be correct, and builds a loop where an imperfect attempt simply cannot move forward until it becomes a good result.
So... local maxima?
Perfect, yeah the obvious answer and comment is in the subtitle right at the top. Good way to write an article
> Coding agents changed what it costs to build mobile apps twice. Here’s why Shopify is moving from React Native back to Swift and Kotlin.
Major loss for react native community at large with Skia and Flashlist dying. :(
Legend List is the new hotness in RN.
I wish more companies would just focus on webapps. It's infuriating how many services try to push an app on you when it's completely unnecessary. The other day I went to a restaurant that had an app. Not a fast food chain, a nice full-service place. No, I'm not going to download an app to order dinner.
IMHO, now is a great time to use native Swift/Kotlin code alongside shared Rust code via UniFFI
We've been doing this for a while and it works great. Logic and network stuff goes in Rust, UI goes in Swift/Kotlin.
So you want to review and maintain code in 3 separate languages?
Sounds like a complete waste of tokens with the worst case of just quickly building more technical debt, three times.
It's a lot nicer than having the same logic in 2 languages and trying to keep them in sync – whether doing it by hand or with an LLM.
One of the big rules is don't repeat yourself – much of the logic only needs to be written once (except UI)
Well you don’t repeat yourself if the llm repeats it for you at the cost of millions of tokens.
Rust is uncompetitive for the use case of sharing logic between mobile apps. Kotlin has Swift interop and KMP is a mature tech by this point.
This is probably biased by the specific multi-platform apps I've worked on, but my default assumption is that sooner or later, any non-trivial multi-platform app will need to reach for something that doesn't already have a KMP library and that, on Android, might require compiling native code via the NDK. Rust has a way bigger library ecosystem than KMP. So I figure one might as well do the cross-platform core in Rust and add that FFI boundary early, but managed by something like uniffi-rs. And, I've seen it work in a few real projects now, with just a little build system friction up front. So in what sense is Rust uncompetitive for this use case?
KMP can call into native libraries easily. C FFI is not a competitive advantage.
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.
In that case, Kotlin makes even more sense especially with Kotlin Native, and Rust is unnecessary.
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.
Agreed, the whole of the Javascript / TypeScript ecosystem has caused a slop hellscape of workarounds, half-backed fixes and have exposed short-comings in the ecosystem.
Perhaps these languages do not work well as they are not designed to run efficiently on mobile devices. Now that we have libraries such as SwiftUI and Jetpack Compose, React Native no longer makes sense to use.
Now we should also move away from Electron to better alternatives such as Kotlin Multi-Platform or fully native libraries on each platform; because of LLMs.
So disagree. The benefits you get from leveraging a framework as as important today as they have ever been -- strong frameworks, fewer tokens, faster progress.
Hallelujah!
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
Too late. My kids called the app Stop-ify because it was so unreliable. Switched to Apple music and won't go back. On Android!
I think you’re confusing Shopify and Spotify.
this AI stuff is goin crazy
Out of curiosity why not look at Flutter? I know you don't get native look-and-feel, but most apps are branded who cares?
> you don't get native look-and-feel
You answered your own question
I've been around long enough to see this argument come and go under a lot of different names. This time it's AI. Maybe AI really does change the economics. But this post doesn't demonstrate it.
Talk to me in a year.
The side-by-side comparisons? Whoopty do. It's different code. Of course agents can produce two implementations that look the same today. That's not the hard part.
The hard part is keeping them the same.
Feature parity isn't an implementation cost. It's a divergence cost. It accrues over years across experiments, analytics, accessibility, edge cases, bug fixes, platform behavior, and a thousand little decisions which current agents aren't great at tracking.
Agents can write code fast but they aren't a panacea.
The load-bearing sentence in the whole post is this:
"Shared specifications, tests, and review checkpoints dramatically reduced the cost of maintaining parity."
Okay. For how long? By how much? Got any numbers to share? How will these hold up under contact with customer?
You haven't maintained parity yet. You've built prototypes. You're making a claim about a cost that compounds over time based on what it costs at t=0.
The other thing missing is the counterfactual. They keep comparing this rewrite to what a rewrite would have cost before coding agents. But what if you point those same agents at the existing RN codebase?
If agents make software development cheaper, they make RN development cheaper too. And now you're modifying one implementation instead of generating, testing, reviewing, and reconciling two.
The tooling section makes this even stranger. They find that agents are bad at driving simulators, so they pull business logic out of the UI, make it runnable headlessly, and expose a CLI.
That's a good idea! Do that!
But that's an architecture change, not an argument for native. You can make an RN codebase agent-friendly without rewriting five apps.
Then you get to "Preventing slop," which is probably the most important section in the post. Just pointing an LLM at the codebase doesn't work. They had to build Helix, with ordered checkpoints, test proofs, visual diffing, adversarial reviewers, and human gates.
So what they've actually demonstrated is that Shopify has enough engineering resources and agent infrastructure to make maintaining two codebases look economically plausible.
Maybe it is! For Shopify.
That's a much narrower claim than "AI changes the economics of cross-platform development."
And where are the numbers?
For a post about reevaluating costs from first principles, there's remarkably little cost data. Engineer hours? Review time? Defect rates? Parity failures? Agent spend? Ongoing maintenance? Anything?
They even say RN performance isn't the problem. "React Native apps can be fast. Ours are."
So there's no product crisis here. No performance crisis. There's an internal cost argument, with no numbers, being used to justify rewriting five apps used by millions of merchants.
And in isolation I'd probably just shrug and say: Shopify made a bet. Let's see how it goes.
But it's harder to view it entirely in isolation when they brought Tailwind on yesterday too.
Shopify used to be one of the great stewards of the broader ecosystem. What worries me about the recent direction isn't any single technology choice. It's the appearance that, following the recent tech leadership changes, we're starting to see decisions driven more by the preferences of the people now making them than by demonstrated technical merit.
Maybe that's an unfair read. I hope it is. But posts like this don't help, because if you're going to make a sweeping technical argument for a major change, show the evidence.
The part I actually find convincing is much less exciting: Shopify is tired of paying the upstream tax. They've spent years working on RN performance, improving the framework, dealing with dependencies and upgrades, etc.
Fair enough. That's a real cost. Being an RN framework developer or dependent is -- or has been -- awful -- it's like trying to fly a kite in a hurricane. The web team has been super disciplined and also ridiculously slow. The RN team changes apis in .. questionable ways with regards to compatibility
But it's not new, and it has very little to do with LLMs.
And let's not get me started on taking this kind of dependency for your business on companies who still don't have any idea how much to charge for their tools and are all operating (on a per token basis) at a loss. They're swapping some framework dependency for dependency on coding models whose capability, pricing, and terms they don't control.
None of this means they're making the wrong decision. Maybe they're right. Maybe in three years this looks obvious.
But that's exactly the point.
Come back in a year and show me parity bugs, engineering hours per feature, experiment drift, accessibility regressions, review burden, model spend, and how much human work it takes to keep the implementations aligned.
Right now they've shown that AI makes rewrites cheaper.
Whoopty do.
100%
expected
That also means that ruby becomes less important in their (rails) stack since they move to Swift and Kotlin specifically. Quite interesting considering problem-man DHH ("why are people upset at me shooting at wolves and comparing this it to Roma and Sinti" - and even aside from the connection on his blog to humans, I don't think everyone agrees at gunning down wolves in the first place) is part of the Shopify bromance team.
In hindsight that also explains why they laid off so many ruby devs in the last two years. Now if only someone could have told the ruby core team that companies pursue their own interests ... perhaps then they would not have led to the fiasco about a year or so ago. (And prior to that, the silly 100k downloads restriction at rubygems, aka "after that point we no longer allow you to remove your own code", whereas Microsoft github has no such restrictions in place. What are these people smoking?)
"Native is now the future of mobile at Shopify" is a rather unfortunate title for a writeup of why you're leaving a product with "Native" in the name.
Reminder that Shopify's CEO and COO are both literally Nazis and they host websites for literal Nazis.
What, exactly, is a "literal Nazi" -- I think Tobi is German, but he seems more like a capitalist than a national socialist. /shrug
https://drewdevault.com/weird-guys/#lutke
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...
Good one
It's not surprising. Code is cheap nowadays because of AI. I reckon more companies will follow suit.
the reason what I believe is that, AI can understand react very well. so It can be beneficial for Shopify
100%