4 ms·

> Sometimes that tradeoff is worth the cost but other times (particularly in the era of Swift and SwiftUI having replaced Objective C and UIKit) you’ll be bette

by sofixa 1y ago

> Sometimes that tradeoff is worth the cost but other times (particularly in the era of Swift and SwiftUI having replaced Objective C and UIKit) you’ll be better off just biting the bullet and learning a little native code. As a JS developer I found Swift to be a delight. But then you have double the work, in double the languages/frameworks for the two platforms.

JimDabell 1y ago
It’s not double the work – native developers don’t have to do the type of work listed in the article.
cosmic_cheese 1y ago
It’s not really double, something closer to 1.25x. The bulk of the work is on whatever platform you first implemented the UI on, because that’s where rubber hits the road and you run into things like assumptions the designer made breaking. On the second platform all that’s already done and you just need to replicate. Besides that, in your typical CRUD app the UI really shouldn’t be the hard part anyway. Additionally, you’re going to have to deal with per-platform bugs which require you to dig in to the native side to fix even if you go all in on RN or Flutter or whatever the cool thing is this month, and that’s in addition to the bugs with the framework. Finally, major system updates tend to be much more of an ordeal with these frameworks where (for example) mature iOS apps can easily go years without major changes. There’s also things like https://skip.tools/ https://skip.tools/ which translates your iOS SwiftUI app into native Android Jetpack Compose on the fly. All in all a lot less trouble than it might seem.
afavour 1y ago
Double the code, but not necessarily double the work. And look at this blog post: these "write once" solutions often have the surprise of a bunch of extra work you weren't expecting.
thegrim33 1y ago
For a real world datapoint - my team at a FAANG invested heavily into RN over the course of years, the promoters kept touting the "only write code once!" line, and after years and years of effort in the end we managed to share only ~10% of code for any given new feature. For any given RN feature we also had to write so many APIs/hooks/setup in native code to support it that the 10% code share didn't even save us any time. In fact, we were prevented from doing a lot of stuff that we wanted to do, because RN either A) didn't support it (because iOS didn't have a similar concept), or B) we were gated on upgrading / using something because it depended on doing a massive RN version upgrade, which nobody wanted to schedule the time for. So I'd argue it was a net negative to productivity overall. I could continue ranting and raving about this for many paragraphs but I'll limit it there. Not a fan.
- creamyhorror 1y ago
  We're looking at moving to Expo from RN precisely to reduce the pain & risk of RN+dependency upgrades just to stay compatible. Google (and Apple) have been keeping us on the upgrade treadmill, so I'm hoping Expo can be responsible for handling that and maintain a stable API for our apps and dependencies.
  - sagacity 1y ago
    What makes you think Expo is not going to just be more of the same? Genuine question.
    - no_wizard 1y ago
      They manage so much of the pain points, like the toolchain, building, releasing etc. It’s night and day compared to using RN directly
  - terandle 1y ago
    Have had our apps on expo for a while. Highly recommend, much easier upgrades and you can turn off any platform vendor stuff like their OTA updates and do local builds also. Expo + RN has saved us a ton of time on our apps and no way a small team like us could support both platforms otherwise.
  - foresterre 1y ago
    At my company we have been using react-native for years without Expo, and aside from some performance issues here or there it has mostly been great (we also use Android auto so that's my reference to "native-ish mobile"). Recently we've been trialling Expo again, and I think it has much approved from where it was a few years ago (when we went in the opposite direction). It mostly saves you time on the build side and gives you some known to work 'good' libraries to depend on, and if you want it, a file based router (we just kept using react-navigation directly, on which the router is built). The biggest pain in react-native are the major version updates which are regularly breaking (and the lack of css grid , you'll have to make do with flex) With Expo, that's not necessarily gone, but the updates are usually smaller compared to respective Android updates (but you still need to comply with new rules for app stores), and usually less painful because with Expo (unlike react-native directly) there's less to manually update within the platform native files which is error prone, even when you use Microsoft's upgrade tool. When you are some versions behind it was sometimes easier to bootstrap from scratch and copy over your own code. One thing to say about Expo is that, here too, it's easier to start with a newly created app than to add expo later on, partly because Expo's docs assumed you did that.

by sofixa 1y ago

JimDabell 1y ago

It’s not double the work – native developers don’t have to do the type of work listed in the article.

cosmic_cheese 1y ago

It’s not really double, something closer to 1.25x. The bulk of the work is on whatever platform you first implemented the UI on, because that’s where rubber hits the road and you run into things like assumptions the designer made breaking. On the second platform all that’s already done and you just need to replicate. Besides that, in your typical CRUD app the UI really shouldn’t be the hard part anyway. Additionally, you’re going to have to deal with per-platform bugs which require you to dig in to the native side to fix even if you go all in on RN or Flutter or whatever the cool thing is this month, and that’s in addition to the bugs with the framework. Finally, major system updates tend to be much more of an ordeal with these frameworks where (for example) mature iOS apps can easily go years without major changes. There’s also things like https://skip.tools/ https://skip.tools/ which translates your iOS SwiftUI app into native Android Jetpack Compose on the fly. All in all a lot less trouble than it might seem.

afavour 1y ago

Double the code, but not necessarily double the work. And look at this blog post: these "write once" solutions often have the surprise of a bunch of extra work you weren't expecting.

thegrim33 1y ago

For a real world datapoint - my team at a FAANG invested heavily into RN over the course of years, the promoters kept touting the "only write code once!" line, and after years and years of effort in the end we managed to share only ~10% of code for any given new feature. For any given RN feature we also had to write so many APIs/hooks/setup in native code to support it that the 10% code share didn't even save us any time. In fact, we were prevented from doing a lot of stuff that we wanted to do, because RN either A) didn't support it (because iOS didn't have a similar concept), or B) we were gated on upgrading / using something because it depended on doing a massive RN version upgrade, which nobody wanted to schedule the time for. So I'd argue it was a net negative to productivity overall. I could continue ranting and raving about this for many paragraphs but I'll limit it there. Not a fan.

creamyhorror 1y ago
We're looking at moving to Expo from RN precisely to reduce the pain & risk of RN+dependency upgrades just to stay compatible. Google (and Apple) have been keeping us on the upgrade treadmill, so I'm hoping Expo can be responsible for handling that and maintain a stable API for our apps and dependencies.
- sagacity 1y ago
  What makes you think Expo is not going to just be more of the same? Genuine question.
  - no_wizard 1y ago
    They manage so much of the pain points, like the toolchain, building, releasing etc. It’s night and day compared to using RN directly
- terandle 1y ago
  Have had our apps on expo for a while. Highly recommend, much easier upgrades and you can turn off any platform vendor stuff like their OTA updates and do local builds also. Expo + RN has saved us a ton of time on our apps and no way a small team like us could support both platforms otherwise.
- foresterre 1y ago
  At my company we have been using react-native for years without Expo, and aside from some performance issues here or there it has mostly been great (we also use Android auto so that's my reference to "native-ish mobile"). Recently we've been trialling Expo again, and I think it has much approved from where it was a few years ago (when we went in the opposite direction). It mostly saves you time on the build side and gives you some known to work 'good' libraries to depend on, and if you want it, a file based router (we just kept using react-navigation directly, on which the router is built). The biggest pain in react-native are the major version updates which are regularly breaking (and the lack of css grid , you'll have to make do with flex) With Expo, that's not necessarily gone, but the updates are usually smaller compared to respective Android updates (but you still need to comply with new rules for app stores), and usually less painful because with Expo (unlike react-native directly) there's less to manually update within the platform native files which is error prone, even when you use Microsoft's upgrade tool. When you are some versions behind it was sometimes easier to bootstrap from scratch and copy over your own code. One thing to say about Expo is that, here too, it's easier to start with a newly created app than to add expo later on, partly because Expo's docs assumed you did that.