Comment by paxys
1 day ago
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.
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.
9 replies →
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.
3 replies →
> 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.
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
1 reply →
Agree to a point, but human resource is literally the main cost in most businesses, so there's that
Conway's law also plays a big part here and it's kind of TBD to see if agentic development will minify or magnify its effects
Very true, especially when there are different turn around times and review policies for the various app stores, things can get out of sync quickly
Assuming they have a robust feature flag and experiment pipeline in place they are trying to solve a much more complicated version of this
> 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.
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.
2 replies →
Yeah, massive parts of our community and ecosystem miss that something can be right today, and wrong tomorrow, and having to change along with your users and needs is OK. You'll never be able to anticipate what the business needs in the future, so stop pretending your software design can be done once and then just coast on that, because that's typically not how a software project should be run long-term or even medium-term.
The problem with tomorrow is sunk costs. There are many places I wish we had made a difference decision in the past - but we need to balance that with cost to make changes when what we have works okay.
There's also a recency bias, where you ignore how valuable some decision was in the past and ignore the fact that you maybe wouldn't even get to the place you are if "you made a different decision in the past".
5 replies →
In my experience it comes from the business and people who think if we need to touch the same code twice in the same month it is somehow a moral failing of some kind.
Another factor is design.
A lot of companies go to React Native, etc, because they want one single non-native design on both platforms.
Which IMO can be a mistake most of the time, especially from the POV of a user.
most users can’t even use their phones properly
it is always the nerds (i’m a nerd, but also run a company and led teams before at a unicorn that IPOd) who obsess over things that normal people would probably not even come to given 100 years
case in point: even some of apples own apps don’t follow their design language.
also some of the most popular apps in the world like tiktok or x don’t use ios glass.
my bank app doesn’t use it and opts for a single theme across platforms.
and you know what? i don’t give a fuck. i just want my money transferred properly, my memes consumed on demand, and that’s about it.