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

411–420 of 962 posts

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

#411

Post by TheRealPomax »

Shorel wrote: post #211
TheRealPomax wrote: post #112

Earlier quoted context omitted.

It's funny how folks can't even get that number right. Depending on how much you care to optimize, Electron adds 50 to 80 MB to your application. Those multi hundreds of megabyte apps? Yeah that's not because of electron, that's things like "we couldn't be bothered to actually think about the assets we bundled in". 100 uncompressed 16 bit PNG? Sure why not. 20MB worth of fonts because we don't like the built in ones…

Are you defending Electron apps? The audacity :) Bruno consumes 300MB in RAM. The alternative I am using consumes 25 MB and it is much faster. The difference is not because some uncompressed PNG or some fonts, it's the Electron architecture that is wasteful, by design.

First off, RAM is not app size, and second, the point of having RAM is literally so it's there to be used. Sure, Chrome is absolute nonsense, but Electron is not Chrome, and an Electron app using 300 MB in memory where data needs to be uncompressed and directly accessible when your computer (including your phone) has gigabytes of the stuff to work with is just... irrelevant? That's pretty much pretending there's a problem for the sake of wanting a problem.

And yes, not using electron will use less memory, which is an excellent reason to go "we're not using Electron". But there's a difference between "We want to use as little memory as possible" and "300MB of RAM on a system with 8 gigabytes of the stuff is a problem". The first is an excellent call. The second is nonsense =)

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

#412

Post by nevertoolate »

atonse wrote: post #31

We did the same thing - had 90% of it overnight. Then spent a few days in the background tweaking for polish. Our app is smaller, and has about 15-20 screens. I started at about 12:30am by giving codex a goal and it inventoried every screen based on the react native code, then created android and iOS directories, used maestro (I had already set up this tooling for a previous personal app build a few weeks prior), and…

So now you have two vibe coded applications you don’t understand. I’m not an advocate of making “job security” decisions but this definitely goes to red flag territory. Was it your job to maintain the RN codebase or do you have other functions there as well? I’m not sure I would keep a native noob on a vibed native codebase. What is your take?

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

#413

Post by ethin »

thm76 wrote: post #410
tcdent wrote: post #406

Earlier quoted context omitted.

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.

The solution is to make the common features a part of a statically-linked library that you can pull into your apps. A web app is, IMO, never the answer when you want to address multiple audiences. It is bad for accessibility (because 99.999 percent of web app developers never consider accessibility) and it doesn't solve the problem that web apps are trying to solve (having 8 code bases all that have to remain in sync) because you will inevitably need your code to handle platform-specific differences, standards/conventions and whatnot.

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

#414

Post by greenowl »

kccqzy wrote: post #302
greenowl wrote: post #179

Earlier quoted context omitted.

Isn't ZDR only the case if you "opt out" through a setting? Lots of opportunities to make a mistake here, or for the LLM provider to play games. You could be unaware of the setting. The provider could reset the setting upon subscription lapse/renewal, application update, model release, etc. A developer could accidentally use their personal subscription (w/ setting on) on a work codebase. Also what's the timing on thi…

The mistakes you describe are only possible if the company doesn’t really think there’s proprietary IP in the codebase. If a company really believed there’s valuable IP in code, there would at a minimum, ban laptops or ban code on laptops[0], provide and maintain a centrally managed LLM gateway[1] that handles authentication, billing and model choice, have MDM to prevent you from using your own Claude login, etc. [0]…

I'd wager many software startups out there would consider their code valuable IP (even if in the AI era it's not), and don't have these types of IT controls in place. Startups I worked at gave you an email account, github access to their private repos, and that was that.

Heck, you don't even need to mix up a personal and business AI subscription. For the vast majority of folks one day their IDE "updated" and a bunch of AI features suddenly became available. Free, no sub needed. A dev starts using them (because, why not?) and lo and behold the company's code got shipped out in an inference call and is now scheduled to be in the next training run. Oops.

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

#415

Post by prisonguard »

Waterluvian wrote: post #28

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…

its sad that the only reason warranting this switch is AI.

I would have loved to see some performance benchmarks on some critical app flow.

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

#416

Post by nfw2 »

tcdent wrote: post #406
nfw2 wrote: 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…

There is an implication here that the back button is a microcosm that represents the differences holistically but it's not. It's a small one-off exception that doesn't even affect the design choices made for the various apps. As I open up app over app on my Android (Audible, Spotify, ChatGPT, etc.), they all have clear in-app "back" functionality where needed. No apps I have installed rely on the Android back button exclusively. Also, none of these apps have any design elements that follow Android's design language.

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

#417

Post by nfw2 »

thm76 wrote: post #410
tcdent wrote: post #406

Earlier quoted context omitted.

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.

Why does Shopify need to use Apple's or Google's branded design language in their app?

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

#418

Post by mwcampbell »

mike_hearn wrote: post #166
massel wrote: post #90

Earlier quoted context omitted.

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)

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.

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?

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

#419

Post by nodamage »

_fzslm wrote: post #274
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…

This is true in a very real sense – models can help you build native apps very quickly, no question. But how do you keep them from drifting apart from one another as you add/change features or design? Right now, there isn't much tooling for this. React Native's advantage of having a single source of truth for code hasn't quite gone away yet, imo.

I don't understand the question. If the model built both apps why wouldn't it also be building the new features on both platforms at the same time?

Alternatively, point the model at your git repo for platform A, read the diffs since release X and implement the same changes on platform B?

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

#420

Post by pmontra »

nfw2 wrote: post #416
tcdent wrote: post #406

Earlier quoted context omitted.

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…

There is an implication here that the back button is a microcosm that represents the differences holistically but it's not. It's a small one-off exception that doesn't even affect the design choices made for the various apps. As I open up app over app on my Android (Audible, Spotify, ChatGPT, etc.), they all have clear in-app "back" functionality where needed. No apps I have installed rely on the Android back button…

The back button works at its best when it closes an app and it restores the one that opened the previous one. There could be no in app back button to do that. However the back button used to be an always available hardware button or a touch one on the bottom bezel. It's optionally visible now (I'm on an old Android phone so I'm not up to date with the latest OS) or a gesture, right? So app designers must design as if it does not exist.
Post reply on HN