6 ms·

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

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 app... just start native. Your devs are barely going to be writing code anyway.

robertlagrant 9d ago
You always still needed a specialist per-platform even if most of the code was RN or KMM[0]. But I agree - a thousand not-great mobile apps sprang from this idea. [0] I always thought the best answer was something like KMM to do all the backend comms and local data model in a shared way, and then a bespoke UI building on what that shared code exposed.
- dd8601fn 9d ago
  > a thousand not-great mobile apps sprang from this idea. Hi. That’s me… not-great mobile app maker. And yes, I’m grateful that RN exists. Mostly what it does is make sure that an Android version of things exist at all.
  - robertlagrant 8d ago
    Hello! As I'm on Android, thank you for your service.
_fzslm 8d ago
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.
- Dfiesl 8d ago
  Android and iphone emulator MCP, model compares screens, flags is theres drift? Something like that I’d guess
  - professoretc 8d ago
    But the screens should look different, right? That's the point of building separate iOS vs. Android versions is to make each version "native" to its platform. The feature-set should be the same, but the interfaces can diverge.
    - Dfiesl 8d ago
      I think the whole native thing is more for better performance, debugging ease and dependency reduction rather than seeking variation in UIs.
      - myko 8d ago
        It is both. You want the application to look correct on the platform the user is on, i.e. Liquid Glass on iOS and Material on Android.
- akd 8d ago
  "GPT-8 Galaxia - figure out where our iOS and Android apps show different doohickeys and fix them"
  - otabdeveloper4 8d ago
    > You're completely right to call me out on this. Here's the real smoking gun: the iDoohickey isn't a real API interface on iPhone
- patcon 8d ago
  Tests? Not being flippant, but that strikes me as the new surface to maintain to get what RN used to offer
spiderice 8d ago
Nobody is talking about the real advantage of RN: Being able to release to the App Store without having to go through a review. That's so massive. Getting a bug fix out to users instantly, sneaking in optimizations, etc.. Sure, you need a review to release native code changes, and you should probably get a review if you have big feature changes just for the sake of Apple not banning you. But in practice, it removes one of the biggest annoyances of developing for the App Store.
- tcoff91 8d ago
  Over the air updates is SO valuable with react-native. Being able to ship hotfixes instantly to our users has saved our asses multiple times.
- sebmellen 8d ago
  This is so true, and I'm surprised that Shopify didn't mention it or that they don't use OTA updates.
- azuanrb 8d ago
  I’ve worked with both native and cross-platform. I think the mentality of being able to make changes quickly without much review often comes from cross-platform, especially when the developers come from a web background. Changes are cheap and fast, so teams often feel less pressure to test everything thoroughly before a release. Which is a fair tradeoff. That’s part of the reason we can have dozens of releases a day on the web. Not just because we can, but because sometimes we have to. With native, you know each release is harder to roll back, so you tend to build more tooling around releases, think through changes more carefully, and test more thoroughly before they’re ready to ship. You opt for one bigger, more stable release every few weeks instead. At the end of the day, both approaches work. Heh, now that I think about it, maybe web and cross-platform devs were the original vibe coders? Changes are cheap and fast. Just move fast and break stuff. Native devs are the old-school ones. Shipping is expensive, so you better get it as right as possible.
  - sebmellen 8d ago
    Totally depends on your business model too. We have clients that often require quick changes for compliance reasons, and they need to ensure all users of our apps are congruently updated. That’s not easy without OTA.
kypro 8d ago
> The main appeal of RN was being able to leverage your web devs for mobile dev. > But now that all code is generated, there's little upside to having an RN app... just start native. Your devs are barely going to be writing code anyway. Are you saying: - webdevs are now able to write and review native code because of AI (who cares if they don't really understand it); or, - Because developers are more productive we can cut the number of webdevs and hire native engineers – same no. engineers, same output, but now native apps. Why not: Continue using RN but now and just enjoy being more productive? If productivity was the reason to pick RN, then enjoy it. It's not a bug.
throwaway27448 8d ago
> The main appeal of RN was being able to leverage your web devs for mobile dev. There's nothing remarkable about the skill set of either party; the appeal here is re-use of code. how the labor markets itself is irrelevant
bryanhogan 8d ago
I think there are many reasons why React Native would be unappealing, my experience with it wasn't that positive. I don't see a reason to use it over web stacks plus CapacitorJS (Or Tauri) or directly native for very large teams.

robertlagrant 9d ago

You always still needed a specialist per-platform even if most of the code was RN or KMM[0]. But I agree - a thousand not-great mobile apps sprang from this idea. [0] I always thought the best answer was something like KMM to do all the backend comms and local data model in a shared way, and then a bespoke UI building on what that shared code exposed.

dd8601fn 9d ago
> a thousand not-great mobile apps sprang from this idea. Hi. That’s me… not-great mobile app maker. And yes, I’m grateful that RN exists. Mostly what it does is make sure that an Android version of things exist at all.
- robertlagrant 8d ago
  Hello! As I'm on Android, thank you for your service.

_fzslm 8d ago

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.

Dfiesl 8d ago
Android and iphone emulator MCP, model compares screens, flags is theres drift? Something like that I’d guess
- professoretc 8d ago
  But the screens should look different, right? That's the point of building separate iOS vs. Android versions is to make each version "native" to its platform. The feature-set should be the same, but the interfaces can diverge.
  - Dfiesl 8d ago
    I think the whole native thing is more for better performance, debugging ease and dependency reduction rather than seeking variation in UIs.
    - myko 8d ago
      It is both. You want the application to look correct on the platform the user is on, i.e. Liquid Glass on iOS and Material on Android.
akd 8d ago
"GPT-8 Galaxia - figure out where our iOS and Android apps show different doohickeys and fix them"
- otabdeveloper4 8d ago
  > You're completely right to call me out on this. Here's the real smoking gun: the iDoohickey isn't a real API interface on iPhone
patcon 8d ago
Tests? Not being flippant, but that strikes me as the new surface to maintain to get what RN used to offer

spiderice 8d ago

Nobody is talking about the real advantage of RN: Being able to release to the App Store without having to go through a review. That's so massive. Getting a bug fix out to users instantly, sneaking in optimizations, etc.. Sure, you need a review to release native code changes, and you should probably get a review if you have big feature changes just for the sake of Apple not banning you. But in practice, it removes one of the biggest annoyances of developing for the App Store.

tcoff91 8d ago
Over the air updates is SO valuable with react-native. Being able to ship hotfixes instantly to our users has saved our asses multiple times.
sebmellen 8d ago
This is so true, and I'm surprised that Shopify didn't mention it or that they don't use OTA updates.
azuanrb 8d ago
I’ve worked with both native and cross-platform. I think the mentality of being able to make changes quickly without much review often comes from cross-platform, especially when the developers come from a web background. Changes are cheap and fast, so teams often feel less pressure to test everything thoroughly before a release. Which is a fair tradeoff. That’s part of the reason we can have dozens of releases a day on the web. Not just because we can, but because sometimes we have to. With native, you know each release is harder to roll back, so you tend to build more tooling around releases, think through changes more carefully, and test more thoroughly before they’re ready to ship. You opt for one bigger, more stable release every few weeks instead. At the end of the day, both approaches work. Heh, now that I think about it, maybe web and cross-platform devs were the original vibe coders? Changes are cheap and fast. Just move fast and break stuff. Native devs are the old-school ones. Shipping is expensive, so you better get it as right as possible.
- sebmellen 8d ago
  Totally depends on your business model too. We have clients that often require quick changes for compliance reasons, and they need to ensure all users of our apps are congruently updated. That’s not easy without OTA.

kypro 8d ago

> The main appeal of RN was being able to leverage your web devs for mobile dev. > But now that all code is generated, there's little upside to having an RN app... just start native. Your devs are barely going to be writing code anyway. Are you saying: - webdevs are now able to write and review native code because of AI (who cares if they don't really understand it); or, - Because developers are more productive we can cut the number of webdevs and hire native engineers – same no. engineers, same output, but now native apps. Why not: Continue using RN but now and just enjoy being more productive? If productivity was the reason to pick RN, then enjoy it. It's not a bug.

throwaway27448 8d ago

> The main appeal of RN was being able to leverage your web devs for mobile dev. There's nothing remarkable about the skill set of either party; the appeal here is re-use of code. how the labor markets itself is irrelevant

bryanhogan 8d ago

I think there are many reasons why React Native would be unappealing, my experience with it wasn't that positive. I don't see a reason to use it over web stacks plus CapacitorJS (Or Tauri) or directly native for very large teams.