Shopify is moving from React Native back to Swift and Kotlin

Posted by fnthawar2 1 day ago

Shopify is moving from React Native back to Swift and Kotlin(shopify.engineering)

1168 points | 853 commentspage 9

vladkens 17 hours ago|

Lol, they bought Tailwind CSS, freaked out, and decided not to touch it at all.

parentheses 22 hours ago||

The underlying problem is that it's difficult to make a principled decision. So, it's ripe for SEO mining and such fuzzy takes happen.

The meta point of the article, I agree with though. The line is moving and AI makes having multiple platforms with code specific to them faster. Getting them right is still difficult.

ergocoder 22 hours ago||

A companies with thousands of engineers should simply go native.

Write once, deploy everywhere like React Native mainly benefits small teams and startups who are okay with building 90/10 solutions.

At the shopify's scale, they would want to go advance for every corner of the apps and use cases, and only native allows that.

SwellJoe 22 hours ago|

Even a single person can now build/maintain native apps. It's literally a day of effort for an experienced dev working with the best current models to port an app to a new native platform. Maybe another day or two to walk through wiring up all the test harnesses needed to prove the app is working well without a human having to click everything. Until recently you'd still have to spend a bunch of time on making sure the UI looked and felt right, but models now have good enough vision capabilities to where even that can mostly be automated.

And, honestly, the cost of tracking React over time has always been higher than the cost of tracking native deployment options, which move more slowly and usually with more care than React, where breaking backward compatibility is just another Tuesday. I don't think the promise of React Native being an almost-free "native" app actually pans out in reality. I've never maintained a large React Native app, but from following some apps that are, it seems like it introduces a sizable amount of technical debt that you pay over time. So, in exchange for worse software you also get worse maintenance costs.

trynotsober 21 hours ago||

The shared specs and tests seem like a big part of making this work. I'd be interested in a follow-up after a few months of shipping new features on both platforms. Does keeping behaviour consistent still take much coordination, or have the agents reduced that work too?

polloRebozado 23 hours ago||

I have not coded any mobile apps, I understand the downsides of using react native/electron due to them being web apps but what about things like Kotlin multi platform or flutter? Aren't this frameworks supposed to allow your to have 1 codebase and the apps be truly native instead of web apps?

zelphirkalt 21 hours ago||

I think any framework that aims to support desktop and mobile frome the same code per view/screen is doomed to either make one of those two awkward to use, or alternatively become itself very complex to use.

The most advanced in this area may well be websites and into those decades of work of thousands of engineers went (HTML, CSS and JS standards).

wilsonnb3 22 hours ago||

React Native apps are not webview based like Electron, they use native components. Arguably it is more native than flutter, which uses its own components designed to mirror native ones on Android and iOS.

aurareturn 1 day ago||

How long until LLMs just write machine code?

desterothx 3 hours ago||

IMO it doesn't make sense for LLMs to write machine code, because abstraction allows them to have more information density. As context size is a big limitation right now, cluttering it with less dense information seems like a bad idea.

_flux 1 hour ago||

What actually might could make sense in the future would be super-dense but abstraction-able programming language made for models. Then you'd train the model to work with it and you could have a way to render a human-readable version of the program for introspection.

It preferably come with superior guard rails, so strict static typing, borrow checker if not gc, perhaps ability to state proofs, etc.

_flux 6 hours ago|||

Probably a long time, as machine code is verbose and thus destroys the context both when reading and writing, as well as making it more expensive.

MattDamonSpace 23 hours ago||

Direct 1s and 0s

synergy20 22 hours ago||

wow, what about electron.js the bloated cross-desktop GUI, can LLM either totally modernize wxWidgets(to avoid Qt's license mess), or create some light-weight cross platform GUI widgets to make GUI easy on windows/macos/linux that is not resource heavy?

simonhamp 11 hours ago||

Working on this problem for the next version of NativePHP Desktop. Have dropped Electron entirely

mike_ivanov 21 hours ago|||

wxWidgets carries too much legacy. A GTK3 fork maybe? Or a functional clone of QML with some improvements.

synergy20 20 hours ago||

maybe gtk4 gui first then ask llm to recreate them natively on windows and macos

mike_ivanov 17 hours ago||

no, not gtk4 - they lost their way after v3

amedvednikov 10 hours ago||

https://github.com/vlang/ui2 does just that

bilater 22 hours ago||

This is obvious in hindsight. I expect most companies that move fast and care about performance to abandon React Native. Code is cheap now, and the tradeoff of having a single codebase and only hiring React devs basically isn't there anymore.

fhub 15 hours ago|

I had one feature in RN and the rest properly native. The day I realized agents were good, I ported that RN to native. Monkey-off-back moment.

More comments...