7 ms·

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 fe

by paxys 6d 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).

embedding-shape 6d ago
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.
- collabs 6d ago
  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.
- bluGill 6d ago
  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.
  - rafaelmn 6d ago
    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".
    - bluGill 6d ago
      I can't count how many times I've said "this is really bad, I it is worth rewriting to fix all the issues", only to discover that there were good reasons for all the past decisions and so we end up with the same mess as before - except that now I know what it must be that way. Not always, but very often people in the past had good reason for what they did.
      - edoceo 6d ago
        Those are the comments that should persist in the code. I hate when the AI edits and removes my "why" comments. I want the refactor to make it less messy but keep why it's that kind of mess.
        bluGill 6d ago
        Too Soon often we thought those were obvious and didn't comment. Meanwhile there are detailed comments about things nobody cares about.
        tisdadd 6d ago
        I just put a comment in yesterday for this very reason - there was a flag I had set to false, and then looking at the library docs for something else thought maybe it should be true but that doesn't work how I would have implemented it if I had created the library and written the docs how I did. It is a very capable library, and when I first started using it the docs were more Oracle docs looking - but I could find what I wanted easily. Now, it is much more annoying to delve through but looks more modern.
      - xp84 6d ago
        As relevant today as it was 26 years ago: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... See also: Chesterton's Fence
nfw2 6d 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 6d 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 6d 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 6d 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
whstl 6d ago
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.
- moomoo11 5d ago
  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.

by paxys 6d ago

embedding-shape 6d ago

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.

collabs 6d ago
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.
bluGill 6d ago
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.
- rafaelmn 6d ago
  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".
  - bluGill 6d ago
    I can't count how many times I've said "this is really bad, I it is worth rewriting to fix all the issues", only to discover that there were good reasons for all the past decisions and so we end up with the same mess as before - except that now I know what it must be that way. Not always, but very often people in the past had good reason for what they did.
    - edoceo 6d ago
      Those are the comments that should persist in the code. I hate when the AI edits and removes my "why" comments. I want the refactor to make it less messy but keep why it's that kind of mess.
      - bluGill 6d ago
        Too Soon often we thought those were obvious and didn't comment. Meanwhile there are detailed comments about things nobody cares about.
        tisdadd 6d ago
        I just put a comment in yesterday for this very reason - there was a flag I had set to false, and then looking at the library docs for something else thought maybe it should be true but that doesn't work how I would have implemented it if I had created the library and written the docs how I did. It is a very capable library, and when I first started using it the docs were more Oracle docs looking - but I could find what I wanted easily. Now, it is much more annoying to delve through but looks more modern.
    - xp84 6d ago
      As relevant today as it was 26 years ago: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... See also: Chesterton's Fence

nfw2 6d 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 6d 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 6d 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 6d 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

whstl 6d ago

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.

moomoo11 5d ago
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.