As an iOS Engineer that has been fighting the battle against every C-level type who brings up the subject of a shared codebase my whole career, I feel very validated.

They specifically say in the post how React Native was the correct decision and that it worked well for them.

Now it's a different situation as implementation has become incredibly cheap.

Not sure why someone would say it was a wrong decision. Why would they even need to do this if LLMs make coding easier. They are likely chasing the things I advocate for: direct access to latest APIs from each platform, platform specific UI, UI that behaves correctly on each platform without chasing down edge case solutions (also said as ui that looks and feels "right"), and a bonus of separate developer pool to hire from that knows the ins and outs of the platform without needing to hire a developer to know all three- react, iOS, and Android.

> Not sure why someone would say it was a wrong decision.

Writing almost anything with javascript sucks ass to begin with. Writing native code with it is even more painful. Most javascript engines don't even have any decent model of parallelism. It takes zero imagination to see the problem here

how much parallelism are you writing in your frontends?

The problem with everything being single threaded isn't so much that you want to do a lot of parallel processing, but that you don't want to have the occasional fat loop cause the whole engine to start stuttering. If you want butter smooth scrolling while there's (for example) a lot of dynamic content moving around, you want very precise control of the threading so you can get the gnarly stuff done without causing hitches that don't feel right.

The browser, iOS, and Android all use a main thread separate from the thread responsible for scrolling animations.

However, I think it's true that controlling threading in order to perform gnarly work in a separate thread is more ergonomic on mobile than in JS/React.

You'd need to create a Promise that wraps a Web Worker, which would be an unusual thing to use. I don't think most apps need such control over threading in the browser.

If you care about smooth interactions, the browser even in 2026 is not the most straightforward route, nor the route any reasonable small company takes.

I mean, why would they admit to it being the wrong decision. Its a business.

Why would they need to worry about hiring for specific skills at all? As AI progresses, isn't the only skill that matters that you can drive it effectively (which encompasses testing and review) without needing oversight?

Because we are not there yet and you can't oversee something you don't know

> worked well for them

yeah because they don't care about a top notch user experience.

Yeah they do say that but as someone who has worked on native apps / RN for most of my career I think that is bullshit. They're not going to come out with a mea culpa owning that, this is as close as it gets.

FWIW, the native app specialists are in some sense the most invalidated here. Shopify decided they couldn't afford your skill set and didn't change their mind until you could be replaced with an LLM.

Really the whole concept of technology specialization is the thing in jeopardy. It no longer appears to work to make a career out of deeply learning something obscure. Agent-farming generalists appear to be the ones who own the future right now (if, heh, not the agents themselves).

My validation is that platform specific codebases is what is the right course of action. The c-level decision is that they want the cheapest route to consumers. My point is that consumers can tell, the product is better, and developers are happier working on native codebases.

I'd challenge you to determine which of the top app store(s) apps are react native vs not -- plenty of app store awards have gone to react native apps -- bad software is bad software. plenty of you ios devs write shit software. I've done this job almost 40 years and no language or platform has ever prevented people from building shitty software or for that matter gotten in the way of writing good software. good engineers can figure it out.

source: ios dev since it was possible -- I am not even pro react native, I am just pro merit based arguments -- you aren't making any

Challenge not accepted but deferred to the article where one of the largest business wants to sit at the intersection of native apis without a a middle layer for the sake of saving money. Put another way, given unlimited resources, native wins out over shared.

You should read the article. You'd realize that you're not actually vindicated by its contents.

I read it. They chose native over shared. Hence vindicated.

Derp. Read it again.

Shopify is moving its mobile apps from React Native back to native Swift and Kotlin. With the main cost of native gone, the benefits of staying close to platform APIs and first-party tooling win out. This has been my ethos. That native is better than shared.

Your argument was you've argued your whole career for native. The article argues only very recently the cost equation has changed. Your argument reads like you are not taking into account the broader context or the passage of time.

I'll put it this way, my argument was pro native. And in the context of the article, if a large company had unlimited resources, they would choose native. I'm not discussing the business case for it, but the end result of it being the better option. It can be seen as "Shopify tried Reactive Native and left it behind the second they could after sinking resources into it for 6 years".

Everyone always knew native was better if dev cost weren't a factor

Go back in time and read the react-native vs native debates. Many react advocates claimed otherwise

Time and progress have overtaken them. At the time they were likely correct but I certainly wouldn’t bother with react native any more when the LLMs have gotten so good

What was the claimed advantage of react-native aside from ease of use?

I don't see why you would, unless your argument for your whole career has been that LLMs make this easy.

My argument is that platform specific codebases is the right course of action. My point is that consumers can tell, the product is better, and developers are happier working on native codebases.

> developers are happier working on native codebases.

Agents are happier working on any codebase, but ultimately Shopify and other companies want iOS native app level quality without the huge cost of hiring many native iOS / Android devs.

LLMs and Agents deliver on getting a native app out at lower cost, higher quality, faster all at once.

I think everyone is trying to tell you your skills as an iOS native dev have been commoditised and Shopify and others don't need to hire anymore native devs to find this out.

I don't see how your job being completely commoditised and cannibalised by LLMs replacing your job is some how vindication?

This is just like saying "we won the argument", but what did you actually "win"?

Yea, I hear that. I'm content with winning the argument and truthfully, I think they will find they need to hire iOS engineers because we do more than write Swift. There are whole ecosystems of knowledge to go from a product idea, sit in meetings with many stakeholders, and implement the actual thing everyone wants. All they got here was a 1-to-1 implementation of their current app which was born of engineers working through real constraints. It says nothing of new features that have to play nice with other pillars of the company.

> I think they will find they need to hire iOS engineers because we do more than write Swift.

Shopify isn't hiring any mobile engineers.

Probably because the agents were hired first and took the job already.

That is the point of the job being literally commoditized and cannibalised, they hire less or close to 0.

Your quixotic 'vindication' means nothing and has the opposite effect.

Not sure why you are defining my vindication. Its purely rooted in native is the better solution for mobile apps. Which they are using. Not sure how that makes it the opposite.

You're looking at it from iOS side only, and for a US company that would be the last platform they'd ever drop.

It was a different picture out of the Apple garden, when a company only brings their next major feature to iOS because they couldn't be bothered to hire the same headcount on two development teams and their CEO uses an iPhone anyway.

We had that discussion about a decade ago with a company rep that didn't realize 70% of their EU users were on Android yet their play store app didn't have the feature they were planning to promote.

Basically, better was the enemy of good for most companies.

Correct, I advocated for the solution that produced the best outcome for user experience, code and architecture simplicity, and prevented having to rewrite an app in the future in native. Which has been validated here.

The android shortfall is a real one but I also pushed for hiring native android developers too.

As someone who has watched a team battle Xamarin and now Maui, and all the painful upgrades in between, I agree with you. Sure they never had the pain of supporting two separate codebases, but they also never had the luxury of doing anything the easy way.

We'll have to wait and see if the extra maintenance / bugs / attack surface is justified. This an announcement of future direction so vindicated is certainly premature.

They're right when it makes business sense, which is also about cost and why Shopify didn't do it before.

I'm not arguing the business sense. Two sides can be right which is why I advocated for native development. Which is vindicated here.

If you weren't arguing against the business case, what were you arguing with the C-level types about? I don't think I have ever heard a case for react that wasn't centered around shared codebases mean fewer resources/cost/time to deliver a feature.

Because someone needs to be in the room to show the “make the most money with the least resources” people that there are more variables to consider.

In other words your team also resigned the next day ?

I'm inclined to agree on certain points; true native apps are, generally speaking, better when it comes to e.g. customer experience. It comes with risks and costs (but I think the cost vs benefit is exaggerated) - risk being the ability to find good native developers, which aren't as common as e.g. web developers who can switch to RN fairly easily.

But there's a factor few people (that decide on using RN) miss; it adds a layer of indirection, so you're no longer as "in touch" with the underlying platform. While possible, few RN developers would consider adding widgets or smart watch apps to their main app, but (I feel like) if you're a native iOS developer who is all-in on the Apple ecosystem, you're more likely to try and adopt these features (where applicable).

(disclaimer: RN is my current day job, used to do native iOS development and I frequently miss it)

Same here. Glad I stuck with native iOS development. I still haven’t switched to SwiftUI though (except for some small stuff). Still sticking with UIKit here.

If only LLMs had been invented at the beginning of your career, you would have been right all along!

Just want to say hello fellow culinary -> software engineer migrator.

Now you two just need to figure out the eventual transition into woodworking and you've officially done the lot ;)

oh trust me, I have made almost all of my furniture. It was inevitable.

They're saying "I can see logical ways we can deal with this but the common folk are afraid of technology and change"

More like "it's not socially acceptable to discuss alternatives to orthodoxy", but yes.

How do you protect the risk from falling on society? I think that is the crux of it, it is not something you can cleanly separate which is where regulation steps in. The question is, how much money and influence can these companies shore up before that regulation hits?

I have mine self record into Supabase for my projects and a local sqlite for work. It determines a method of record keeping which I audit every week to hone the process. Really makes it so I can move to any provider I want and I have a queryable memory store. Also really helps when someone asks about why some feature was implemented a certain way. I also have it learn from corrections in PRs and comments made overtime in a repo to get the shape of what is important to the team at work.

> It determines a method of record keeping which I audit every week to hone the process

I would like to hear more details of what it ended up with for a structure

I'd argue that emotional co-regulation is born out of biological origins. Unless we are making synth, it would be a long time to match the relationship with a living creature.

I dusted of my lightest computer with an M1 chip and use Tailscale to make my network virtual from anywhere. Been running a. Pi5 as a main house hub and an M1 Pro as an always on Mac. It would be nice to go all out and make a Studio a hub I can just screen share into for major compute.

I like this train of thought. The inverse is saying that the cost of this computer is the value we give away to AI companies by doing compute on their servers with our data. And to take it another way, is the value to you, the cost of a small used car?

> And to take it another way, is the value to you, the cost of a small used car?

For me personally, not quite that valuable yet, but I think it's getting there quickly. Deepseek V4 Flash massively increased the value of local AI to me, to the point where it's displaced most of my Claude Code usage, its upcoming vision enabled version should bump it further, and it's only going to get better from there.

It's a lot faster, but a lot of it is also feeling free to discuss things I wouldn't be comfortable sending to Claude, with the idea that that info is now theirs in perpetuity. I got my genome fully sequenced recently (it's cheap now!), and I get a battery of blood tests every year. Wouldn't do processing on any of that with Claude, but local AI? Totally great.

And if I was running a company with a large cloud AI bill, I'd probably buy a wheelbarrow full of these macs. Cheaper, but also a more solid/predictable base to build on.

Yea, I've started making it write linters to check the code that goes out. Anything that can be deterministically measured, gets added to it once we lock it down.

Needs a scroll that becomes a full page ad that when you scroll pass becomes the same ad but 1/3rd the page

And if you scroll back up the content above is completely changed to something else.

Don't give them ideas... LoL

That is already deployed to real web sites.