upvote
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.

reply
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.
reply
> 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

reply
how much parallelism are you writing in your frontends?
reply
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.
reply
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.

reply
deleted
reply
I mean, why would they admit to it being the wrong decision. Its a business.
reply
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?
reply
Because we are not there yet and you can't oversee something you don't know
reply
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.
reply
> worked well for them

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

reply
You should read the article. You'd realize that you're not actually vindicated by its contents.
reply
I read it. They chose native over shared. Hence vindicated.
reply
Derp. Read it again.
reply
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.
reply
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.
reply
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".
reply
Everyone always knew native was better if dev cost weren't a factor
reply
Go back in time and read the react-native vs native debates. Many react advocates claimed otherwise
reply
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
reply
I don't see why you would, unless your argument for your whole career has been that LLMs make this easy.
reply
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.
reply
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.

reply
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.

reply
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.
reply
They're right when it makes business sense, which is also about cost and why Shopify didn't do it before.
reply
I'm not arguing the business sense. Two sides can be right which is why I advocated for native development. Which is vindicated here.
reply
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.
reply
In other words your team also resigned the next day ?
reply
> 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"?

reply
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.
reply
> 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.

reply
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.
reply
probably because every react native app they've used feels like shit
reply
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)

reply
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).

reply
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.
reply
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

reply
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.
reply
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.
reply
If only LLMs had been invented at the beginning of your career, you would have been right all along!
reply
what they should've done is written logic etc.. in rust and use mobile app just for native layers, so they can still share code.
reply
[dead]
reply
[dead]
reply