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

381–390 of 962 posts

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

#381

Post by sarky-litso »

nfw2 wrote: post #269
paxys wrote: post #41

Earlier quoted context omitted.

And the “makes sense or not” part can change based on a bunch of factors. 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).

The main cost of two engineering teams shipping identical products in my opinion isn't the cost of those extra engineers, it is in the product and organizational challenges of keeping those two products that need to be identical in sync. I am very bullish on coding agents but would be wary of this turning into a mess.

Assuming they have a robust feature flag and experiment pipeline in place they are trying to solve a much more complicated version of this

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

#382

Post by AtNightWeCode »

CodingJeebus wrote: post #329
AtNightWeCode wrote: post #321

Why on earth is Shopify not just a web wrapped in an app like most apps? I mean, they implement most of that stuff for the desktop anyway.

There's quite a bit of research out there showing that application performance has a material impact on checkout conversion rate, so a single platform optimization potentially improves checkout for millions(?) of storefronts.

Google research from a decade ago that might as well been that their bot did not want to wait for pages to load. The performance difference between React native and a web wrapped in an app is pretty much zero today.

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

#383

Post by azuanrb »

spiderice wrote: post #327
tonic_note wrote: post #243

Models have gotten a lot better at generating native iOS apps. The main appeal of RN was being able to leverage your web devs for mobile dev. that's what I did at my last company. And it's fine for a startup, but eventually you want dedicated native engineers bc each platform really deserves its own technical masters who can optimize for it. But now that all code is generated, there's little upside to having an RN ap…

Nobody is talking about the real advantage of RN: Being able to release to the App Store without having to go through a review. That's so massive. Getting a bug fix out to users instantly, sneaking in optimizations, etc.. 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 o…

I’ve worked with both native and cross-platform. I think the mentality of being able to make changes quickly without much review often comes from cross-platform, especially when the developers come from a web background.

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.

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

#384

Post by shawabawa3 »

canto wrote: post #351

So, instead of paying humans twice for the same thing, Shopify will pay corporations to burn the planet a little bit more, waste water and energy - to build the same thing twice. Just because. There's no tech reason to do it. "LLMS are better now". There's no low level optimisations, no blockers, no app shortcomings, it's a shopping app for Christ sake. Instead of optimising, creating more with less, they will create…

> Just because. There's no tech reason to do it.

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

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

#385

Post by eleventen »

spiderice wrote: post #330
eleventen wrote: post #106

Earlier quoted context omitted.

Of course it would. Supply and demand. Some companies would decide not to bother. Others would decide it was worthwhile. The limited pool of supply (app developers) would be distributed across demand.

> Some companies would decide not to bother Sounds like you agree

I agree that AI is suppressing developer wage growth and taking real jobs. The opposite argument is being made elsewhere in the thread, and I think that argument is wrong.

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

#386

Post by gvv »

canto wrote: post #351

So, instead of paying humans twice for the same thing, Shopify will pay corporations to burn the planet a little bit more, waste water and energy - to build the same thing twice. Just because. There's no tech reason to do it. "LLMS are better now". There's no low level optimisations, no blockers, no app shortcomings, it's a shopping app for Christ sake. Instead of optimising, creating more with less, they will create…

quality ragebait

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

#387

Post by azuanrb »

jrochkind1 wrote: post #268

I'm not totally following the part about the simulator(s), probably because I haven't actually done mobile development before. > 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…

It’s a reasonable tradeoff. Shopify uses Rails, and there’s been a long history of discussion around E2E testing in the Rails community.

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

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

#388

Post by tisdadd »

bluGill wrote: post #373
edoceo wrote: post #292

Earlier quoted context omitted.

Those are the comments that should persist in the code. I hate when the AI edits and removes my "why" comments. I want the refactor to make it less messy but keep why it's that kind of mess.

Too Soon often we thought those were obvious and didn't comment. Meanwhile there are detailed comments about things nobody cares about.

I just put a comment in yesterday for this very reason - there was a flag I had set to false, and then looking at the library docs for something else thought maybe it should be true but that doesn't work how I would have implemented it if I had created the library and written the docs how I 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.

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

#389

Post by skydhash »

nfw2 wrote: post #269
paxys wrote: post #41

Earlier quoted context omitted.

And the “makes sense or not” part can change based on a bunch of factors. 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).

The main cost of two engineering teams shipping identical products in my opinion isn't the cost of those extra engineers, it is in the product and organizational challenges of keeping those two products that need to be identical in sync. I am very bullish on coding agents but would be wary of this turning into a mess.

> it is in the product and organizational challenges of keeping those two products that need to be identical in sync.

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.

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

#390

Post by sfn42 »

kentm wrote: post #344
sfn42 wrote: post #142

Earlier quoted context omitted.

I don't have any actual experience with React Native and Electron, but with that caveat out of the way I personally think tools get far too much blame that should be on developers. 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 neces…

> React can render at more than 60fps if necessary, and if the code isn't shit. 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.

Yeah, obviously your average React app has no need to render anywhere near that frequently. The ones I've worked on will generally only render as a response to user action, server event or polling.

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.

Post reply on HN