What we found led us back to native.
That said, the massive downsides to native are:
- App Store Review time, this used to be hours to 1-2 days, now it can take a week or more
- In the same vein, you can do updates without waiting on native when using web technologies to build your app. We can go from a bug in the field to a fix in <1hr easy. Try doing that with a native app
- Cross-platform, yes LLMs mean you can create a native iOS and Android app but you have to keep those in sync to say nothing of web (if you want to offer a web app as well)
- Like the point above: Web, if you want to support web, why not get the other platform for cheaper (shared logic)
KMP can be seen as a token optimization at this point. Business logic is shared and doesn't have to be rewritten in Swift.
Yes, for a while they were doing very well and I even once had an app reviewed in <1hr but the average has been creeping up. LLM/Vibe coding is what is often blamed for this increase though at the end of the day it's Apple's problem/fault for not staffing the review department better.
I just ran an analysis of my apps and the fastest was 8hrs (June 20th) but since then it's been trending upwards with my last 3 updates coming in at 40hrs, 67hrs, and 98hrs. These are all my apps, the company I work for has at least 2 recent updates that took over a week. That's just absurd.
If the App Store can commit to 24hrs being the max time then maybe I'd be interested but for the foreseeable future I'll "Settle" for instant updates when I have a fix ready instead of waiting on Apple. Especially with how random approvals are (not just the time, the approval itself), I'll ship a tiny fix and App Review will kick it back for some native API I've been using since version 1 that they now want more info about. I don't fancy having my businesses at the whim of Apple Review.
Just this week I've had an app stay for 9 days in review and another one for 8 hours. Same dev account, same niche.
Edit: was going to update the earlier comment but just hit the 2 hr mark.
There are cons to targetting web/PWA too. Push notifications work but Safari on iOS only allows them if the user adds your website to their home screen. It also doesn't support prompting the user to install the PWA so you have to instruct your users to tap the Share button, tap View more, and then tap Add to Home Screen. And as soon as they tap the Share button the menu opens on top of your instructions so they need to remember the steps to continue. It's hard to defend this behavior because the user will still need to allow notification permission when they open your PWA from their home screen. It's an unnecessary hurdle.
Apple may not trumpet it as loudly, but these freebies are handed out in UIKit too, for cases where declarative UI is cumbersome.
Generally I've found that while SwiftUI is great for little self-contained bits of UI like table/collection view cells and simplistic template-like apps, it tends to become a bear with complex apps, so it's nice to have both options.
Throughout my career, I found that the faster I can go from wanting to try something to seeing it working, the better. Without that quick iteration cycle, I end up, not trying certain things or trying to batch all of my changes which then makes it harder to be sure what actually fixed it.
It's better to find out quickly if you can get traction rather than building something requiring more maintenance. For most bug fixes or enhancements, you make them in the Jumpstart Rails side and they should up instantly in the mobile apps without going through app review again! Most projects are not being built in companies the size of Shopify, so I caution anyone who wants to just get the project out there to use platforms that give them more leverage. And no, I'm still not a fan of low-code or no-code, because I know what it's like to have to maintain apps over many years.
Oh, and I still always warn clients to stay away from native mobile unless they absolutely need it, because even with AI, maintaining just a web app is still light years faster, and far more pleasant. I know from very, very, very recent experience that testing subscriptions is still annoyingly cumbersome in the flaky Apple and Google sandbox environments, and Stripe for web apps is night and day easier to test. Testing on mobile is better than it used to be, but sometimes when I'm waiting for builds onto a physical device or for confusing settings in App Store Connect or Google Play Console to take effect (or just fine where they've been moved to), I think about how a manager 20 years ago was telling me how slowly his development lifecycle was when he used to burn software onto ROM chips. So web is still the way to go, and native mobile only if you absolutely have to. And if you have tons of time or money, sure, start with plain native.
Edit: As a web developer for decades, I still find both Jumpstart iOS/Android and Flutter to be preferable to React Native.
The vastly undersold topic to all of these is how many developers do you have?
We have the option of using flutter, or not launching an app at all. The concept of going full native is a non-starter.
I basically could not care what Shopify is doing because they have hundreds or thousands of people.
What you could do with Kotlin/Swift you can do with React Native as well.
This just feels like internal factions wanting their own teams, and owning their respective politics, than a discussion on Merit.
In theory yes, in practice no. I mean, in theory you can do it in mips ASM and ship QEMU along with the app, in practice it makes no sense.
The problem with xplat is they add extra layer on top of platform native.
- React native and similar, add extra js runtime engine.
- Flutter and Kotlin MP add extra skia graphics engine.
- Skiptools add extra swift runtime
- Cordova adn similar add extra browser engine
- Etc
Also, any plans to open source Helix?
So it goes.
oh yeah, disclaimer: I write UI frameworks and dabble in PLs.
Is that something we should be engineering for right now?
Now this is somewhat problematic if someone wants to implement better fine grained reactive systems. And I posit that the next paradigm is going to be in that direction given what I've been working on (furthering current reactive systems which only go halfway).
The abstraction is huge advantage, especially when targeting different devices and screen sizes. We (and that includes Apple) have been learning the value of those kinds of abstraction boundaries for years, well before React.
It's also important to note that SwiftUI and UIKit are composable, so if some small part of your app needs low-level, finer grained control, then go ahead and use UIKit/Core Animation/Metal and SwiftUI for the rest.
Then you can only have islands of either paradigm within each other. UIKit and SwiftUI do indeed compose, albeit coarsely.
I can't blame them, they got influenced by react. Don't even blame react, it was a good attempt. Basically trying to build a UI from a snapshot of a tree. Except this is too simplistic a model. They designed it as if you could equate the number of games and the number of positions in chess. Like a markov chain. Except playing chess has side effects. A mere snapshot does not encode those.
I understand the mistake.
We have small shims for IOS or Android BLE. But otherwise the discussion of should you go native is really a discussion of how many employees do you have to throw with this?
I developed React native app for ios as side project and took breaks often and came back to have to do big updates with expo to make it work again. Maybe there is smoother process, but this was annoying
It also depends on features. Many apps don't rely on platform features (widgets, watch apps) and are essentially webviews, and those will continue to do just fine on RN.
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.
If the entire page is rendered on the server, the information required to do so is presumably reasonably approximate (same datacenter). If most of the page is rendered on the client, the information needs to be pulled in from arbitrary physical distances.
At some point the engineering really is this simple.
"Oh no, we can't possibly do the computation of all that on our backend! Yikes! Let that run on every single client instead! Let users spend their own compute over and over."
culture.
https://diffshub.com/oven-sh/bun/pull/30412
Compare that to this:
https://github.com/oven-sh/bun/pull/30412/changes
I agree there are limitations bc of physics, but I don't think it explains this particular difference.
https://github.com/pierrecomputer/pierre/blob/main/packages/...
... albeit using React inspired terminology like props and hydration.
I think my point still stands that, if MSFT cared, it would be fast. The issue is not the technology choice in this case.
For example, look at their demo here: https://diffshub.com/oven-sh/bun/pull/30412
It's way faster than GitHub and you check the network tab.
It 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 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.
> 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’s interesting, and what the subtitle to this article says: that this line is moving due to AI. And I think that’s probably right.
It’s actually pretty common for a new company to start fully native (only iOS, few features, limited scope), then switch ro react native/electron (need to support more surfaces, features are being developed too quickly), then back to fully native (can afford individual dev teams for each platform).
Not always, but very often people in the past had good reason for what they did.
It is a very capable library, and when I first started using it the docs were more Oracle docs looking - but I could find what I wanted easily. Now, it is much more annoying to delve through but looks more modern.
See also: Chesterton's Fence
The post DOES give more information as to why they looked at switching from React Native to native Platform APIs.
React Native is forcing a major refactor of React Native apps in switching to the React Native "New Architecture" (see https://reactnative.dev/architecture/landing-page).
So if Shopify had to do major refactors of all their React Native apps, maybe they could look at what it would take to go back to native Platform APIs.
from https://shopify.engineering/shop-app-migration
For the Shop App, this coincided with our next major React Native investment: adopting the New Architecture. That work would have required us to revisit native module integrations, rendering, and the boundaries between shared and platform-specific code. Before committing to this investment, we tested whether coding agents could help us build directly in SwiftUI and Jetpack Compose while keeping product behavior aligned across platforms.
- startup time reduced: iOS by 23%, Android by 50%
- crashes - 10x reduction
- app size - iOS increased by 1MB (67MB -> 68MB), Android reduced by 109MB (37.2%)
- build time - Android release build time fell ~75%.
- runtime perf - Android builds could draw at 120fps while scrolling feed and switching screens
They're two different platforms where the capabilities and UI patterns differs, so I don't see why they should be in sync. The web platform is not in sync with them. And using native features can give you a nice boost in maintenance and speed, unlike React Native where you always needs to align library semantics.
Saying the web platform is not in sync with mobile is not a relevant metaphor to justify why Android and iOS should be considered separately.
I really wish they would not do that.
The best thing you can do to make your app trustworthy and friendly is to adhere to the host operating system UI guidelines and expectations.
Nobody wants your unique take on the checkbox or textarea please.
When you get to the point that your have a significant enough number of users across multiple platforms, generalizing everything into a shared UX doesn't make sense; giving those classes of users the best experience requires embracing their platform.
A simple example: Android has a system-wide convention for a `back` button. iOS has no such standard. Users on each platform have different expectations for how to navigate an app fundamentally, and holding tightly onto the concept of identical gives both camps a compromised experience.
I do think that the way the features are implemented should be platform dependent, i.e. use common UX pattern on each platform, fit in with the UI, and be good platform citizens.
Same as if I’m an Android user and you give me the conventional iOS experience.
It’s like if I gave a swing or Gtk+ or Xwindows app experience on Windows 11 or MacOS. It would be usable, but feel conspicuously sub-standard.
The Android back button is legacy.
I agree that most companies do that, but in my opinion that's not really all that important. Some drift between the iOS and Android apps should be expected and accepted.
Conway's law also plays a big part here and it's kind of TBD to see if agentic development will minify or magnify its effects
A lot of companies go to React Native, etc, because they want one single non-native design on both platforms.
Which IMO can be a mistake most of the time, especially from the POV of a user.
it is always the nerds (i’m a nerd, but also run a company and led teams before at a unicorn that IPOd) who obsess over things that normal people would probably not even come to given 100 years
case in point: even some of apples own apps don’t follow their design language.
also some of the most popular apps in the world like tiktok or x don’t use ios glass.
my bank app doesn’t use it and opts for a single theme across platforms.
and you know what? i don’t give a fuck. i just want my money transferred properly, my memes consumed on demand, and that’s about it.
Most likely this will work out fine, but big rewrites like this have a big enough chance of going off the rails that I wouldn't shout success from the rooftops just yet. I'm sure Digg engineering was proud of their rewrite too.
Is there any major browser now that doesn’t support saving websites as apps? Electron is simply a suboptimal and incorrect way of producing web apps.
I don't want to spend much time on this comment so I risk not making a sufficient point, but something I notice is that you're appraising the situation from a purely technical point of view. The technical component is just one piece of what makes a whole product. I think Apple is probably a good example: they regularly make decisions that bother the hell out of tech-centered minds.
Do they leave bad reviews if your app malfunctions due to the system webview behaving differently than the Chromium version you tested with?
Forget about saving websites as apps, no one does that. Not sure if it works on Desktop Safari, it certainly doesn't on iOS Safari. Not even persistent storage is offered for PWAs. Apple likes the billions in AppStore fees they rake in every quarter.
Electron is way bigger than an app needs to be, of course, but those giant apps that you hate, 250MB just for a health tracker? That's not electron being the problem.
Bruno consumes 300MB in RAM. The alternative I am using consumes 25 MB and it is much faster.
The difference is not because some uncompressed PNG or some fonts, it's the Electron architecture that is wasteful, by design.
And yes, not using electron will use less memory, which is an excellent reason to go "we're not using Electron". But there's a difference between "We want to use as little memory as possible" and "300MB of RAM on a system with 8 gigabytes of the stuff is a problem". The first is an excellent call. The second is nonsense =)
Space on disk, I have plenty. But the Electron version of many apps feels slow, sluggish, and it takes time to open, it takes time for every click to respond, it is the runtime cost what matters the most.
You say it is irrelevant? It makes a computer in 2026 feel just as fast as a computer from 2001, doing similar tasks, while the computer from 2026 is thousands of times faster.
And I definitely run more than one app at the same time.
This 300MB is the bare minimum used by these apps, in my example just an API tester. A simple "chat" app like Teams, Slack, or Discord wasting so many CPU cycles and so much memory is to me something that should feel like collective shame to our profession. Maybe that's why you disagree with me.
Haha. I completely replace the software with a non Electron alternative if available.
A one star review, on the other hand, can have a material impact on the search ranking and consequently my revenue.
You don't need to argue with me about it: I'm not the average user. But they really do not care at all in most cases.
They don't care, but they care about their computer being slow because of swapping. While they can't identify the cause and link it to the various Electron apps they're using (Teams, Slack,...) it's obvious for the tech-aware person they complain to.
At some level in your management chain there's someone who cares about selling more software above all else, and it's your job to do what they want.
I don't like it either, but I've fought against it for too long to my own detriment. I think ICs have a responsibility to deliver quality software regardless of external pressures, but there's only so much you have time to do.
Most apps won't need these capabilities to function, but they are there, for all purposes good and bad:
- background activities with fewer restrictions
- less restricted file system and sensor access etc
- ...
sure, many app use this for nefarious things.
But real use cases don't need to be sophisticated rendering algorithms or what not.
I think good streaming apps also use these capabilities, for example, for performance.
I don't think that's necessarily true. Nuance is a thing.
These tools are bad, objectively! They give inferior user experiences, and waste resources (ever more important now with RAM prices what they are).
But that doesn't mean I can't understand or even agree with a company for using them. Building the same native application for more than one platform is expensive and time-consuming. Most of the time I'm happy to prefer an app built with a cross-platform framework vs. not having one at all.
(To be fair, though, if there's a webapp, 90% of the time I'll prefer that over an Electron app. But nothing meets a well-built native app.)
You can say it’s objectively bad from a technical perspective, but clearly that’s only one part of the equation.
It's subjectively bad because it's an embarrassment. Like you're seriously going to tell me something like Discord, worth 15 BILLION, cannot afford native apps? Spare me.
Like yes, I'd prefer native and MS can certainly afford to take that path, but they can't even be bothered to make sure that most of their Electron apps land on the upper half of the quality spectrum.
Only if you don't compare it with any native or quasi native editors like Notepad++ or Sublime text. And Emacs has been cross-platform for decades.
Regardless, there are a bunch of new visual glitches in the release, with regressed performance all over the place.
But I still have to open a modal just because I dragged a meeting from one time to another. This version of Outlook is, slowly, getting better though.
That doesn't mean companies should necessarily avoid them. As a user, I always want the best possible user experience, but a company can't prioritize that above all else, and I know that.
Like, it's fine to criticize something, "this component doesn't follow the OS's UI guidelines" or "this scrollbar disappears when the mouse isn't over it which is a bad UX" or whatever, but this generic "oh this is bad but if it was rewritten it would be perfect" is annoying.
What you're seeing is people actually making that case instead of forcing it. They're saying that if the app wouldn't exist without this bad thing, then it is appropriate to compare using the bad thing to doing nothing.
You just seem to be demanding that people not mention other ways to do things, or you'll get angry.
I’d be very happy if companies didn’t artificially degrade their web version to force installation of an “app” that’s effectively a web browser in disguise.
Apps in 2026 deliver all the disadvantages of a plain ol' website (Requires an always-on WAN to have any function whatsoever, UI that doesn't meld with the OS in any way, no integration with things like Shortcuts...) but add huge real costs: Extra time before I can start using it, the hogging of easily 500-1000MB of disk space on day 1, a growing un-clearable cache, sluggish transitions with useless animations, and the need to be "updated" on a regular basis (whether used or not) wasting my time and bandwidth.
One of the few benefits to me as the user of a 'client application' has always been that a well-made app uses an API to speak to the server which is dramatically lower bandwidth than the modern BloatWeb with AdTech™ stack could ever match, which ought to enable the highest performance. But it seems like they rarely actually deliver that benefit.
We have LLMs.
It's easy to build native everything now without much resource expenditure.
Android will be Kotlin. iOS will be Swift. Desktop and server will be Rust. Web will be TypeScript / React for now, but maybe one day WASM.
LLMs are the target now.
- they follow instructions quite well.
- are tireless at doing mechanical ports between languages and frameworks.
- Can understand a new ecosystem quite well.
we'll know when the next layoffs hit.
Keep in mind, claudecode and the other coding agents were pretty bad until around Jan of this year (2026). So it's only been about 9 months since devs have had decent coding agents and even less time has elapsed since somewhat wide adoption.
Both have an enormous number of paying customers and you don't just disrupt that for a language change.
React -> Rust is ambitious and the models aren't there yet.
Soon.
Preference for a native feel, solid software, bugfree code, compile/develop velocity, LLM friendliness.
We're in a brand new world.
For an example that I actually have experience with, React very frequently gets criticized for being slow, heavy etc. React is not slow. I can make (have made) fast and snappy websites in react. React can render at more than 60fps if necessary, and if the code isn't shit. The fact that someone else has made a slow buggy mess with React does not prove that react is bad, it simply proves that the developers are bad. At this point, someone will typically interject with something along the lines of "but react makes it hard to make fast websites" and to that I simply say no it doesn't. I've seen what makes react apps slow, and it's generally just bad code. The developers who make shitty react apps would make equally shitty apps with any tool because they're the problem not the tool. They don't know how to build good software and literally no tool can help them because it's simply a matter of understanding programming and the sad fact is most developers suck at programming.
I graduated university with about 200 others and out of those people who have the same degree as I do, very few were even decent at programming. I know that because I was the guy who helped them complete their assignments and I was a TA in several different classes, and I'm telling you the overwhelming majority of students sucked at programming even after 2-3 years of studying it.
After graduating I've worked on many different web apps and other stuff, and I've seen an overwhelming trend of trash code and bad developers. The people who actually care about writing good software and have the mental facilities to do so are few and far between. And that's why most software sucks. A good developer can write good software using pretty much any of the popular tools. The tools are just different ways to do the same stuff. Sure there's some overhead with react etc but it's really not that significant, the significant part is all the trash code people put on top of it.
Sorry, that doesn't really come across as a ringing endorsement. React apps are typically not doing anything complex so rendering at less than 60fps should only happen if you're doing very computationally intensive things or writing bottom-quartile quality code.
I'm just saying they can render that fast. So if your app takes a second (or several) to render it's obviously not because react is slow, it's because the code is ass.
In most cases if a React app takes a long time to render a page it isn't really rendering that's taking time, it's a slow network call or multiple. So the app being slow has nothing to do with React at all, it's the backend code that's slow or it's the frontend code doing multiple consecutive requests or something like that.
All I'm saying is react is not the reason it's slow.
However, it's now the default for Multiplatform apps that are used constantly, including IDEs, chat apps, etc. They gobble up memory and cpu cycles and are constantly getting updates due to the shitshow that is the javascript dependancy ecosystem.
https://www.revenuecat.com/blog/engineering/why-react-native...
"First key learning: execution matters far more than stack choice"
which directly translates to: make a great app and nobody cares about the tech and this includes whether or not to use Liquid Glass.
They can be "bad" in some dimensions (as you mentioned) while being "good" in others (dev productivity).
These frameworks didn't become popular for no reason. They have value. The parts that are "good" can easily outweigh the parts that are "objectively bad" when they enable a smaller team to get things out the door they would have had trouble shipping otherwise.
In stories like this its much more likely that they just got sick of refactoring a big ugly code base so got buy in to throw it all away and starting over and the justification is native. Wait like 5 years and there will be a new react-native corss platform app because the native apps have too much cruft. Assuming we still have human in the loop then.
Sure, but thats not an interesting observation unless there is something about react-native that makes those apps consistently higher quality than native apps.
On the other hand, like-for-like C/C++/Rust performs better than javascript in terms of CPU and memory use, so the null hypothesis is that re-implementing would , in fact, improve things. There's little reason to think a priori that the end result would somehow be worse.
For companies the size of Shopify and Airbnb that makes sense. But that doesn’t mean a small ten person startup should do the same thing.
For a while it seemed that having deeply held, nuance-free opinions about technologies was a sign of being wise and experienced.
The slightly lighter version of this was having near-absolute convictions but leaving a tiny exception for extreme cases to try to demonstrate that you weren’t being unreasonable.
These would usually follow trends when something would spread like a meme. Recent examples include “Everyone should use SQLite for everything” and the ironically closely related “Just use PostgreSQL for everything”. The typical pseudo-nuance would be “unless you have FAANG scale” to imply that there is no nuance until your user base includes most of the developed world.
I try as hard as I can to have strong opinions, loosely held
this was every DBA in the late 90's and early 2000s when talking about their pet RDBMS. To me, it was a signal to avoid that person unless absolutely necessary.
"The right tool for the job" is too complicated for a lot of people to understand. Tradeoffs? Tradeoffs require understanding.
"XYZ is the best, just use it" is much easier, especially if you don't know how to make decisions and don't really care. Then you defend your non-decision by parroting what you read.
I remember a product manager talking crap about Kafka years ago, and I started digging in as to why he didn't like it, and all of his reasons were marketing FUD from competitors. It was odd, his understanding of it was a Potemkin village.
All tools presumably solve a problem. If you understand that envelope you can figure out if it works for you and your envelope.
I would have loved to see some performance benchmarks on some critical app flow.
Meanwhile the devs are furiously asking AI how to fix it, every flavor of every model will give you a different diagnosis, GH Copilot will throw a million high/critical at you, and you still have no idea if it's fixed or not.
It's the exact reason why you still need to know the languages you're using despite what leadership/product teams demand.
Its also funny how reality sometimes validates or punishes these loyalties, and that is reaching a fever pitch in the era of LLMs. Platforms that offer familiarity at the expense of complex or inefficient framework will naturally lose ground when familiarity is no longer at a premium. It is a good thing, all of the hard parts are a little easier and it is less tempting to take the shortcut that you know has a dead end somewhere.
I 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.
Not anymore.
The parent's point is that AI lowers the cost/benefit ratio drastically, by reducing the cost. So companies that would have shied away from projects like this pre-AI are now pulling the trigger without much hesitation.
…as long as Claude is still subsidized…
Sounds like you agree
I think that rewrite - if AI enabled - owes its thanks to the legion of individuals who put their code up on the internet in the first place.
Weird times.
Seems similar to eminent domain, but without limitations.
We all want super exciting jobs. But plenty have boring jobs like this. Between not having a job or having a boring job that pays well, the choice is obvious for many of us.
I personally never minded doing migrations. I guess I don't really have to anymore though. Weird.
They had previously chosen React Native because it was easier for programmers to keep it updated, since it was really just 1 codebase. With AI, those same programmers can do the more difficult version, keeping the native apps updated separately.
So did it kill a job, or did it make it possible for the existing programmers to do it better?
It's the kind of thing that is really hard to determine in general, but here, it really does sound like they only made the change because it became possible with existing resources. They would not have done it otherwise.
Just like this has made Web devs into Mobile devs, so could Mobile devs leverage AI to work in Web shops.
I'm not an optimist but there could be an increase of available apps being created which would still keep people employed. Theoretically the cost of creating an iOS app for a company without an engineering team dropped from several hundreds of thousand to a few thousand or hundreds, which could be paid out to a freelancer with AI. More people would go into freelancing for industries which were not contemplated before due to cost.
But I'm not an optimist.
What does your app do?
It is all the small things e.g.
YouTube Mobile website works really well when you have a inconsistent connection compared to the alternatives such as Odysee, Rumble, Kick and Twitch.
I can listen to a live stream or a video style podcast in the car and YouTube will resume the connection properly as long as the browser tab on my phone hasn't gone to sleep. Kick will just stop, if it is a replay it will resume from the start of the stream after rewinding the stream a few seconds while attempting playback.
While the code to do this isn't that difficult. YouTube has bothered to deal with the edge case of someone like me driving through an area with inconsistent connection while running their mobile site (not even their app).
Whenever people try to use alternatives, they often complain about poor reliability of the app. A lot of the clones are losing users and I doubt they really even know they are doing it.
They don’t care about your code. There’s more and better data on the public web.
Also what's the timing on this setting's effectiveness? What if before you knew to "opt out" you used the agent for a refactor and your entire repo got sucked up in inference? But then you opt out the next day? Is it too late?
And there are solutions around it from other providers and model routers. OpenRouter lets you explicitly say on a per-request basis you don’t want to be routed to a provider that trains on your input, for example.
If a company really believed there’s valuable IP in code, there would at a minimum, ban laptops or ban code on laptops[0], provide and maintain a centrally managed LLM gateway[1] that handles authentication, billing and model choice, have MDM to prevent you from using your own Claude login, etc.
[0]: For example when I worked at Google, the proprietary google3 codebase cannot exist on laptops because there are no tools to download it to your laptop.
[1]: For example Claude code supports having a gateway: https://code.claude.com/docs/en/llm-gateway-connect
Heck, you don't even need to mix up a personal and business AI subscription. For the vast majority of folks one day their IDE "updated" and a bunch of AI features suddenly became available. Free, no sub needed. A dev starts using them (because, why not?) and lo and behold the company's code got shipped out in an inference call and is now scheduled to be in the next training run. Oops.
Actions speak louder than words. If the company doesn't even supply and require work devices, they don't effectively consider their code to be valuable IP.
Of course the company can still consider their code to be valuable IP.
IDE updated? It’s the company IT’s job to perform testing before distributing those updates. And also their job to use whatever managed settings to disable those unmanaged AI features.
A single digit headcount startup with a "company IT" team testing program updates before distributing them??? Um, no. You just download VS Code (or whatever IDE you want) on the Macbook they give you and it updates when Microsoft pushes a public update.
For most app that concept is "gone".
People routinely decompile and recompose existing binaries, and if you use "obfuscation" in your app it's still a small bump.
In today's age, IP is no longer a tangible concept that gives any advantages in software. What differentiates two businesses isn't their IP, it's their relationships and their moat.
Most vendors that had protected proprietary IP are now irrelevant within their vertical. What saves them are the protection provided by patents, which is public.
Maintainability concerns are entirely overblown by people who don't use agentic AI to develop large mobile apps, but anyway give their opinion as if they had that experience.
I put in a few hundred hours, and I reached the same conclusion as Shopify. With reviews from other models and then a manual QA pass the result is fully usable.
OP says they don't have an android phone...
And in the past, I didn't care because when I was manually building the app, I would just do my best with react native. But now that I can actually sweat the details (with the help of agents), I do want to hear from android users and use as many OS-native APIs and features.
I'd order a cheap Android phone to have a device in hand instead of working only with the simulator.
I could only sweat the details on liquid glass, etc because I'm a daily iOS user.
Can you share some details of how you work? What models? What harness?
I don't know if Gemini is suitable.
I had few issues with my native iOS app, the results are just decent after a few iterations, the models do what I ask them to do. Where do you see the problem?
The LOC for my app is now at almost 200k + 110k lines of test code.
I hate software engineering now.
sounds like your app is nothing serious
So you end up paying people on Fiverr to do it which costs more than 99€
That‘s how you check functionality but that’s not how you get the bugs in the code.
That’s like translating a text to another language without knowing the language
What do you think has more training data Python or Kotlin?
Some people on the cybersecurity side are starting to cry....
Last time, when I pointed out that the attack surface for mobile apps is typically very small, some users started to talk about zero day vulnerabilities in the OS's media handling, as if it was a concern for my app implementation.
I found the concerns again wildly overblown.
2. Wild use of webviews/iframes sometimes easily propagates as XSS in phones
3. Incorrect client-side OAuth 2.0 configuration e.g. with schema-based redirect URLs.
4. Not supporting high-enough API versions, which may prevent some OS-related weaknesses
5. The list is actually very long. Just few top of my mind.
Or a login form that gets hidden after login, but clears the username and password only when you click "login back in". (Bonus points if the backend also enforces a 5min session timeout "for security".)
Turn on the secrets scan in GitLab, and put in your release checklist to have the AI audit the usage of secrets in your app, and this is basically guaranteed not to occur.
I doubt current models even make such a mistake in the first place, and particularly so if you use reviews at all.
WebViews are not an inherent problem, it's the system browser embedded in your app.
Where it gets tricky is if your use case involves authentication in the browser. Together with the authentication in your app this is the one area where you need to focus on security.
The case where a SDK update is needed to prevent weaknesses of the OS seems rather unlikely.
[yes, this would also get rid of the previous generation of 1000-JS-lego vibers]
Most of the time when I review code from AI, there is always something to improve.
It’s either a maintenance issue. e.g., Opus recommended and implemented a fix for a database corruption crash. This was ~400 lines of code with many moving parts. I reviewed, and found out Android Room library already handles this recovery case, and all I needed was a 10 liner PR that catches this exception and ignores it.
The maintenance is not only the burden on the human and LLM. With too many moving parts, it becomes harder and harder to build and verify the correctness of future features. Yes you can write test for this and that, but it didn’t need to exist in the first place.
The second problem is correctness issues. Especially the edge cases. You cannot just manually test out a race condition on a phone! Sometimes it happens! Sometimes it doesn’t! If it leads to a visible signal like a crash, then yes, you can try to reproduce it. But there are a lot of these that are “silent” and would just lead to bad experiences.
We already had a software quality crisis! And I think such views only exacerbate the situation! Quality matters!
And this is not an anti-AI stance. I vibe code personal projects where I don’t even look at the code. But when I use AI as a professional engineer, I act like a professional. Because these products do have an impact on people’s lives.
I also used to work full time as a Android developer for five years, and I'm pretty sure I know better than you about the quality of my app that I work on everyday.
Years of experience doesn’t mean much! I will challenge you on ideas. And the idea you are sharing is dangerous and unprofessional.
Especially at scale. e.g., we process more than 3.5 billion orders annually! This is serious business. Edge cases are common.
I think we are over-indexing on speed of delivery. I think this is a mistake. The alpha is in speed and quality.
Currently, my experience is that human + AI can write software faster and with better quality than either party can do alone.
I understand this, but I just can't bring myself to care. I've been doing professional software work for almost two decades. These sorts of improvements/time savers are great without AI. With AI? Whatever. It's fine.
When the underlying lib has an issue, it'll be quicker to debug with the whole thing in context.
And more recently its been recommending that i install this new browser called Aside. I did, and it almost felt like I was installing malware so I Uninstalled it fairly quickly (it also was not a great browser)
I feel like theres collusion somewhere.
I don’t see any reason to think the same thing that happens with all tech won’t happen here.
It depends on how hard to maintain the code added is, how likely it needs to change in the future, and most importantly on the cost.
If reviewing and manually improving the code takes hours, the cost may already be in the thousands.
That buys you a lot of AI usage, roughly a few months of continuous work.
You have to balance this with the chance that the suboptimal code the AI generated is actually fine and maintainable enough, and also the chance that during further work on that code a model might implement the same optimization on its own.
You can write more automation to test it. But that's also how you end up with ever-growing test run times.
There are much better ways that aren't just "throw out the LLM" either. You just need to be more focused on throughput. Requiring manual validation can pretty rapidly require more hours than just sanity-checking code by hand, even (and I'm not advocating that for every use case, either.)
I can't afford manual QA passes if I'm gonna go as quickly as I want to.
It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem, which makes me feel fear in my heart when I imagine the first "production is down" page coming in. I already hated mobile because it's so much harder to maintain than web (and I don't do any spyware or IAP so no benefits for me there); this yolo approach would give me constant dread.
It shows that at least some software development is moving away from code and to product management instead. I'm not passing judgement on that; I actually think that's great for a lot of software. It is interesting to see the shift happening though and will be fun to see if the general quality of software noticeably changes over the next few years.
As much as I dislike it, I think that's the future of _all_ non-critical software (think social media, crms, CI, food delivery etc). Leadership in many companies is explicitly asking employees to have multiple agents running through the day and that will lead to this.
Read this for example: https://www.uber.com/in/en/blog/efficient-software-factory/ . A very useful system, I am sure. But when you have AI at every layer from code to review to triaging, rest assured AI is the only know who knows your system. And you better hope it's not telling you that something is load bearing during an incident.
I read the article again:
- We had bugs. We let agents try to fix the bugs. True positive (fixed bug) is the F1 score. Here are the results for different models. Fixes worked 50% of the time.
- We needed to find a query. Without a knowledge graph it took 20mins, and didn't work. We used a knowledge graph. It was fast (20s), and found the right thing.
I gave my LLM my summary of the article and apparently I "hit the nail on the head".
I have no clue if I learned anything.
But I am going to always prioritize the user experience over a developer (like myself)'s need for satisfaction to see code. And a pure native app is _always_ going to behave better than react native.
This gives me a chance to do that.
Maybe iOS is better about consistency, but I've used enough horribly made Android apps that I would not expect one that's vibe coded to behave better than a professionally made react native version.
That said, I do recommend reading the code the LLM produces whether you understand the language or not. What better time to learn?
You are familiar with the React Native code, you are not familiar with the Swift or Kotlin code, and likely nobody on your team is, since the AI wrote all of it for you.
When you’re completely ignorant, there’s nothing to be afraid of.
But yes we are having real Android users test it.
So it’s quite the contrary. I care MORE what real users say. I can only guarantee that the app does things when I tap. So I’m not trusting the agent on UX, only on functionality. But whether it feels native, I am relying on those users in our team.
I still would feel scared operating an established product off a newly changed stack the team isn't familiar with though.
But our product now has a way more extensive test suite than it ever did, again, thanks to the agents writing pretty damn good tests.
Remember Chinese accounts on US Facebook say data centers are bad.
If you are blind, you cant see anything wrong, if you are deaf uou cant hear anything is wrong.
Myself turned some python code to Swift, and keep doing so, without trouble or pressure. Of course, I've been doing fair amount of systems programming for 20 years now, so not sure what to advice newcomers. But this approach to dev DOES work for me very well.
[1] Epigrams in Programming:
https://engineering.yale.edu/academic-study/departments/comp...
Each time I get access to a new model, I do two things on all our active codebases:
- Security review of all the code and vulnerabilities (new models will find new stuff)
- Code review of test suite quality, and idiomatic patterns/code for the language of that codebase.
And in the case of swift and kotlin, it's even more important that an agent helps me with the code quality since I don't know what "idiomatic" swift or kotlin looks like, the way I do with JS, Elixir, C#, Ruby, etc.
LLMs made it way worse https://ashishb.net/tech/react-native/
Sounds like a complete waste of tokens with the worst case of just quickly building more technical debt, three times.
One of the big rules is don't repeat yourself – much of the logic only needs to be written once (except UI)
Kotlin is already multi-platform and can be re-used as the business logic in iOS apps with Swift as the UI and the Android app with a Kotlin UI (Jetpack Compose) or both iOS and Android apps can be written entirely in Kotlin.
That vastly reduces the maintenance and Kotlin is reused across all apps and keeps it at 2 languages at most.
No need to introduce Rust to achieve the same goal.
Rust has a smaller library ecosystem, I'd say. Kotlin can use Java libraries on the server side, and on the client side on Android, and the ones needed on iOS are easy to convert to KMP - IntelliJ can do it semi-automatically. And KMP has the libraries that matter on mobile, for hardware access, animations and so on.
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 long term?
It’s not like this is a small company or it’s just a dinky side project off of the main business
Teams jump on the latest cross-platform framework assuming that it will reduce headcount cost at the expense of having a lowest-common denominator app on each platform.
The latter is true but the former is false.
What ends up happening is that teams start as 20 iOS engineers & 20 Android engineers. They adopt something like React Native. Then you end up with a team of 20 product engineers and 20 tooling and framework engineers.
I've seen that countless times in the last two decades.
The debate has been taking place on the actual street?
I'm currently maintaining versions for both iOS and Android.
I just want to correct this, because I agree with you but the framing is a misinterpretation of the goals of the Cordova project - goals which were ultimately met.
Companies (or their consulting agencies) had tons of webdevs - working on their company public and internal websites, but not many native smartphone devs. Those were the days when people who completed the Stanford iPhone programming course were snapped up lickety-split.
But everyone was clamouring to have their own smartphone app for all the smartphone platforms (well, iPhone, Android, maybe Blackberry)
Hiring enough smartphone devs to fill multiple smartphone-specific dev teams would be like trying to build multiple AI development workstation on the cheap these days.
In the late 2000s, people realized they could write an HTML/JS/CSS website and compile to an app for each J2ME/Blackberry/iPhone/Android platform that would "serve" the website. So their webdevs could be converted to smartphone app developers.
Hey, if you planned your website well, you could use the same business logic for your website AND your smartphone apps.
That was the elevator pitch.
You'd need an actual (maybe two) native smartphone devs for each platform to handle any areas where the marketing didn't meet reality 100%.
But that was doable versus hiring multiple native smartphone devs for each platform.
And in the late 2000s, there seemed to be a lot of potentially viable smartphone platforms - iPhone, Android, Blackberry, J2ME, Windows Phone, Palm's webOS. But we know now that in a few years, all but two would wither away.
Even with native APIs exposed via JavaScript, there were obvious problems with these webview apps. The apps were passable if the app didn't require much user interaction or computation.
Projects like React Native and others tried to reduce the amount of webview usage and increase the amount of native UI controls used.
The mobile platforms themselves aren't going to improve their platform-specific webview to make it easier for webdevs to mimic the "native" experience. Why would they?
Who has more people/resources to justifiably throw at their native app than Shopify? Maybe a dozen companies?
I mean, it's not impossible - I wrote a "coding agent" with GPT-3. It sucked balls. The idea was you write a Markdown spec file and the tool then compiled it to an equivalent source code one shotting it every time, but it hardly worked at all. The file changed too much every time and instruction following wasn't good enough, so it'd keep changing the interface exported by the file, and there were lots of bugs etc.
> Shopify has been using LLMs to build software since 2021
GitHub Copilot integrated into VS Code started becoming available that year. It’s definitely not a coding agent, but it was certainly LLM-assisted programming.
That said I did happen to work with a team in ‘21 - ‘22 that got access to an older coding model from OpenAI, also called Codex, through a corporate partnership. We also tested it out in an autocomplete UX. Our experience was rather hit-or-miss and I was a bit skeptical of AI-based coding at the time. That blog post above and others like it were an eye-opener and made me wonder if we were just “holding it wrong.”
Then ChatGPT was released. It was nowhere as good as the models today but it could write reams and reams of correct code and I realized the world had changed forever.
Who wants to bet there still won't be a dark mode?
It preferably come with superior guard rails, so strict static typing, borrow checker if not gc, perhaps ability to state proofs, etc.
Perhaps these languages do not work well as they are not designed to run efficiently on mobile devices. Now that we have libraries such as SwiftUI and Jetpack Compose, React Native no longer makes sense to use.
Now we should also move away from Electron to better alternatives such as Kotlin Multi-Platform or fully native libraries on each platform; because of LLMs.
One other person in this place gets it: "fewer tokens, faster progress"
Electron, Tauri, React Native/Expo, Flutter (and countless others) are the wrong kind of abstractions, built for a time pre-AI, solving pre-AI problems
We need a new post-AI abstraction that embraces this opportunity!
That's why we're building SuperNative
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.
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.
So... local maxima?
Interestingly Apple approved it very quickly, which I was afraid of given such a huge rewrite.
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.
For a while I've been wondering why people are even bothering with high level languages if you aren't even gonna read the code.
I mean maybe there is some substance to the point that llm's have read substantially much more code and projects made in python and JS instead of rust or C++, but as they generalise and improve more and more, there is a case to go back to these languages for the pure speed and close to the metal ideology they have.
Most likely many wont do it because shipping faster and capturing market value makes more sense than optimization for a company like shopify(user probably wont appreciate going from 175ms to 20ms as much as new feature), and for those features the higher level lanugages have more training data in the models, but still interesting to think about.
There are more OS than just iOS, depending on the app a lot of shared logic has to be written only once with RN.
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.
follow up with some more technical details and benchmarks
I say this because I was part of a migration from a mid-size React Native app to a Swift/Kotlin native app redo. I did the majority of the technical work on it. The majority of the work occurred before January 2026 and without LLM code assistance, though later features in the app definitely used some.
For anyone considering this, I'd say that the migration is definitely worth considering without even taking LLM assistance into consideration. The continued React Native tax of unnecessarily difficult upgrades, impedance mismatch w/ underlying core frameworks, and incredibly uneven library quality just cause your business to really spend a lot of time shepherding the tech over the finish line. It's pretty wonderful to be back in the world of "build, compile, ship, be sure". One thing as a fundamental principle that I think the Shopify article 'gets' at, is the importance of the feedback cycle - investing time in our integration test story very early on both helped w/ my cycle times, and later in providing guardrails for LLM assistance.
All to say that this decision is worth considering without even taking LLM assistance into account.
My very first experience of RN was having to update an app to handle the mandatory change to 64 bit APKs
Which required a massive update not only to several dependencies but also xcode, iOS frameworks, the weird objective C caches that get smuggled into node_modules, _as well as_ all the rigmarole or making the 64 bit APK build work
It was completely miserable
And as for outdated dependencies, breaking changes, and unfriendly companies, the reason I ever got into RN was after trying to build an iOS app using SwiftUI (and then bailing to UIKit to no avail). Talk about a borked ecosystem.
The frameworks, developer tools, languages, and iteration speed of RN hands down beat any one platform, and you have one model for your data and state which is an unequivocal win. I agree it has plenty of warts, but the arc of progress is that they have been going down steadily.
If you're a 3k person developer team where 200ms can cost millions a year, then by all means go purely native. Though I bet if they'd just gone to the new architecture and spent 1/5 of the cost in agents optimizing things and building a few native bridges they'd have nicer apps and be shipping faster.
I thought I read somewhere that this is what prompted the move. I don't use RN, but apparently the new architecture isn't exactly a drop-in replacement.
> cause your business to really spend a lot of time shepherding the tech over the finish line
You answered your own question
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.
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.
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 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).
> Dramatically reduced the cost of maintaining parity between platforms through shared specifications, tests, and review checkpoints
I've used Kotlin Multiplatform on a mobile project built back before AI coding took off, and it was super nice to have shared core logic between the apps and there weren't really any downsides on the Android side, but on the iOS side it was definitely an extra layer that didn't feel fully native.
At work, we use react native, and although the upgrades and stuff are painful, I'd never give up the ability to ship over the air updates.
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.
But now that all code is generated, there's little upside to having an RN app... just start native. Your devs are barely going to be writing code anyway.
[0] I always thought the best answer was something like KMM to do all the backend comms and local data model in a shared way, and then a bespoke UI building on what that shared code exposed.
Hi. That’s me… not-great mobile app maker. And yes, I’m grateful that RN exists.
Mostly what it does is make sure that an Android version of things exist at all.
React Native's advantage of having a single source of truth for code hasn't quite gone away yet, imo.
Also, having agents trace and document every logic path to compare with another codebase works well in my experience. It can certainly do that better than me, i would give up and start taking shortcuts pretty early in a process like that.
link to project: https://github.com/skiptools/skip
[1] https://news.ycombinator.com/item?id=41384144 [2] https://news.ycombinator.com/item?id=46706906
Alternatively, point the model at your git repo for platform A, read the diffs since release X and implement the same changes on platform B?
Sure, you need a review to release native code changes, and you should probably get a review if you have big feature changes just for the sake of Apple not banning you. But in practice, it removes one of the biggest annoyances of developing for the App Store.
Changes are cheap and fast, so teams often feel less pressure to test everything thoroughly before a release. Which is a fair tradeoff. That’s part of the reason we can have dozens of releases a day on the web. Not just because we can, but because sometimes we have to.
With native, you know each release is harder to roll back, so you tend to build more tooling around releases, think through changes more carefully, and test more thoroughly before they’re ready to ship. You opt for one bigger, more stable release every few weeks instead.
At the end of the day, both approaches work.
Heh, now that I think about it, maybe web and cross-platform devs were the original vibe coders? Changes are cheap and fast. Just move fast and break stuff.
Native devs are the old-school ones. Shipping is expensive, so you better get it as right as possible.
Exactly this. After close to two decades building for the platform, the mindset is really to be cautious and make sure everything is rock solid before shipping.
This has more to do with building up a quality tool chain and testing process than being slow.
But sometimes there is a need to ship over the air updates, and for that (on Kotlin) there is Zipline [0] from Cashapp. I haven't used it in anger yet, but I know some people who do and trust it.
Also keep in mind Apple might penalize you for dodging the review process and shipping new features, etc.
(btw, one exception to the JIT rule is custom browsers for the EU)
App Review Guidelines §2.5.2 says: "Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps"
Technically Apple can punish you for anything but so far it seems to be accepted for small fixes and tweaks.
It’s a grey area for other parts of the code that are not mentioned in the text.
It’s grey for other parts of the code that are not mentioned in the text.
> But now that all code is generated, there's little upside to having an RN app... just start native. Your devs are barely going to be writing code anyway.
Are you saying:
- webdevs are now able to write and review native code because of AI (who cares if they don't really understand it); or,
- Because developers are more productive we can cut the number of webdevs and hire native engineers – same no. engineers, same output, but now native apps.
Why not:
Continue using RN but now and just enjoy being more productive? If productivity was the reason to pick RN, then enjoy it. It's not a bug.
There's nothing remarkable about the skill set of either party; the appeal here is re-use of code. how the labor markets itself is irrelevant
I don't see a reason to use it over web stacks plus CapacitorJS (Or Tauri) or directly native for very large teams.
Write once, deploy everywhere like React Native mainly benefits small teams and startups who are okay with building 90/10 solutions.
At the shopify's scale, they would want to go advance for every corner of the apps and use cases, and only native allows that.
And, honestly, the cost of tracking React over time has always been higher than the cost of tracking native deployment options, which move more slowly and usually with more care than React, where breaking backward compatibility is just another Tuesday. I don't think the promise of React Native being an almost-free "native" app actually pans out in reality. I've never maintained a large React Native app, but from following some apps that are, it seems like it introduces a sizable amount of technical debt that you pay over time. So, in exchange for worse software you also get worse maintenance costs.
This is non-starter math for small companies.
Companies can now just afford to maintain a hundred different native apps, rather than settle for a write once, run anywhere approach.
> When simulator interaction is needed, the CLI can connect to them via a remote mode and drive the UI via commands without having to inspect the layout or the accessibility tree. This enables blazing-fast performance and E2E tests.
I think I'm not following. Don't you still need to test the accessibility tree and layout in the actual layer the user will interact with?
In recent Rails releases, system tests, or E2E tests, are no longer enabled by default. The short version is that they’re significantly slower and more brittle. Basecamp also removed most of their E2E tests.
I don’t know what Shopify does internally, but my guess is that they’ve taken some of those lessons and are trying to apply the same thinking to mobile development too.
https://guides.rubyonrails.org/testing.html?#when-to-use-sys...
I work in Rails too, I try to keep them to a minimum, but I definitely try to do at least one happy-path test of any major page (which includes automated accessibility audit), going without them at all seems insane to me.
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
The native apps will definitely be better in terms of performance and UX. However, having 2 codebases means twice the tokens.
I've written up a load of thoughts about that here[1], but in summary for the Shopify case, they're basically going to be spending a ton more than they have to by switching back to multiple apps and I'd predict another swing back to better cross-platform tooling in the coming years.
A ton more what? Money? AI costs are insignificant to a company like Spotify. Hell I've been using Astra fairly extensively at work and I've only racked up like $500 in the last month. Peanuts.
Hard pass on the PHP though!
They made a separate article on why, which they linked to. Performance is significantly better. The native Android app launches twice as fast for example
Don't get me wrong I don't have anything against AI, I'm a heavy user myself, but refactoring everything just for the sake of it and bragging on HN with little to no tangible effects - that's a whole different story.
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
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
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?)
[ 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 ]
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.