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.
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.
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.
Native is fast , no extra layer , the problem is maintaining on every native platform your app available. And AI tooling can handle that efficiently today , not way back then.
The problem with xplat is they add extra layer on top of platform native.
- React native and similar, add extra js runtime engine.
- Flutter and Kotlin MP add extra skia graphics engine.
“One React app vs two native apps” is a false comparison. A sufficiently polished React Native app still means two platforms to tune, test, debug, ship, and maintain. It gives you the appearance of efficiency and uniformity, but much of the complexity is just moved elsewhere… including, sometimes, to resource consumption on users’ devices.
They created a mess in 2020 and hopped on over to a job at FAANG and now a fresh batch of Waterloo graduates want to do the same - maintaining somebody else's turds is beneath a Waterloo graduate on his way to becoming a manager who never touches code ever again :)
Yeah. No way we’re getting the full story. It probably goes something like this… we lost native engineers when we switched to React then we lost the engineers that were supporting react recently and won’t be replacing them because stock market. Therefore we’ll switch back to native and go with under skilled engineers using llms. This will work until we have a code base model collapse
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.
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.
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?
It is virtual dom like.
We don't have access to a stable underlying element like we could 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 want to implement better fine grained reactive systems. And I posit that the next paradigm is going to be in that direction given what I've been working on (furthering current reactive systems which only go halfway).
This is such a clueless take, and I see it surprisingly often. Declarative UI does not inherently mean virtual DOM nor does it "automatically" mean slower than UIKit.
The abstraction is huge advantage, especially when targeting different devices and screen sizes. We (and that includes Apple) have been learning the value of those kinds of abstraction boundaries for years, well before React.
It's also important to note that SwiftUI and UIKit are composable, so if some small part of your app needs low-level, finer grained control, then go ahead and use UIKit/Core Animation/Metal and SwiftUI for the rest.
Yes, declarative UI is just an abstraction of imperative code. :)
The rest is properties of the internal implementation.
The VDOM way obfuscates the internals more. Doesn't let you control rendering appropriately.
Then you can only have islands of either paradigm within each other. UIKit and SwiftUI do indeed compose, albeit coarsely.
I can't blame them, they got influenced by react.
Don't even blame react, it was a good attempt. Basically trying to build a UI from a snapshot of a tree. Except this is too simplistic a model.
They designed it as if you could equate the number of games and the number of positions in chess. ;)
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?
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.
the tricky part about React Native is that you almost always need to use it with expo.
I developed React native app for ios as side project and took breaks often and came back to have to do big updates with expo to make it work again. Maybe there is smoother process, but this was annoying
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.
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.
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
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:
“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.
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 ...
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 I think is very interesting, and what the subtitle to this article says: that this line is moving, thanks to AI. And I think they're probably right.
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.
Using cross-platform web technology is absolutely a nuanced engineering decision that is the right one for many businesses. What is categorically bad is bundling a standalone browser runtime for every single service, wasting user’s storage and memory when you could just have a website in a browser.
Is there any major browser now that doesn’t support saving websites as apps? Electron is simply a suboptimal and incorrect way of producing web apps.
That decision is easy: do users leave bad reviews for bundling a few hundred MB of Chromium?
Do they leave bad reviews if your app malfunctions due to the system webview behaving differently than the Chromium version you tested with?
Forget about saving websites as apps, no one does that. Not sure if it works on Desktop Safari, it certainly doesn't on iOS Safari. Not even persistent storage is offered for PWAs. Apple likes the billions in AppStore fees they rake in every quarter.
> Much of Hacker News seems to be incapable of understanding the average user doesn't care about memory use at all, beyond a few extreme examples.
They don't care, but they care about their computer being slow because of swapping. While they can't identify the cause and link it to the various Electron apps they're using (Teams, Slack,...) it's obvious for the tech-aware person they complain to.
That's true, but greater efficiency isn't going to sell more software if the users don't know they need it.
At some level in your management chain there's someone who cares about selling more software above all else, and it's your job to do what they want.
I don't like it either, but I've fought against it for too long to my own detriment. I think ICs have a responsibility to deliver quality software regardless of external pressures, but there's only so much you have time to do.
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.
> 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.
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.
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.
I think they were speaking as a user. These tools create inferior products. (Still not technically objective, but true nonetheless.)
That doesn't mean companies should necessarily avoid them. As a user, I always want the best possible user experience, but a company can't prioritize that above all else, and I know that.
I am so tired of existing react/electron applications being compared against imaginary, hypothetical "native" applications.
Like, it's fine to criticize something, "this component doesn't follow the OS's UI guidelines" or "this scrollbar disappears when the mouse isn't over it which is a bad UX" or whatever, but this generic "oh this is bad but if it was rewritten it would be perfect" is annoying.
It's always the preference of people defending bad decisions to compare them to doing nothing.
What you're seeing is people actually making that case instead of forcing it. They're saying that if the app wouldn't exist without this bad thing, then it is appropriate to compare using the bad thing to doing nothing.
You just seem to be demanding that people not mention other ways to do things, or you'll get angry.
The app not existing would unironically be better in so many instances, though. The web version doesn’t take up 1GB of disk space, install persistent services, send you push notifications by default, and it’s trivial to block ads in comparison.
I’d be very happy if companies didn’t artificially degrade their web version to force installation of an “app” that’s effectively a web browser in disguise.
Hard agree. Day by day, I become more exhausted with "apps" as they are currently delivered, with native being slightly better than cross-plaform, but not good.
Apps in 2026 deliver all the disadvantages of a plain ol' website (Requires an always-on WAN to have any function whatsoever, UI that doesn't meld with the OS in any way, no integration with things like Shortcuts...) but add huge real costs: Extra time before I can start using it, the hogging of easily 500-1000MB of disk space on day 1, a growing un-clearable cache, sluggish transitions with useless animations, and the need to be "updated" on a regular basis (whether used or not) wasting my time and bandwidth.
One of the few benefits to me as the user of a 'client application' has always been that a well-made app uses an API to speak to the server which is dramatically lower bandwidth than the modern BloatWeb with AdTech™ stack could ever match, which ought to enable the highest performance. But it seems like they rarely actually deliver that benefit.
Yup. Now we have a choice of either using a terrible website with popovers and cookie bars (never remembering the choices) or apps that have insane onboarding, and bombard you with ads through notifications, with zero benefit.
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.
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.
Then why aren't people doing that? Microsoft has as much access to cheap tokens as any software company around, right, so you'd think they would be leading the way.
Keep in mind, claudecode and the other coding agents were pretty bad until around Jan of this year (2026). So it's only been about 9 months since devs have had decent coding agents and even less time has elapsed since somewhat wide adoption.
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.
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.
I don't have any actual experience with React Native and Electron, but with that caveat out of the way I personally think tools get far too much blame that should be on developers.
For an example that I actually have experience with, React very frequently gets criticized for being slow, heavy etc. React is not slow. I can make (have made) fast and snappy websites in react. React can render at more than 60fps if necessary, and if the code isn't shit. The fact that someone else has made a slow buggy mess with React does not prove that react is bad, it simply proves that the developers are bad. At this point, someone will typically interject with something along the lines of "but react makes it hard to make fast websites" and to that I simply say no it doesn't. I've seen what makes react apps slow, and it's generally just bad code. The developers who make shitty react apps would make equally shitty apps with any tool because they're the problem not the tool. They don't know how to build good software and literally no tool can help them because it's simply a matter of understanding programming and the sad fact is most developers suck at programming.
I graduated university with about 200 others and out of those people who have the same degree as I do, very few were even decent at programming. I know that because I was the guy who helped them complete their assignments and I was a TA in several different classes, and I'm telling you the overwhelming majority of students sucked at programming even after 2-3 years of studying it.
After graduating I've worked on many different web apps and other stuff, and I've seen an overwhelming trend of trash code and bad developers. The people who actually care about writing good software and have the mental facilities to do so are few and far between. And that's why most software sucks. A good developer can write good software using pretty much any of the popular tools. The tools are just different ways to do the same stuff. Sure there's some overhead with react etc but it's really not that significant, the significant part is all the trash code people put on top of it.
> React can render at more than 60fps if necessary, and if the code isn't shit.
Sorry, that doesn't really come across as a ringing endorsement. React apps are typically not doing anything complex so rendering at less than 60fps should only happen if you're doing very computationally intensive things or writing bottom-quartile quality code.
Yeah, obviously your average React app has no need to render anywhere near that frequently. The ones I've worked on will generally only render as a response to user action, server event or polling.
I'm just saying they can render that fast. So if your app takes a second (or several) to render it's obviously not because react is slow, it's because the code is ass.
In most cases if a React app takes a long time to render a page it isn't really rendering that's taking time, it's a slow network call or multiple. So the app being slow has nothing to do with React at all, it's the backend code that's slow or it's the frontend code doing multiple consecutive requests or something like that.
All I'm saying is react is not the reason it's slow.
Nuance is always a thing. Native apps are faster and better most of the time. Electron and React Native wouldn't annoy me so much if they were used with small apps where it's not worth over-optimizing.
However, it's now the default for Multiplatform apps that are used constantly, including IDEs, chat apps, etc. They gobble up memory and cpu cycles and are constantly getting updates due to the shitshow that is the javascript dependancy ecosystem.
I would rather have the opposite? I don't want 10 people making small apps that use Electron. I would rather that be used for bigger apps where the overhead is negligible.
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.
> 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.
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.
Absolute opinions are simple and travel better on media.
"The right tool for the job" is too complicated for a lot of people to understand. Tradeoffs? Tradeoffs require understanding.
"XYZ is the best, just use it" is much easier, especially if you don't know how to make decisions and don't really care. Then you defend your non-decision by parroting what you read.
I remember a product manager talking crap about Kafka years ago, and I started digging in as to why he didn't like it, and all of his reasons were marketing FUD from competitors. It was odd, his understanding of it was a Potemkin village.
All tools presumably solve a problem. If you understand that envelope you can figure out if it works for you and your envelope.
I think this is something we’ll see AI very meaningfully impact — the threshold needed for “Get this thing working on a tech stack we might not be familiar with” has gone waaaaaaay down.
It is funny how the experience of finding a tool/platform that you love can be a little bit like joining a cult. You probably have experience using other things that were frustrating and this one seems like the answer. Each platform has its own tradeoffs and philosophies and embracing one can make the others seem backwards.
Its also funny how reality sometimes validates or punishes these loyalties, and that is reaching a fever pitch in the era of LLMs. Platforms that offer familiarity at the expense of complex or inefficient framework will naturally lose ground when familiarity is no longer at a premium. It is a good thing, all of the hard parts are a little easier and it is less tempting to take the shortcut that you know has a dead end somewhere.
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."
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.
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 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.
> 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.
We use CC with Fable(Opus before that) continuously on a rather large project, everything is tested, we maintain high verified test coverage, we ship features x10 faster than when we started(pre Claude-everything era 2-3 years ago). I never worked with RN before and I ship features now. LLMs allowed us to find issues within RN itself, that thanks to some patches, improved lower end Android experience by a lot. We just use all the Claude defaults with claude.md that evolved over last year.
Same result here just using plain Opus 4.8+. I had a web ap with a PWA approach. Now I have an iOS app written in Swift/SwiftUI and an Android app in Kotlin in the appstores. I do not know how to code a single line of Swift or Kotlin. You just test the app and iterate with the AI over it until it is stable and does what it should.
Why would you asume that, and how do you define serious? Ever since the iOS appstore presence I get more signups from organic app store searches + installs, which results to some percentage in new daily+monthly active users. Meaning: People use the native app and keep using it. That is how I would define have value, as it provides value to the users - else they wouldn't be using it.
My main agentic coding side project is something that I can't justify paying the apple developer license for. If I was an Android person or I didn't have to pay the developer license, maybe I'd just go for it.
Android got wirse than Apple. It costs 25 dollar now to get ID verified (mandatory) and before you can publish in the Ply store you need 12 betatester that install the app from a special link - those testers must keep the app installed 14days. Only then will you become visible publicly in the play store.
So you end up paying people on Fiverr to do it which costs more than 99€
This is wildly overblown. I've been working with agents for a good while, read tens of thousands of generated Python and the language factor is actually the part they get right that humans don't.
I have been getting these comments often here, including concerns about my non existent backend's security.
Last time, when I pointed out that the attack surface for mobile apps is typically very small, some users started to talk about zero day vulnerabilities in the OS's media handling, as if it was a concern for my app implementation.
You sound like a person who's never had their app pen tested. The attack surface is anything but small if you're working with any kind of sensitive data.
Are there cybersecurity concerns in the frontend? I would have thought you have to assume the client is untrusted and only do security work on the backend
Doing anything right on web is 10x harder and more complex. The problem is the browser, once you use it to deliver anything you have to buy into all of it’s bullshit. CORS, XSS, headers, caching. All that just goes away (outside your backend API, if you even need one) when you ship a native app
My favourite (not a huge pratical concern, I admit) is a logout button with a logout API that fails, and nobody ever notices because it still shows the logout screen, which hides the API error toast (if errors were even displayed). The still valid refresh token stays in sessionStorage (or even localStorage) while the app displays "logged out". (Bonus points if you cleared the access token, and check this to know if the user has logged out.)
Or a login form that gets hidden after login, and clears its password input only after you click "login back in" on the logged-out screen.
Storing private secrets in your public client is easy to avoid for anyone halfway competent. We are all professionals here.
Turn on the secrets scan in GitLab, and put in your release checklist to have the AI audit the usage of secrets in your app, and this is basically guaranteed not to occur.
I doubt current models even make such a mistake in the first place, and particularly so if you use reviews at all.
WebViews are not an inherent problem, it's the system browser embedded in your app.
Where it gets tricky is if your use case involves authentication in the browser. Together with the authentication in your app this is the one area where you need to focus on security.
The case where a SDK update is needed to prevent weaknesses of the OS seems rather unlikely.
This is the most naive take on security ever. For the backend, you assume your client is compromised, but you still don't want to allow your client to be compromised.
If your clients are compromised then what's even the point of backend security. Users will login and do legitimate actions while their compromised client does whatever behind their back, while still looking normal. And the backend can't tell the difference.
Severe financial liability for security breaches, severe enough that, for instance, companies which leak 1m+ user data are driven to bankruptcy [would also get rid of the previous generation of JS 1000-lego vibers]
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.
All true (and thanks for posting a concrete example rather than "LLMS suck"). But my take is that none of this is much different than before times when I had teams of developers creating applications. They would often make similar mistakes which I would either need to catch or which would flush out in the field. Where it seems that LLMs are not excellent is where the person driving it is also the senior domain expert so can immediately spot pitfalls. But typically using humans to develop software this was really not often the case. Those people get promoted so they're no longer cutting the code. Under that scenario (replacing subordinate humans) I find the current models are either on-par or somewhat better (specifically because the models can also act like a peer senior dev, discussing approach options etc).
> It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.
I understand this, but I just can't bring myself to care. I've been doing professional software work for almost two decades. These sorts of improvements/time savers are great without AI. With AI? Whatever. It's fine.
When the underlying lib has an issue, it'll be quicker to debug with the whole thing in context.
You do realize that letting the LLM produce more output means that maintenance will be more expensive? I can easily see a world where claude and gpt are producing more tokens to sell you more tokens.
Just the other day I burned through my 5h quota twice in a row because I had opus spawn a review session on a medium sized PR and I don't know what happened but I told it to summarize to me and it said it spent 100M tokens throughout 50 subagent sessions.
And more recently its been recommending that i install this new browser called Aside. I did, and it almost felt like I was installing malware so I Uninstalled it fairly quickly (it also was not a great browser)
Well yeah, that's the name of the game of most software companies. Anthropic has been fairly good up until the last week or so when it started needing more hand holding to not do things it didn't normally do.
It depends on how hard to maintain the code added is, how likely it needs to change in the future, and most importantly on the cost.
If reviewing and manually improving the code takes hours, the cost may already be in the thousands.
That buys you a lot of AI usage, roughly a few months of continuous work.
You have to balance this with the chance that the suboptimal code the AI generated is actually fine and maintainable enough, and also the chance that during further work on that code a model might implement the same optimization on its own.
That's a recipe for regressions as the amount of surface you have to cover with "just...use the app" gets bigger and bigger.
You can write more automation to test it. But that's also how you end up with ever-growing test run times.
There are much better ways that aren't just "throw out the LLM" either. You just need to be more focused on throughput. Requiring manual validation can pretty rapidly require more hours than just sanity-checking code by hand, even (and I'm not advocating that for every use case, either.)
I can't afford manual QA passes if I'm gonna go as quickly as I want to.
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.
I wrote every single line of the react native app we ported, and maintained it for 9 years. So suffice to say, I'm familiar with the code.
But I am going to always prioritize the user experience over a developer (like myself)'s need for satisfaction to see code. And a pure native app is _always_ going to behave better than react native.
> And a pure native app is _always_ going to behave better than react native.
Maybe iOS is better about consistency, but I've used enough horribly made Android apps that I would not expect one that's vibe coded to behave better than a professionally made react native version.
You are familiar with the React Native code, you are not familiar with the Swift or Kotlin code, and likely nobody on your team is, since the AI wrote all of it for you.
Presumably a sarcastic post, but this is actually going to be how things are done soon. I had a box that OOMed and needed to be rebooted every few weeks. It was a disaster recovery standby box so figuring out what was going on never rose to the top of my priority list. So I asked Claude to dig into it (proxying the commands it wanted to run through me) and in an hour it had diagnosed the problem, fixed it, and taught me a bunch about memory usage in our system on modern kernels.
Not sarcastic. I have a moderately successful app and I haven’t once looked at the code (though I am capable, so far atleast). The only time I open Xcode is if I have to modify signing certificates. I did set up a slack workflow with a “fix it” button that basically tells Codex to fix the issue, run comprehensive tests, manually UI test for that particular issue with computer use and then deploy it.
It is. For my day job, I’m a software engineering director and I probably won’t have a job in under five years. For low to medium complexity apps, even Codex before Astra was capable of doing it completely by itself from scratch. For testing I would bring up the app after each atomic change and then manually try it out. I also use my own app heavily multiple times a day and I have found dozens of issues but I just ask Codex to fix it on the spot.
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.
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.
Next up, designing an even higher level language which will be used by LLMs to compile to high level languages like kotlin or swift. Just store instructions for LLMs in repos.
I 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.
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?
I thought the same, but then I build a few complicated apps and thought I could keep the different codebases stable but still was a headache, so switched web, ios, android all back to expo/rn. I love that testing is only (almost) only thing now, instead of 3 platforms.
We did the same with our apps used by a few hundred thousand people a day. We are a slow, boring company, so the port took about 4 weeks of engineering work, and maybe 3 months taking into account release process and change management. But in fairness, we had the first working version after a day as well. This was in February, too, with substantially less capable models, unable to do overnight runs.
In that case, Kotlin makes even more sense especially with Kotlin Native, and Rust is unnecessary.
Kotlin is already multi-platform and can be used as the re-useable business logic in an iOS app 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.
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.
If the majority of your app is native code and only a few places are stitched together via JS code that runs in the Hermes VM, then React Native is suitable for you.
Look at V8 vs. Hermes performance.
We use Flutter; we rarely need to write native code. We have three apps: Symbiote workout app, CalorieCodex, an AI calorie tracker app, and MacroCodex with 17,000+ users, all of them completely free
Your data is out of date. React Native performs within spitting distance of raw native now because in the last 2 years... it basically became native - it's now false dichotomy
It's not. RN has always used native widgets (with a custom renderer) but the JS code itself is purely interpreted.
They increased the interpreter performance by quite a bit, but JITs are impossible on iOS, so it can never be fast.
We have a RN app that needs to do a lot of geometry processing and things like polyclip are unbearably slow, so we had to add native modules to accelerate them. The web version with a true JIT works just fine.
762 comments
[ 2.6 ms ] story [ 251 ms ] threadWhat we found led us back to native.
It's better to find out quickly if you can get traction rather than building something requiring more maintenance. For most bug fixes or enhancements, you make them in the Jumpstart Rails side and they should up instantly in the mobile apps without going through app review again! Most projects are not being built in companies the size of Shopify, so I caution anyone who wants to just get the project out there to use platforms that give them more leverage. And no, I'm still not a fan of low-code or no-code, because I know what it's like to have to maintain apps over many years.
Oh, and I still always warn clients to stay away from native mobile unless they absolutely need it, because even with AI, maintaining just a web app is still light years faster, and far more pleasant. I know from very, very, very recent experience that testing subscriptions is still annoyingly cumbersome in the flaky Apple and Google sandbox environments, and Stripe for web apps is night and day easier to test. Testing on mobile is better than it used to be, but sometimes when I'm waiting for builds onto a physical device or for confusing settings in App Store Connect or Google Play Console to take effect (or just fine where they've been moved to), I think about how a manager 20 years ago was telling me how slowly his development lifecycle was when he used to burn software onto ROM chips. So web is still the way to go, and native mobile only if you absolutely have to. And if you have tons of time or money, sure, start with plain native.
Edit: As a web developer for decades, I still find both Jumpstart iOS/Android and Flutter to be preferable to React Native.
The vastly undersold topic to all of these is how many developers do you have?
We have the option of using flutter, or not launching an app at all. The concept of going full native is a non-starter.
I basically could not care what Shopify is doing because they have hundreds or thousands of people.
What you could do with Kotlin/Swift you can do with React Native as well.
This just feels like internal factions wanting their own teams, and owning their respective politics, than a discussion on Merit.
In theory yes, in practice no. I mean, in theory you can do it in mips ASM and ship QEMU along with the app, in practice it makes no sense.
The problem with xplat is they add extra layer on top of platform native.
- React native and similar, add extra js runtime engine.
- Flutter and Kotlin MP add extra skia graphics engine.
- Skiptools add extra swift runtime
- Cordova adn similar add extra browser engine
- Etc
Also, any plans to open source Helix?
So it goes.
oh yeah, disclaimer: I write UI frameworks and dabble in PLs.
Is that something we should be engineering for right now?
Now this is somewhat problematic if someone want to implement better fine grained reactive systems. And I posit that the next paradigm is going to be in that direction given what I've been working on (furthering current reactive systems which only go halfway).
The abstraction is huge advantage, especially when targeting different devices and screen sizes. We (and that includes Apple) have been learning the value of those kinds of abstraction boundaries for years, well before React.
It's also important to note that SwiftUI and UIKit are composable, so if some small part of your app needs low-level, finer grained control, then go ahead and use UIKit/Core Animation/Metal and SwiftUI for the rest.
Then you can only have islands of either paradigm within each other. UIKit and SwiftUI do indeed compose, albeit coarsely.
I can't blame them, they got influenced by react. Don't even blame react, it was a good attempt. Basically trying to build a UI from a snapshot of a tree. Except this is too simplistic a model. They designed it as if you could equate the number of games and the number of positions in chess. ;)
I understand the mistake.
We have small shims for IOS or Android BLE. But otherwise the discussion of should you go native is really a discussion of how many employees do you have to throw with this?
I developed React native app for ios as side project and took breaks often and came back to have to do big updates with expo to make it work again. Maybe there is smoother process, but this was annoying
It also depends on features. Many apps don't rely on platform features (widgets, watch apps) and are essentially webviews, and those will continue to do just fine on RN.
LLMs change the tradeoff and organizations would be remiss to not reconsider previous decisions.
I am still mourning pre-React GitHub. Maybe rose-tinted glasses, but it was so pleasant to use
For example https://diffs.com/ is built in React and it's basically instant.
https://github.com/pierrecomputer/pierre/blob/main/packages/...
... albeit using React inspired terminology like props and hydration.
I think my point still stands that, if MSFT cared, it would be fast. The issue is not the technology choice in this case.
For example, look at their demo here: https://diffshub.com/oven-sh/bun/pull/30412
It's way faster than GitHub and you check the network tab.
It sounds pretty solid, so I wouldn't expect anything to change in just 6 months.
It's not the layers that are the problem; they're the point.
It's the quality of those layers. React is just a poor abstraction layer
“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.
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 ...
> 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 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 I think is very interesting, and what the subtitle to this article says: that this line is moving, thanks to AI. And I think they're probably right.
Most likely this will work out fine, but big rewrites like this have a big enough chance of going off the rails that I wouldn't shout success from the rooftops just yet. I'm sure Digg engineering was proud of their rewrite too.
Is there any major browser now that doesn’t support saving websites as apps? Electron is simply a suboptimal and incorrect way of producing web apps.
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.
Haha. I completely replace the software with a non Electron alternative if available.
A one star review, on the other hand, can have a material impact on the search ranking and consequently my revenue.
You don't need to argue with me about it: I'm not the average user. But they really do not care at all in most cases.
They don't care, but they care about their computer being slow because of swapping. While they can't identify the cause and link it to the various Electron apps they're using (Teams, Slack,...) it's obvious for the tech-aware person they complain to.
At some level in your management chain there's someone who cares about selling more software above all else, and it's your job to do what they want.
I don't like it either, but I've fought against it for too long to my own detriment. I think ICs have a responsibility to deliver quality software regardless of external pressures, but there's only so much you have time to do.
I don't think that's necessarily true. Nuance is a thing.
These tools are bad, objectively! They give inferior user experiences, and waste resources (ever more important now with RAM prices what they are).
But that doesn't mean I can't understand or even agree with a company for using them. Building the same native application for more than one platform is expensive and time-consuming. Most of the time I'm happy to prefer an app built with a cross-platform framework vs. not having one at all.
(To be fair, though, if there's a webapp, 90% of the time I'll prefer that over an Electron app. But nothing meets a well-built native app.)
You can say it’s objectively bad from a technical perspective, but clearly that’s only one part of the equation.
It's subjectively bad because it's an embarrassment. Like you're seriously going to tell me something like Discord, worth 15 BILLION, cannot afford native apps? Spare me.
That doesn't mean companies should necessarily avoid them. As a user, I always want the best possible user experience, but a company can't prioritize that above all else, and I know that.
Like, it's fine to criticize something, "this component doesn't follow the OS's UI guidelines" or "this scrollbar disappears when the mouse isn't over it which is a bad UX" or whatever, but this generic "oh this is bad but if it was rewritten it would be perfect" is annoying.
What you're seeing is people actually making that case instead of forcing it. They're saying that if the app wouldn't exist without this bad thing, then it is appropriate to compare using the bad thing to doing nothing.
You just seem to be demanding that people not mention other ways to do things, or you'll get angry.
I’d be very happy if companies didn’t artificially degrade their web version to force installation of an “app” that’s effectively a web browser in disguise.
Apps in 2026 deliver all the disadvantages of a plain ol' website (Requires an always-on WAN to have any function whatsoever, UI that doesn't meld with the OS in any way, no integration with things like Shortcuts...) but add huge real costs: Extra time before I can start using it, the hogging of easily 500-1000MB of disk space on day 1, a growing un-clearable cache, sluggish transitions with useless animations, and the need to be "updated" on a regular basis (whether used or not) wasting my time and bandwidth.
One of the few benefits to me as the user of a 'client application' has always been that a well-made app uses an API to speak to the server which is dramatically lower bandwidth than the modern BloatWeb with AdTech™ stack could ever match, which ought to enable the highest performance. But it seems like they rarely actually deliver that benefit.
We have LLMs.
It's easy to build native everything now without much resource expenditure.
Android will be Kotlin. iOS will be Swift. Desktop and server will be Rust. Web will be TypeScript / React for now, but maybe one day WASM.
LLMs are the target now.
- they follow instructions quite well. - are tireless at doing mechanical ports between languages and frameworks. - Can understand a new ecosystem quite well.
we'll know when the next layoffs hit.
Keep in mind, claudecode and the other coding agents were pretty bad until around Jan of this year (2026). So it's only been about 9 months since devs have had decent coding agents and even less time has elapsed since somewhat wide adoption.
Both have an enormous number of paying customers and you don't just disrupt that for a language change.
React -> Rust is ambitious and the models aren't there yet.
Soon.
Preference for a native feel, solid software, bugfree code, compile/develop velocity, LLM friendliness.
We're in a brand new world.
For an example that I actually have experience with, React very frequently gets criticized for being slow, heavy etc. React is not slow. I can make (have made) fast and snappy websites in react. React can render at more than 60fps if necessary, and if the code isn't shit. The fact that someone else has made a slow buggy mess with React does not prove that react is bad, it simply proves that the developers are bad. At this point, someone will typically interject with something along the lines of "but react makes it hard to make fast websites" and to that I simply say no it doesn't. I've seen what makes react apps slow, and it's generally just bad code. The developers who make shitty react apps would make equally shitty apps with any tool because they're the problem not the tool. They don't know how to build good software and literally no tool can help them because it's simply a matter of understanding programming and the sad fact is most developers suck at programming.
I graduated university with about 200 others and out of those people who have the same degree as I do, very few were even decent at programming. I know that because I was the guy who helped them complete their assignments and I was a TA in several different classes, and I'm telling you the overwhelming majority of students sucked at programming even after 2-3 years of studying it.
After graduating I've worked on many different web apps and other stuff, and I've seen an overwhelming trend of trash code and bad developers. The people who actually care about writing good software and have the mental facilities to do so are few and far between. And that's why most software sucks. A good developer can write good software using pretty much any of the popular tools. The tools are just different ways to do the same stuff. Sure there's some overhead with react etc but it's really not that significant, the significant part is all the trash code people put on top of it.
Sorry, that doesn't really come across as a ringing endorsement. React apps are typically not doing anything complex so rendering at less than 60fps should only happen if you're doing very computationally intensive things or writing bottom-quartile quality code.
I'm just saying they can render that fast. So if your app takes a second (or several) to render it's obviously not because react is slow, it's because the code is ass.
In most cases if a React app takes a long time to render a page it isn't really rendering that's taking time, it's a slow network call or multiple. So the app being slow has nothing to do with React at all, it's the backend code that's slow or it's the frontend code doing multiple consecutive requests or something like that.
All I'm saying is react is not the reason it's slow.
However, it's now the default for Multiplatform apps that are used constantly, including IDEs, chat apps, etc. They gobble up memory and cpu cycles and are constantly getting updates due to the shitshow that is the javascript dependancy ecosystem.
https://www.revenuecat.com/blog/engineering/why-react-native...
"First key learning: execution matters far more than stack choice"
which directly translates to: make a great app and nobody cares about the tech and this includes whether or not to use Liquid Glass.
They can be "bad" in some dimensions (as you mentioned) while being "good" in others (dev productivity).
These frameworks didn't become popular for no reason. They have value. The parts that are "good" can easily outweigh the parts that are "objectively bad" when they enable a smaller team to get things out the door they would have had trouble shipping otherwise.
In stories like this its much more likely that they just got sick of refactoring a big ugly code base so got buy in to throw it all away and starting over and the justification is native. Wait like 5 years and there will be a new react-native corss platform app because the native apps have too much cruft. Assuming we still have human in the loop then.
Sure, but thats not an interesting observation unless there is something about react-native that makes those apps consistently higher quality than native apps.
On the other hand, like-for-like C/C++/Rust performs better than javascript in terms of CPU and memory use, so the null hypothesis is that re-implementing would , in fact, improve things. There's little reason to think a priori that the end result would somehow be worse.
For companies the size of Shopify and Airbnb that makes sense. But that doesn’t mean a small ten person startup should do the same thing.
For a while it seemed that having deeply held, nuance-free opinions about technologies was a sign of being wise and experienced.
The slightly lighter version of this was having near-absolute convictions but leaving a tiny exception for extreme cases to try to demonstrate that you weren’t being unreasonable.
These would usually follow trends when something would spread like a meme. Recent examples include “Everyone should use SQLite for everything” and the ironically closely related “Just use PostgreSQL for everything”. The typical pseudo-nuance would be “unless you have FAANG scale” to imply that there is no nuance until your user base includes most of the developed world.
this was every DBA in the late 90's and early 2000s when talking about their pet RDBMS. To me, it was a signal to avoid that person unless absolutely necessary.
"The right tool for the job" is too complicated for a lot of people to understand. Tradeoffs? Tradeoffs require understanding.
"XYZ is the best, just use it" is much easier, especially if you don't know how to make decisions and don't really care. Then you defend your non-decision by parroting what you read.
I remember a product manager talking crap about Kafka years ago, and I started digging in as to why he didn't like it, and all of his reasons were marketing FUD from competitors. It was odd, his understanding of it was a Potemkin village.
All tools presumably solve a problem. If you understand that envelope you can figure out if it works for you and your envelope.
I would have loved to see some performance benchmarks on some critical app flow.
Its also funny how reality sometimes validates or punishes these loyalties, and that is reaching a fever pitch in the era of LLMs. Platforms that offer familiarity at the expense of complex or inefficient framework will naturally lose ground when familiarity is no longer at a premium. It is a good thing, all of the hard parts are a little easier and it is less tempting to take the shortcut that you know has a dead end somewhere.
I also believed that finally this year react native got mature enough with improved tooling and performance to the point that it started to being 'boring' technology.
"The Shop app, which is regularly at the top of the list in the shopping category in the app stores, is the first to be migrated. Assisted by AI, the team was able to go from a proof of concept to a fully rebuilt native app published in the app stores in just 12 weeks. We’ve written about this migration in depth here [0].
The migration of the Shopify app (our biggest with 300+ screens, home & lockscreen widgets, Apple Watch app, complications, Siri Shortcuts, etc.), is also underway and will ship later this year. The rest of our apps will be migrated soon."
[0] Migrating Shop app from React Native to native https://shopify.engineering/shop-app-migration
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.
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.
Can you share some details of how you work? What models? What harness?
I don't know if Gemini is suitable.
I had few issues with my native iOS app, the results are just decent after a few iterations, the models do what I ask them to do. Where do you see the problem?
The LOC for my app is now at almost 200k + 110k lines of test code.
what the fuck are you talking about
I hate software engineering now.
sounds like your app is nothing serious
So you end up paying people on Fiverr to do it which costs more than 99€
That‘s how you check functionality but that’s not how you get the bugs in the code.
That’s like translating a text to another language without knowing the language
What do you think has more training data Python or Kotlin?
Some people on the cybersecurity side are starting to cry....
Last time, when I pointed out that the attack surface for mobile apps is typically very small, some users started to talk about zero day vulnerabilities in the OS's media handling, as if it was a concern for my app implementation.
I found the concerns again wildly overblown.
2. Wild use of webviews/iframes sometimes easily propagates as XSS in phones
3. Incorrect client-side OAuth 2.0 configuration e.g. with schema-based redirect URLs.
4. Not supporting high-enough API versions, which may prevent some OS-related weaknesses
5. The list is actually very long. Just few top of my mind.
Or a login form that gets hidden after login, and clears its password input only after you click "login back in" on the logged-out screen.
Turn on the secrets scan in GitLab, and put in your release checklist to have the AI audit the usage of secrets in your app, and this is basically guaranteed not to occur.
I doubt current models even make such a mistake in the first place, and particularly so if you use reviews at all.
WebViews are not an inherent problem, it's the system browser embedded in your app.
Where it gets tricky is if your use case involves authentication in the browser. Together with the authentication in your app this is the one area where you need to focus on security.
The case where a SDK update is needed to prevent weaknesses of the OS seems rather unlikely.
Most of the time when I review code from AI, there is always something to improve.
It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.
The maintenance is not only the burden on the human and LLM. With too many moving parts, it becomes harder and harder to build and verify the correctness of future features. Yes you can write test for this and that, but it didn’t need to exist in the first place.
The second problem is correctness issues. Especially the edge cases. You cannot just manually test out a race condition on a phone! Sometimes it happens! Sometimes it doesn’t! If it leads to a visible signal like a crash, then yes, you can try to reproduce it. But there are a lot of these that are “silent” and would just lead to bad experiences.
We already had a software quality crisis! And I think such views only exacerbate the situation! Quality matters!
And this is not an anti-AI stance. I vibe code personal projects where I don’t even look at the code. But when I use AI as a professional engineer, I act like a professional. Because these products do have an impact on people’s lives.
I also used to work full time as a Android developer for five years, and I'm pretty sure I know better than you about the quality of my app that I work on everyday.
Years of experience doesn’t mean much! I will challenge you on ideas. And the idea you are sharing is dangerous and unprofessional.
Especially at scale. e.g., we process more than 3.5 billion orders annually! This is serious business. Edge cases are common.
I think we are over-indexing on speed of delivery. I think this is a mistake. The alpha is in speed and quality.
Currently, my experience is that human + AI can write software faster and with better quality than either party can do alone.
I understand this, but I just can't bring myself to care. I've been doing professional software work for almost two decades. These sorts of improvements/time savers are great without AI. With AI? Whatever. It's fine.
When the underlying lib has an issue, it'll be quicker to debug with the whole thing in context.
And more recently its been recommending that i install this new browser called Aside. I did, and it almost felt like I was installing malware so I Uninstalled it fairly quickly (it also was not a great browser)
I feel like theres collusion somewhere.
I don’t see any reason to think the same thing that happens with all tech won’t happen here.
It depends on how hard to maintain the code added is, how likely it needs to change in the future, and most importantly on the cost.
If reviewing and manually improving the code takes hours, the cost may already be in the thousands.
That buys you a lot of AI usage, roughly a few months of continuous work.
You have to balance this with the chance that the suboptimal code the AI generated is actually fine and maintainable enough, and also the chance that during further work on that code a model might implement the same optimization on its own.
You can write more automation to test it. But that's also how you end up with ever-growing test run times.
There are much better ways that aren't just "throw out the LLM" either. You just need to be more focused on throughput. Requiring manual validation can pretty rapidly require more hours than just sanity-checking code by hand, even (and I'm not advocating that for every use case, either.)
I can't afford manual QA passes if I'm gonna go as quickly as I want to.
It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem, which makes me feel fear in my heart when I imagine the first "production is down" page coming in. I already hated mobile because it's so much harder to maintain than web (and I don't do any spyware or IAP so no benefits for me there); this yolo approach would give me constant dread.
It shows that at least some software development is moving away from code and to product management instead. I'm not passing judgement on that; I actually think that's great for a lot of software. It is interesting to see the shift happening though and will be fun to see if the general quality of software noticeably changes over the next few years.
But I am going to always prioritize the user experience over a developer (like myself)'s need for satisfaction to see code. And a pure native app is _always_ going to behave better than react native.
This gives me a chance to do that.
Maybe iOS is better about consistency, but I've used enough horribly made Android apps that I would not expect one that's vibe coded to behave better than a professionally made react native version.
That said, I do recommend reading the code the LLM produces whether you understand the language or not. What better time to learn?
You are familiar with the React Native code, you are not familiar with the Swift or Kotlin code, and likely nobody on your team is, since the AI wrote all of it for you.
When you’re completely ignorant, there’s nothing to be afraid of.
But yes we are having real Android users test it.
So it’s quite the contrary. I care MORE what real users say. I can only guarantee that the app does things when I tap. So I’m not trusting the agent on UX, only on functionality. But whether it feels native, I am relying on those users in our team.
I still would feel scared operating an established product off a newly changed stack the team isn't familiar with though.
But our product now has a way more extensive test suite than it ever did, again, thanks to the agents writing pretty damn good tests.
Remember Chinese accounts on US Facebook say data centers are bad.
If you are blind, you cant see anything wrong, if you are deaf uou cant hear anything is wrong.
Myself turned some python code to Swift, and keep doing so, without trouble or pressure. Of course, I've been doing fair amount of systems programming for 20 years now, so not sure what to advice newcomers. But this approach to dev DOES work for me very well.
[1] Epigrams in Programming:
https://engineering.yale.edu/academic-study/departments/comp...
Each time I get access to a new model, I do two things on all our active codebases:
- Security review of all the code and vulnerabilities (new models will find new stuff)
- Code review of test suite quality, and idiomatic patterns/code for the language of that codebase.
And in the case of swift and kotlin, it's even more important that an agent helps me with the code quality since I don't know what "idiomatic" swift or kotlin looks like, the way I do with JS, Elixir, C#, Ruby, etc.
LLMs made it way worse https://ashishb.net/tech/react-native/
Sounds like a complete waste of tokens with the worst case of just quickly building more technical debt, three times.
One of the big rules is don't repeat yourself – much of the logic only needs to be written once (except UI)
Kotlin is already multi-platform and can be used as the re-useable business logic in an iOS app with Swift as the UI and the Android app with a Kotlin UI (Jetpack Compose) or both iOS and Android apps can be written entirely in Kotlin.
That vastly reduces the maintenance and Kotlin is reused across all apps and keeps it at 2 languages at most.
No need to introduce Rust to achieve the same goal.
Rust has a smaller library ecosystem, I'd say. Kotlin can use Java libraries on the server side, and on the client side on Android, and the ones needed on iOS are easy to convert to KMP - IntelliJ can do it semi-automatically. And KMP has the libraries that matter on mobile, for hardware access, animations and so on.
Hermes VM doesn't even have JIT.
If the majority of your app is native code and only a few places are stitched together via JS code that runs in the Hermes VM, then React Native is suitable for you.
Look at V8 vs. Hermes performance.
We use Flutter; we rarely need to write native code. We have three apps: Symbiote workout app, CalorieCodex, an AI calorie tracker app, and MacroCodex with 17,000+ users, all of them completely free
There's also a project to add a static JS compiler, but it's been in development hell for the last 3 years: https://github.com/facebook/hermes/tree/static_h
They increased the interpreter performance by quite a bit, but JITs are impossible on iOS, so it can never be fast.
We have a RN app that needs to do a lot of geometry processing and things like polyclip are unbearably slow, so we had to add native modules to accelerate them. The web version with a true JIT works just fine.
Like wouldn’t you want to invest in platform specific expertise?
It’s not like this is a small company or it’s just a dinky side project