I'd challenge you to determine which of the top app store(s) apps are react native vs not -- plenty of app store awards have gone to react native apps -- bad software is bad software. plenty of you ios devs write shit software. I've done this job almost 40 years and no language or platform has ever prevented people from building shitty software or for that matter gotten in the way of writing good software. good engineers can figure it out.
source: ios dev since it was possible -- I am not even pro react native, I am just pro merit based arguments -- you aren't making any
Challenge not accepted but deferred to the article where one of the largest business wants to sit at the intersection of native apis without a a middle layer for the sake of saving money. Put another way, given unlimited resources, native wins out over shared.
Shopify is moving its mobile apps from React Native back to native Swift and Kotlin. With the main cost of native gone, the benefits of staying close to platform APIs and first-party tooling win out. This has been my ethos. That native is better than shared.
Your argument was you've argued your whole career for native. The article argues only very recently the cost equation has changed. Your argument reads like you are not taking into account the broader context or the passage of time.
I'll put it this way, my argument was pro native. And in the context of the article, if a large company had unlimited resources, they would choose native. I'm not discussing the business case for it, but the end result of it being the better option. It can be seen as "Shopify tried Reactive Native and left it behind the second they could after sinking resources into it for 6 years".
Time and progress have overtaken them. At the time they were likely correct but I certainly wouldn’t bother with react native any more when the LLMs have gotten so good
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.
So disagree. The benefits you get from leveraging a framework as as important today as they have ever been -- strong frameworks, fewer tokens, faster progress.
One other person in this place gets it: "fewer tokens, faster progress"
Electron, Tauri, React Native/Expo, Flutter (and countless others) are the wrong kind of abstractions, built for a time pre-AI, solving pre-AI problems
We need a new post-AI abstraction that embraces this opportunity!
I've been around long enough to see this argument come and go under a lot of different names. This time it's AI. Maybe AI really does change the economics. But this post doesn't demonstrate it.
Talk to me in a year.
The side-by-side comparisons? Whoopty do. It's different code. Of course agents can produce two implementations that look the same today. That's not the hard part.
The hard part is keeping them the same.
Feature parity isn't an implementation cost. It's a divergence cost. It accrues over years across experiments, analytics, accessibility, edge cases, bug fixes, platform behavior, and a thousand little decisions which current agents aren't great at tracking.
Agents can write code fast but they aren't a panacea.
The load-bearing sentence in the whole post is this:
"Shared specifications, tests, and review checkpoints dramatically reduced the cost of maintaining parity."
Okay. For how long? By how much? Got any numbers to share? How will these hold up under contact with customer?
You haven't maintained parity yet. You've built prototypes. You're making a claim about a cost that compounds over time based on what it costs at t=0.
The other thing missing is the counterfactual. They keep comparing this rewrite to what a rewrite would have cost before coding agents. But what if you point those same agents at the existing RN codebase?
If agents make software development cheaper, they make RN development cheaper too. And now you're modifying one implementation instead of generating, testing, reviewing, and reconciling two.
The tooling section makes this even stranger. They find that agents are bad at driving simulators, so they pull business logic out of the UI, make it runnable headlessly, and expose a CLI.
That's a good idea! Do that!
But that's an architecture change, not an argument for native. You can make an RN codebase agent-friendly without rewriting five apps.
Then you get to "Preventing slop," which is probably the most important section in the post. Just pointing an LLM at the codebase doesn't work. They had to build Helix, with ordered checkpoints, test proofs, visual diffing, adversarial reviewers, and human gates.
So what they've actually demonstrated is that Shopify has enough engineering resources and agent infrastructure to make maintaining two codebases look economically plausible.
Maybe it is! For Shopify.
That's a much narrower claim than "AI changes the economics of cross-platform development."
And where are the numbers?
For a post about reevaluating costs from first principles, there's remarkably little cost data. Engineer hours? Review time? Defect rates? Parity failures? Agent spend? Ongoing maintenance? Anything?
They even say RN performance isn't the problem. "React Native apps can be fast. Ours are."
So there's no product crisis here. No performance crisis. There's an internal cost argument, with no numbers, being used to justify rewriting five apps used by millions of merchants.
And in isolation I'd probably just shrug and say: Shopify made a bet. Let's see how it goes.
But it's harder to view it entirely in isolation when they brought Tailwind on yesterday too.
Shopify used to be one of the great stewards of the broader ecosystem. What worries me about the recent direction isn't any single technology choice. It's the appearance that, following the recent tech leadership changes, we're starting to see decisions driven more by the preferences of the people now making them than by demonstrated technical merit.
Maybe that's an unfair read. I hope it is. But posts like this don't help, because if you're going to make a sweeping technical argument for a major change, show the evidence.
The part I actually find convincing is much less exciting: Shopify is tired of paying the upstream tax. They've spent years working on RN performance, improving the framework, dealing with dependencies and upgrades, etc.
Fair enough. That's a real cost. Being an RN framework developer or dependent is -- or has been -- awful -- it's like trying to fly a kite in a hurricane. The web team has been super disciplined and also ridiculously slow. The RN team changes apis in .. questionable ways with regards to compatibility
But it's not new, and it has very little to do with LLMs.
And let's not get me started on taking this kind of dependency for your business on companies who still don't have any idea how much to charge for their tools and are all operating (on a per token basis) at a loss. They're swapping some framework dependency for dependency on coding models whose capability, pricing, and terms they don't control.
None of this means they're making the wrong decision. Maybe they're right. Maybe in three years this looks obvious.
But that's exactly the point.
Come back in a year and show me parity bugs, engineering hours per feature, experiment drift, accessibility regressions, review burden, model spend, and how much human work it takes to keep the implementations aligned.
Right now they've shown that AI makes rewrites cheaper.
For people with medium and high end devices, SPAs are mostly fine. For those with low end devices (which is a large part of the world), SPAs sometimes don't work well and this is true of many UI frameworks.
Real human beings benefit with you ship less code. And, if people are paying for data, which a lot of people still do, this matters.
Impressive to try and moralize this, but as someone born in "the large part of the world" you're aggrandizing for the typical project made in Next... I assure you that shipping a basic non-React project will be infinitely more appreciated than what RSC is enabling when combined with the style of frontend React encourages even if you do just render it down to a string.
> Real human beings benefit with you ship less code.
Real humans beings benefit from reliable and well-made applications more.
The difference between an good engineer and a truly excellent engineer is understanding how "worse" technical choices can result in a better user experience.
Junior engineers obsess over low level metrics like how many lines of code they right, but for some reason people graduate to obsessing over how many bytes of JS they shipped and don't think for a second:
- "how much of a surface area did I just open up for bugs in my chase?"
- "how much productivity spent catching up on this new paradigm would have been better spent making what my users want and need rather than tinkering with implementation details?"
- "how is adding this convoluted multifaceted multistep approach with an unstable technology going to affect the stability of my application?"
- "how much harder did I just make it to solve the bugs I do know about due to indirection?"
You're shipping less code down the pipe but you're dragging in insane amounts more code at every step of the way from compilation to the server runtime to enable it: the net result is a buggier, more complicated, less reliable application.
Of course, when you make money off people not thinking about this stuff, you don't encourage discussion of it.
source: ios dev since it was possible -- I am not even pro react native, I am just pro merit based arguments -- you aren't making any