Top
Best
New

Posted by fnthawar2 21 hours ago

Shopify is moving from React Native back to Swift and Kotlin(shopify.engineering)
1090 points | 786 commentspage 4
eviks 8 hours ago|
Vibe-based architectural changes undoubtedly destined for "extreme" success until the next turn of the churn
lackoftactics 21 hours ago||
I believe this will be overall trend in industry. Dropping React Native and Flutter for native
aatd86 21 hours ago||
That would be a huge mistake if we expect many more hardware and OS running them efficiently than just iOS and Android. Best is to have an IR. Now maybe that IR can be turnt into native code. But we shouldn't be constrained. As an incoming framework author, SwiftUI is problematic for instance because it has a programming model which is dated. And I don't particularly enjoy the language either. Looked fine at first and then got more complex than I feel is needed.

oh yeah, disclaimer: I write UI frameworks and dabble in PLs.

organsnyder 21 hours ago|||
> That would be a huge mistake if we expect many more hardware and OS running them efficiently than just iOS and Android.

Is that something we should be engineering for right now?

aatd86 20 hours ago||
Just like any engineering and business decision, this is a tradeoff. I probably don't see things from the same vantage point. Can't help but notice a trend however. What if this accelerates, especially with AI being an enabler?
uncomputation 16 hours ago|||
How is SwiftUI dated? It uses a declarative model. I don’t see UI framework paradigms shifting that much.
aatd86 15 hours ago||
It is virtual dom like. We don't have access to a stable underlying element like we would with plain UIKit. You can build declarative models without this virtualdomness. But SwiftUI was created during the react boom so they went with the Zeitgeist, understandably.

Now this is somewhat problematic if someone wants to implement better fine grained reactive systems. And I posit that the next paradigm is going to be in that direction given what I've been working on (furthering current reactive systems which only go halfway).

sgt 5 hours ago||
This is such a clueless take, and I see it surprisingly often. Declarative UI does not inherently mean virtual DOM nor does it "automatically" mean slower than UIKit.

The abstraction is huge advantage, especially when targeting different devices and screen sizes. We (and that includes Apple) have been learning the value of those kinds of abstraction boundaries for years, well before React.

It's also important to note that SwiftUI and UIKit are composable, so if some small part of your app needs low-level, finer grained control, then go ahead and use UIKit/Core Animation/Metal and SwiftUI for the rest.

aatd86 4 hours ago|||
Yes, declarative UI is just an abstraction of imperative code. :) The rest is properties of the internal implementation. The VDOM way obfuscates the internals more. Doesn't let you control rendering appropriately. It is so because the diffing and reconciliation algorithm have to be able to remove any subtree of views/nodes from the UI tree.

Then you can only have islands of either paradigm within each other. UIKit and SwiftUI do indeed compose, albeit coarsely.

I can't blame them, they got influenced by react. Don't even blame react, it was a good attempt. Basically trying to build a UI from a snapshot of a tree. Except this is too simplistic a model. They designed it as if you could equate the number of games and the number of positions in chess. Like a markov chain. Except playing chess has side effects. A mere snapshot does not encode those.

I understand the mistake.

accumulator 20 hours ago|||
I think it'll become a trend at larger, well-capitalized companies and startups, but not universally. The article mentions hundreds of engineers have worked on Shopify's RN apps, so they're well positioned to maintain two native codebases with agents and practically infinite token spend. Migration will be a harder sell for resource-constrained businesses.

It also depends on features. Many apps don't rely on platform features (widgets, watch apps) and are essentially webviews, and those will continue to do just fine on RN.

conmod278 20 hours ago|||
Can React Native become a sort of Compiler which compiles to natives (Android/Apple) now that AI can help in that direction as well? I don't know much about mobile ecosystem though.
lackoftactics 45 minutes ago||
the tricky part about React Native is that you almost always need to use it with expo.

I developed React native app for ios as side project and took breaks often and came back to have to do big updates with expo to make it work again. Maybe there is smoother process, but this was annoying

RetpolineDrama 20 hours ago||
Yep. Flutter has been dead-end for a while. RN won't last through 2027.
SV_BubbleTime 18 hours ago||
LOL, flutter/dart are pretty awesome and we have yet to encounter something that needed improvement.

We have small shims for IOS or Android BLE. But otherwise the discussion of should you go native is really a discussion of how many employees do you have to throw with this?

iBelieve 19 hours ago||
It's interesting that they don't mention Kotlin Multiplatform or any sort of shared core logic between their iOS and Android apps. Seems like maybe the apps are fully independent codebases but with shared specifications and tests? They say that agents:

> Dramatically reduced the cost of maintaining parity between platforms through shared specifications, tests, and review checkpoints

I've used Kotlin Multiplatform on a mobile project built back before AI coding took off, and it was super nice to have shared core logic between the apps and there weren't really any downsides on the Android side, but on the iOS side it was definitely an extra layer that didn't feel fully native.

cosmic_cheese 19 hours ago|
Speaking personally, JVM toolchain bits like Gradle being involved is a turnoff and has kept me away from KMP. Last I checked support wasn't really there yet, but I'd much rather go the other direction and use Swift Package Manager and the associated toolchain on Android.
tcoff91 18 hours ago||
I work on an open source app that uses a shared swift core for the iOS and android apps and I think it's awesome. I think having all your business logic in swift is great.

At work, we use react native, and although the upgrades and stuff are painful, I'd never give up the ability to ship over the air updates.

pzo 21 hours ago||
Wish they explained more. Even though I'm mostly native iOS its seems react native is better stack for AI and iteration (hot refresh etc) - the main reason pretty much all AI vibecoding app were implemented via expo/react native.

I also believed that finally this year react native got mature enough with improved tooling and performance to the point that it started to being 'boring' technology.

PKop 12 hours ago|
There's a section linking to a more in depth article:

"The Shop app, which is regularly at the top of the list in the shopping category in the app stores, is the first to be migrated. Assisted by AI, the team was able to go from a proof of concept to a fully rebuilt native app published in the app stores in just 12 weeks. We’ve written about this migration in depth here [0].

The migration of the Shopify app (our biggest with 300+ screens, home & lockscreen widgets, Apple Watch app, complications, Siri Shortcuts, etc.), is also underway and will ship later this year. The rest of our apps will be migrated soon."

[0] Migrating Shop app from React Native to native https://shopify.engineering/shop-app-migration

xcc3641 11 hours ago||
Debugging crashes across JS, C++, and native threads costs more than maintaining two codebases.
akmarinov 6 hours ago||
Not mentioned but this also gets them away from what now seems monthly npm supply chain attacks.

Big win for security

simonhamp 6 hours ago|
You don't have to ditch cross-platform building entirely just to escape dependency hell
akmarinov 5 hours ago|||
No, but it’s a nice bonus
hn993302 5 hours ago|||
Do you even escape dependency hell this way?
msephton 5 hours ago|||
It's a developer decision. But I'd say it's easier to not use dependencies on native because there are more capable system API. I don't use any in my iOS apps, and only one dependency in 20 macOS apps.
akmarinov 5 hours ago|||
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 are safe on the other one.

larodi 20 hours ago||
Truth is the Shopify app is simple enough to get right by a model. Lots of things hare simpler to get right in native code, so it is to be reiterated - a lot of interpreter code/libs is going down the drain, along with the devs that write it. These are not needed anymore.

And, in all honesty, the difficult part with many projects is the bootstrap, the scaffolding, not the continuous dev. Agentic dev. made this a piece of cake.

aprilthird2021 4 hours ago|
This article is about the Shop app (which is a consumer shopping app, kinda like Etsy or Amazon). The Shopify app is a lot more complex actually
w10-1 19 hours ago||
Most of the costs of switching have yet to be borne: user issues with untested code, maintenance issues with code few understand, and the strategic dependency on coding LLM's, which will change in character after providers go public and need revenue to fit reasonable stock multiples. All only get worse with time unless they're addressed proactively.
aecorredor 20 hours ago|
The most interesting part to me here was the whole helix thing + how they split business logic and UI just so AI agents could drive/test state via a CLI. I hope they do a deeper blog post on just that. I’m surprised they are making “decouple state from UI” sound like something groundbreaking when that’s kind of been the foundation for any sane/testable app for a LONG time.
More comments...