Live data from Hacker News

Shopify is moving from React Native back to Swift and Kotlin

shopify.engineering

401–410 of 962 posts

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

#401

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…

> The main appeal of RN was being able to leverage your web devs for mobile dev.

There's nothing remarkable about the skill set of either party; the appeal here is re-use of code. how the labor markets itself is irrelevant

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

#402

Earlier quoted context omitted.

> they're basically going to be spending a ton more than they have to by switching back to multiple apps A ton more what? Money? AI costs are insignificant to a company like Spotify. Hell I've been using Astra fairly extensively at work and I've only racked up like $500 in the last month. Peanuts.

More code means more people. That's not peanuts

The whole point of this article is that it doesn't. Or at least for the same number of people you can now have way more code.

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

#403

Earlier quoted context omitted.

Much of Hacker News seems to be incapable of understanding the average user doesn't care about memory use at all, beyond a few extreme examples. You don't need to argue with me about it: I'm not the average user. But they really do not care at all in most cases.

> Much of Hacker News seems to be incapable of understanding the average user doesn't care about memory use at all, beyond a few extreme examples. They don't care, but they care about their computer being slow because of swapping. While they can't identify the cause and link it to the various Electron apps they're using (Teams, Slack,...) it's obvious for the tech-aware person they complain to.

That's true, but greater efficiency isn't going to sell more software if the users don't know they need it.

At some level in your management chain there's someone who cares about selling more software above all else, and it's your job to do what they want.

I don't like it either, but I've fought against it for too long to my own detriment. I think ICs have a responsibility to deliver quality software regardless of external pressures, but there's only so much you have time to do.

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

#404
post #269

Earlier quoted context omitted.

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.

This is a great point that I wish the Shopify article went into in more depth! Would love to hear if they considered this

I believe they have a more in-depth posting that talks about it

https://shopify.engineering/shop-app-migration

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

#405
post #269

Earlier quoted context omitted.

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

The capabilities of Android and iOS don't meaningfully differ for the purposes of Shopify; Shopify doesn't need LIDAR. Most large brands throw the UI design patterns of the platforms out the window in favor of their own UI guidelines.

Saying the web platform is not in sync with mobile is not a relevant metaphor to justify why Android and iOS should be considered separately.

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

#406
post #269
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.

But here's the thing, across operating systems the products should not be identical.

When you get to the point that your have a significant enough number of users across multiple platforms, generalizing everything into a shared UX doesn't make sense; giving those classes of users the best experience requires embracing their platform.

A simple example: Android has a system-wide convention for a `back` button. iOS has no such standard. Users on each platform have different expectations for how to navigate an app fundamentally, and holding tightly onto the concept of identical gives both camps a compromised experience.

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

#407
post #32

I believe this will be overall trend in industry. Dropping React Native and Flutter for native

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

How is SwiftUI dated? It uses a declarative model. I don’t see UI framework paradigms shifting that much.

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

#408

Earlier quoted context omitted.

None of this matters anymore. We have LLMs. It's easy to build native everything now without much resource expenditure. Android will be Kotlin. iOS will be Swift. Desktop and server will be Rust. Web will be TypeScript / React for now, but maybe one day WASM. LLMs are the target now.

Yet, neither ChatGPT desktop app nor Claude Code CLI is native. Mind you these are made by companies with practically infinite tokens.

These apps predated LLMs "getting good".

Both have an enormous number of paying customers and you don't just disrupt that for a language change.

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

#409

If you put every company that needs/has an app on a spectrum, there is a line somewhere that roughly divides them into two groups: where Electron/React Native/etc. makes sense or not. It's just a normal engineering decision: solving problems given limited resources. Companies have different problems and different resources. I think people in the tech community have probably also noticed that it's rather popular to ha…

[dead]

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

#410
post #406
post #269

Earlier quoted context omitted.

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.

But here's the thing, across operating systems the products should not be identical. When you get to the point that your have a significant enough number of users across multiple platforms, generalizing everything into a shared UX doesn't make sense; giving those classes of users the best experience requires embracing their platform. A simple example: Android has a system-wide convention for a `back` button. iOS has…

I took "identical" as in feature wise. The user should be able to accomplish the same things, no matter what platform they're using.

I do think that the way the features are implemented should be platform dependent, i.e. use common UX pattern on each platform, fit in with the UI, and be good platform citizens.

Post reply on HN