Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shopify is moving from React Native back to Swift and Kotlin

shopify.engineering

Post reply on HN
Print view View original

951–960 of 1001 posts

Re: Shopify is moving from React Native back to Swift and Kotlin

#951

Post by hn993302 »

akmarinov wrote: post #679
hn993302 wrote: post #669

Earlier quoted context omitted.

Do you even escape dependency hell this way?

Yeah, with iOS for example, you typically need very little third party dependencies for functionality. The main ones are things like analytics, crash reports, etc I’m not aware of any attacks on native package managers in the past 5 years. The closest would be a poisoned Xcode build in China that wasn’t downloaded from Apple a while back. Also getting an attack on one of the platforms means at least ~half your users…

I remember there being a lot of hijacked CocoaPods more recently than that Xcode attack. But supposedly Swift Package Manager is actually replacing CocoaPods now, which tbh I didn't even know until now because I've been out of that loop.

So that's good. One of my larger gripes with native Mac/iPhone dev was always needing to rely on a third-party package manager with all its quirks.

Re: Shopify is moving from React Native back to Swift and Kotlin

#952

Post by [deleted] »

alt227 wrote: post #825
darkvertex wrote: post #752

Earlier quoted context omitted.

15 years of extremely well paid engineers and yet we still cannot delete a track from Recently Listened. ಠ _ ಠ

Recently listened is an automatic list like a log, not user curated. I would never expect to be able to delete things from that list.

[deleted]

Re: Shopify is moving from React Native back to Swift and Kotlin

#953

Post by RobKohr »

hilariously wrote: post #858
Keyframe wrote: post #836

Earlier quoted context omitted.

I agree with what you're saying that it's not exactly what we're seeing which makes it not as simple. However, I've seen this play out in many a big companies where there's a big mess going on. Answer is always similar pointing to -> "clearly it's not simple" and that's kind of the whole point. They made it not simple. 3k ENGINEERS, my sweet dude. THREE THOUSAND. By any and all account that's half as much as current…

Taxes, compliance, regulatory bodies, logistics multiplied by X countries X products has an amazing way to bog you down. If you have money and problems money solves (eg you could hire more people to do something) you do not have a problem (except for people on the internet making arguments from personal inexperience)

I think there is something like Parkinson's Law: "Work expands so as to fill the time available for its completion."

This is more like the engineering team scales to match your budget.

It is why successful companies, when starting out and getting to their defining project completion state have significantly less engineers then 10 years later when they are massively more successful.

The cost of having the engineers is nothing compared to the profits, so why not hire more so you can defend your position. Are 80% of them needed to keep the system going, I think Elon showed that you can prune most of them away and the system will keep humming along (ignoring some initial problems). The trouble is bureaucracy, lack of technical knowledge at the top, and the hazy difficulty of identifying what is needed is really difficult, and if you mess it up, you could ruin a billion dollar business to save a hundred million dollars in salaries.

That is the crux of it. You can't know who to cut, and even if you are really good at it, you will still create problems and create ill will. Elon was pretty successful, but it did have some momentary problems. If his negative cult of personality didn't get in the way, it would have been better off.

Re: Shopify is moving from React Native back to Swift and Kotlin

#954

Post by aprilthird2021 »

echoangle wrote: post #818
hackisterium wrote: post #812

Earlier quoted context omitted.

Combined Shopify sales are ~half of Amazon's but growing quicker. Shopify probably supports more sales per engineer than Amazon's retail stack team.

Amazon also has AWS as infra though, they only do retail as a side gig

They also have enormous fulfillment services. Shopify doesn't handle that part.

They also have video and music streaming. And Kindle Unlimited.

Re: Shopify is moving from React Native back to Swift and Kotlin

#955

Post by throwaway27448 »

user43928 wrote: post #739
cloudfudge wrote: post #717

Earlier quoted context omitted.

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 hi…

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…

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.

Re: Shopify is moving from React Native back to Swift and Kotlin

#956

Post by jkmcf »

vendiddy wrote: post #828
frabcus wrote: post #822

Hmmm, the article doesn't really say what is better about the Swift/Kotlin apps, compared to React Native. All we get is: "Native keeps us closer to platform capabilities and first-party tooling, with fewer framework and dependency layers between our code and the platform" What's the user benefit of that? It's not speed, they say "React Native apps can be fast. Ours are." I'd expect it to be considerably easier for a…

I agree with you. I don't think LLMs magically solve the problem that comes with writing twice. Even if they were to write for two platforms, they'd likely want to have a whole bunch of business & state management logic that would be shared between the two with the native part being a thin platform layer. It seems like a mostly shared codebase (reglardless of specific tech choice) would let them get precisely the end…

Besides API features, it won't require downloading 0.5 GB of web browser in order to run.

Sure, you can make it smaller, but how many companies actually do this?

Sure, you can make it faster, but how many companies actually do this? Accountants and product managers don't care about speed or size -- that's a user problem.

Judging by the app sizes I download (and try to avoid), few companies really care about the user experience as long as the basic feature is checked off.

I worked at a company that provided an unnecessary and heavy FE framework (original devs didn't know what they were doing and "just got it out there"). Most of the target audience used used older PCs, and thus slower and memory limited. Some pages required multiple GB of browser memory. We've had this problem for decades because devs usually have well spec'd computers.

Re: Shopify is moving from React Native back to Swift and Kotlin

#957

Post by abustamam »

austin-cheney wrote: post #933
abustamam wrote: post #904

Earlier quoted context omitted.

I dont see the correlation between company type (tech/software/X company) and sucking at your job though. Ive never worked for a, as you define it, "software" company because the software ive built has always been in service of selling other things, but people who sucked at their jobs got let go quickly. And there are absolutely software companies that hire sucky people. I don't know for certain if the people who wor…

> I dont see the correlation between company type (tech/software/X company) and sucking at your job though. The difference is in culture and expectations. People can suck when they are allowed or expected to suck. They can’t suck when the employer sets high expectations. If a company wants to ease hiring and employment flexibility they have to set the bar low to increase the prospective candidate pool. Otherwise they…

> People can suck when they are allowed or expected to suck.

This is not a unique concept to software or any company type though. You don't have to look far on the antiwork subreddit to find people who work in all types of different industries, technical and not, big and small, where some people just suck and everyone knows it and no one does anything about it.

Re: Shopify is moving from React Native back to Swift and Kotlin

#958

Post by gf000 »

Hendrikto wrote: post #753
T4iga wrote: post #736

Earlier quoted context omitted.

I am quite curious about what people hat so much about Spotify. I made some excursions the last few years to competitors like Tidal and Apple Music but I just found myself coming back because the Spotify mobile app experience (and desktop) was just plain better. I wonder what gripes people have.

The website, desktop app, and mobile apps all have different feature sets, for one. There are things that you can only do in one of them, but it is a different one of them for each thing. There is no one feature set. It feels so cobbled together, with each platform doing their own thing. Also, the website is slow and buggy, and the Electron “desktop” app is even worse. Both gobble up way too many resources and soft-c…

Also, probably due to some DRM bullshit, resuming a song from the middle doesn't work most of the time. I have to seek to the beginning for it to start playing.

Like that's literally the only thing it should be able to do 100%..

Re: Shopify is moving from React Native back to Swift and Kotlin

#960

Post by vmg12 »

muddi900 wrote: post #331
vmg12 wrote: post #312

Earlier quoted context omitted.

The problem isn't tokens but verification that the code works.

If you have enough of a budget, you can ask your agent to spawn two subagent to do independent audits of "your" work.

This just doesn't actually work in my experience.
Post reply on HN