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)

1208 points | 900 commentspage 16

gazarsgo 1 day ago|

Cool story but what's the token spend?

AtNightWeCode 1 day ago||

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.

simonhamp 15 hours ago||

Seems like you've never had to worry about accessibility in hybrid apps...

AtNightWeCode 9 hours ago||

We booted react native like 10 years ago and there is not much a web does not solve. We even did solve it for the desktop users anyway even before. A simple app as Shopify with mostly static content should not be any problem to build as a web.

CodingJeebus 1 day ago||

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.

AtNightWeCode 1 day ago||

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.

philipwhiuk 1 day ago||

> It doesn't expect the first output to be correct, and builds a loop where an imperfect attempt simply cannot move forward until it becomes a good result.

So... local maxima?

yieldcrv 1 day ago||

Perfect, yeah the obvious answer and comment is in the subtitle right at the top. Good way to write an article

> Coding agents changed what it costs to build mobile apps twice. Here’s why Shopify is moving from React Native back to Swift and Kotlin.

sergiotapia 1 day ago||

Major loss for react native community at large with Skia and Flashlist dying. :(

gagabity 1 day ago|

Legend List is the new hotness in RN.

rvz 1 day ago||

Agreed, the whole of the Javascript / TypeScript ecosystem has caused a slop hellscape of workarounds, half-backed fixes and have exposed short-comings in the ecosystem.

Perhaps these languages do not work well as they are not designed to run efficiently on mobile devices. Now that we have libraries such as SwiftUI and Jetpack Compose, React Native no longer makes sense to use.

Now we should also move away from Electron to better alternatives such as Kotlin Multi-Platform or fully native libraries on each platform; because of LLMs.

hermitwriter 1 day ago|

So disagree. The benefits you get from leveraging a framework as as important today as they have ever been -- strong frameworks, fewer tokens, faster progress.

simonhamp 15 hours ago||

Hallelujah!

One other person in this place gets it: "fewer tokens, faster progress"

Electron, Tauri, React Native/Expo, Flutter (and countless others) are the wrong kind of abstractions, built for a time pre-AI, solving pre-AI problems

We need a new post-AI abstraction that embraces this opportunity!

That's why we're building SuperNative

railka 1 day ago||

IMHO, now is a great time to use native Swift/Kotlin code alongside shared Rust code via UniFFI

massel 1 day ago||

We've been doing this for a while and it works great. Logic and network stuff goes in Rust, UI goes in Swift/Kotlin.

rvz 1 day ago||

So you want to review and maintain code in 3 separate languages?

Sounds like a complete waste of tokens with the worst case of just quickly building more technical debt, three times.

massel 1 day ago||

It's a lot nicer than having the same logic in 2 languages and trying to keep them in sync – whether doing it by hand or with an LLM.

One of the big rules is don't repeat yourself – much of the logic only needs to be written once (except UI)

doc_ick 1 day ago|||

Well you don’t repeat yourself if the llm repeats it for you at the cost of millions of tokens.

mike_hearn 1 day ago||||

Rust is uncompetitive for the use case of sharing logic between mobile apps. Kotlin has Swift interop and KMP is a mature tech by this point.

mwcampbell 22 hours ago|||

This is probably biased by the specific multi-platform apps I've worked on, but my default assumption is that sooner or later, any non-trivial multi-platform app will need to reach for something that doesn't already have a KMP library and that, on Android, might require compiling native code via the NDK. Rust has a way bigger library ecosystem than KMP. So I figure one might as well do the cross-platform core in Rust and add that FFI boundary early, but managed by something like uniffi-rs. And, I've seen it work in a few real projects now, with just a little build system friction up front. So in what sense is Rust uncompetitive for this use case?

mike_hearn 20 hours ago||

KMP can call into native libraries easily. C FFI is not a competitive advantage.

Rust has a smaller library ecosystem, I'd say. Kotlin can use Java libraries on the server side, and on the client side on Android, and the ones needed on iOS are easy to convert to KMP - IntelliJ can do it semi-automatically. And KMP has the libraries that matter on mobile, for hardware access, animations and so on.

hn-acct 6 hours ago|||

> mature. Sure if you want to write old Swift.

rvz 1 day ago|||

In that case, Kotlin makes even more sense especially with Kotlin Native, and Rust is unnecessary.

Kotlin is already multi-platform and can be re-used as the business logic in iOS apps with Swift as the UI and the Android app with a Kotlin UI (Jetpack Compose) or both iOS and Android apps can be written entirely in Kotlin.

That vastly reduces the maintenance and Kotlin is reused across all apps and keeps it at 2 languages at most.

No need to introduce Rust to achieve the same goal.

More comments...