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.

▲

tcdent 2 hours ago | parent | next [-]

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.

▲

thm76 2 hours ago | parent | next [-]

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.

	▲	ethin an hour ago \| parent \| next [-]
		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.
	▲	nfw2 an hour ago \| parent \| prev [-]
		Why does Shopify need to use Apple's or Google's branded design language in their app?

▲

nfw2 an hour ago | parent | prev [-]

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.

▲

pmontra an hour ago | parent [-]

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.

	▲	nfw2 an hour ago \| parent [-]
		I agree. Design as if it doesn't exist incidentally is also how they design for iOS where it doesn't exist.

▲

serial_dev an hour ago | parent | prev | next [-]

> keeping those two products that need to be identical in sync

I agree that most companies do that, but in my opinion that's not really all that important. Some drift between the iOS and Android apps should be expected and accepted.

▲

nightpool 4 hours ago | parent | prev | next [-]

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

	▲	ninju 2 hours ago \| parent [-]
		I believe they have a more in-depth posting that talks about it https://shopify.engineering/shop-app-migration

▲

sarky-litso 3 hours ago | parent | prev | next [-]

Assuming they have a robust feature flag and experiment pipeline in place they are trying to solve a much more complicated version of this

▲

skydhash 3 hours ago | parent | prev [-]

> 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 library semantics.

	▲	nfw2 2 hours ago \| parent [-]
		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.