Shopify is moving from React Native back to Swift and Kotlin
shopify.engineering686 points by fnthawar2 10 hours ago
686 points by fnthawar2 10 hours ago
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?
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.
> this yolo approach would give me constant dread.
When you’re completely ignorant, there’s nothing to be afraid of.
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.
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.
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.
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.
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.
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.
> 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.
Nailed it. Assume your client is compromised and/or malicious regardless of how it was built.
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.
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.
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?
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.
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?)
> 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
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.
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.
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.
This is a type of project that likely wouldn't have been done before AI
Of course it would. Supply and demand. Some companies would decide not to bother. Others would decide it was worthwhile. The limited pool of supply (app developers) would be distributed across demand.
>> Some companies would decide not to bother. Others would decide it was worthwhile.
The parent's point is that AI lowers the cost/benefit ratio drastically, by reducing the cost. So companies that would have shied away from projects like this pre-AI are now pulling the trigger without much hesitation.
> 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.
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 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.
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.
> 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.
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.
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.
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?
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.
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.
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.
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.
As an iOS Engineer that has been fighting the battle against ever C-level type who brings up the subject of a shared codebase my whole career, I feel very validated.
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.
Surely the decision comes down to whether they have the expertise to build native apps.
I know JS and I know models still write a lot of garbage JS. I don’t know Swift so a model writing Swift all LTGM. Garbage is still there, I just can’t see it.
The solve isn’t another agentic harness. I need to learn more.
Lots of faster/cheaper justifications. I believe that part. If the quality bar is “web devs prompt models” then that’s a worry.
I forsook RN years ago. I am not a huge fan of the JavaScript ecosystem in the first place, and the UX of RN apps is not the best. Instead, I adopted Kotlin Multiplatform (shortly after their memory management overhaul). I haven't been disappointed. As coding agents have come along, they are really good at writing both Swift and Kotlin, and I get to write all the business logic once. UI can either be shared with CMP, which is quite good, or platform-specific.
I had one feature in RN and the rest properly native. The day I realized agents were good, I ported that RN to native. Monkey-off-back moment.
I'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?
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.
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.
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.
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.
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.
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.
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.
Are you saying a native app can't make an http request and update the code they JIT?
This is so true, and I'm surprised that Shopify didn't mention it or that they don't use OTA updates.
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.
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 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?
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.
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
Tests? Not being flippant, but that strikes me as the new surface to maintain to get what RN used to offer
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.
"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
> 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.
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
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.
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.
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.
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.
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.
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.
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?
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
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.
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.
I first learned about the shopify app when I saw a purple "shop" checkout button. Next, I got an email saying that if I wanted to track my package I needed to download an app. No thank you. I don't want your app on my phone. I don't want to browse other stores in the shop app. I want to see my package and its status without enjoying a new "social shopping experience" or whatever.
I now avoid buying things from anyone who use the dreaded purple "shop" button.
If you put every company that needs/has an app on a spectrum, there is a line somewhere that roughly divides them into two groups: where Electron/React Native/etc. makes sense or not. It's just a normal engineering decision: solving problems given limited resources. Companies have different problems and different resources.
I think people in the tech community have probably also noticed that it's rather popular to have an absolute opinion on the goodness or badness of these tools. There's some magical thinking borne from ignorance that everyone just ought to go native or that React Native is the best thing ever to be used everywhere or that AI makes this line disappear entirely.
I think these takes serve little value and distract from what’s interesting, and what the subtitle to this article says: that this line is moving due to AI. And I think that’s probably right.
And 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.
> 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.
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.
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.
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.
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.
This is a great point that I wish the Shopify article went into in more depth! Would love to hear if they considered this
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.
> 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.
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.
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.
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 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
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.
Strong opinions considered harmful
Strong opinions tightly held
I try as hard as I can to have strong opinions, loosely held
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.
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.
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.
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 =)
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.
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.
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.
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 ]
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
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.
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
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.
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.
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
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.
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.
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?
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.
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
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).
> 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?
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.
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.
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 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
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.
https://shopify.engineering/shop-app-migration
follow up with some more technical details and benchmarks
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.
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.
I've been out of FE dev from awhile, is React still leading? I feel like Vue might be taking over?
Lol, they bought Tailwind CSS, freaked out, and decided not to touch it at all.
They don't say anything in the post. But hotwire native supports pushing ui elements to ios and android. I imagine that might be part of the reason. I haven't built anything substantial with hotwire native though so I am not sure on all of the edge cases.
We made the same change for our patient app last month, took 2 months to rewrite from react-native to two mobile apps, but we had the PoC in under a week.
Interestingly Apple approved it very quickly, which I was afraid of given such a huge rewrite.
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.
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
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.
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?
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.
In the history books, this'll be the post indicating the end of writing code as a professional occupation.
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?
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.
Does that mean no more react native skia sponsoring?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
"native" shouldn't be capitalized in the title
Would be nice if Spotify and Notion did the same.
While Meta's Whatsapp just dropped native Windows client for Electron
Lack of vision?
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
Web based mobile made sense pre AI. It is just simpler now to use different languages and have AI implement features across the board.
“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.
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.
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?
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
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 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.
How long until LLMs just write machine code?
Native. Metal. Remove the abatraction layers
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
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.
The article failed to provide reasons on they why move back to native.
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.
A side effect of perceived LLM Generated code is now easier to just make it write native I guess.
Finally some common sense. Time to put electron to rest.
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.
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.
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.
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
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.
Thanks to coding agents, there is no reason not to
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.
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.
Let’s see their app size (and heap)
If you build with electron in the age of LLMs, you should change career
Out of curiosity why not look at Flutter? I know you don't get native look-and-feel, but most apps are branded who cares?
I 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.
Who could have guessed it!
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
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.
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
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.
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.
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.
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.
Too late. My kids called the app Stop-ify because it was so unreliable. Switched to Apple music and won't go back. On Android!
this AI stuff is goin crazy
> 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?
I guess expect no new features on mobile until their token budget gets through all the screens?
Major loss for react native community at large with Skia and Flashlist dying. :(
… from React “Native”
Cool story but what's the token spend?
expected
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)
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.
Well you don’t repeat yourself if the llm repeats it for you at the cost of millions of tokens.
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.
Reminder that Shopify's CEO and COO are both literally Nazis and they host websites for literal Nazis.
It's not surprising. Code is cheap nowadays because of AI. I reckon more companies will follow suit.
Good one
That also means that ruby becomes less important in their (rails) stack since they move to Swift and Kotlin specifically. Quite interesting considering problem-man DHH ("why are people upset at me shooting at wolves and comparing this it to Roma and Sinti" - and even aside from the connection on his blog to humans, I don't think everyone agrees at gunning down wolves in the first place) is part of the Shopify bromance team.
In hindsight that also explains why they laid off so many ruby devs in the last two years. Now if only someone could have told the ruby core team that companies pursue their own interests ... perhaps then they would not have led to the fiasco about a year or so ago. (And prior to that, the silly 100k downloads restriction at rubygems, aka "after that point we no longer allow you to remove your own code", whereas Microsoft github has no such restrictions in place. What are these people smoking?)
I'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.
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.
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[dead]
the reason what I believe is that, AI can understand react very well. so It can be beneficial for Shopify