5 ms·

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 organizationa

by nfw2 23d ago

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.

nightpool 23d ago
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 23d ago
  I believe they have a more in-depth posting that talks about it https://shopify.engineering/shop-app-migration https://shopify.engineering/shop-app-migration
  - canucker2016 23d ago
    The blog post doesn't mention the personnel-related challenges with having two native platform teams working on the app. The post DOES give more information as to why they looked at switching from React Native to native Platform APIs. React Native is forcing a major refactor of React Native apps in switching to the React Native "New Architecture" (see https://reactnative.dev/architecture/landing-page https://reactnative.dev/architecture/landing-page). So if Shopify had to do major refactors of all their React Native apps, maybe they could look at what it would take to go back to native Platform APIs. from https://shopify.engineering/shop-app-migration https://shopify.engineering/shop-app-migration For the Shop App, this coincided with our next major React Native investment: adopting the New Architecture. That work would have required us to revisit native module integrations, rendering, and the boundaries between shared and platform-specific code. Before committing to this investment, we tested whether coding agents could help us build directly in SwiftUI and Jetpack Compose while keeping product behavior aligned across platforms. The result of that native platform APIs side project involving six devs converting the app's major user workflows? - startup time reduced: iOS by 23%, Android by 50% - crashes - 10x reduction - app size - iOS increased by 1MB (67MB -> 68MB), Android reduced by 109MB (37.2%) - build time - Android release build time fell ~75%. - runtime perf - Android builds could draw at 120fps while scrolling feed and switching screens
sarky-litso 23d ago
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 23d ago
> 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 23d ago
  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.
  - skydhash 23d ago
    They vary in terms of architectural patterns and ui widgets. RN tries to prevent a single interface, but you quickly reach the point where it becomes a pain. You can use Expo to help, but their libraries are unstable.
  - unqueued 23d ago
    > Most large brands throw the UI design patterns of the platforms out the window in favor of their own UI guidelines. I really wish they would not do that. The best thing you can do to make your app trustworthy and friendly is to adhere to the host operating system UI guidelines and expectations. Nobody wants your unique take on the checkbox or textarea please.
tcdent 23d ago
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 23d ago
  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 23d ago
    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 23d ago
    Why does Shopify need to use Apple's or Google's branded design language in their app?
    - sokoloff 23d ago
      Because if I’m an iOS user and used to that and you give me a conventional Android app UX, I’m going to feel that as jank. Same as if I’m an Android user and you give me the conventional iOS experience. It’s like if I gave a swing or Gtk+ or Xwindows app experience on Windows 11 or MacOS. It would be usable, but feel conspicuously sub-standard.
serial_dev 23d ago
> 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.
elpakal 23d ago
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
simonhamp 23d ago
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

by nfw2 23d ago

nightpool 23d ago

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 23d ago
I believe they have a more in-depth posting that talks about it https://shopify.engineering/shop-app-migration https://shopify.engineering/shop-app-migration
- canucker2016 23d ago
  The blog post doesn't mention the personnel-related challenges with having two native platform teams working on the app. The post DOES give more information as to why they looked at switching from React Native to native Platform APIs. React Native is forcing a major refactor of React Native apps in switching to the React Native "New Architecture" (see https://reactnative.dev/architecture/landing-page https://reactnative.dev/architecture/landing-page). So if Shopify had to do major refactors of all their React Native apps, maybe they could look at what it would take to go back to native Platform APIs. from https://shopify.engineering/shop-app-migration https://shopify.engineering/shop-app-migration For the Shop App, this coincided with our next major React Native investment: adopting the New Architecture. That work would have required us to revisit native module integrations, rendering, and the boundaries between shared and platform-specific code. Before committing to this investment, we tested whether coding agents could help us build directly in SwiftUI and Jetpack Compose while keeping product behavior aligned across platforms. The result of that native platform APIs side project involving six devs converting the app's major user workflows? - startup time reduced: iOS by 23%, Android by 50% - crashes - 10x reduction - app size - iOS increased by 1MB (67MB -> 68MB), Android reduced by 109MB (37.2%) - build time - Android release build time fell ~75%. - runtime perf - Android builds could draw at 120fps while scrolling feed and switching screens

sarky-litso 23d ago

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 23d ago

> 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 23d ago
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.
- skydhash 23d ago
  They vary in terms of architectural patterns and ui widgets. RN tries to prevent a single interface, but you quickly reach the point where it becomes a pain. You can use Expo to help, but their libraries are unstable.
- unqueued 23d ago
  > Most large brands throw the UI design patterns of the platforms out the window in favor of their own UI guidelines. I really wish they would not do that. The best thing you can do to make your app trustworthy and friendly is to adhere to the host operating system UI guidelines and expectations. Nobody wants your unique take on the checkbox or textarea please.

tcdent 23d ago

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 23d ago
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 23d ago
  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 23d ago
  Why does Shopify need to use Apple's or Google's branded design language in their app?
  - sokoloff 23d ago
    Because if I’m an iOS user and used to that and you give me a conventional Android app UX, I’m going to feel that as jank. Same as if I’m an Android user and you give me the conventional iOS experience. It’s like if I gave a swing or Gtk+ or Xwindows app experience on Windows 11 or MacOS. It would be usable, but feel conspicuously sub-standard.

serial_dev 23d ago

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

elpakal 23d ago

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

simonhamp 23d ago

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