I have a lot of respect for the work the React Native folks do but at the same time the constant reinvention just highlights an inherent weakness in any framework like this: you don’t control the platform, so you’re always always at least one step behind.

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.

▲

theanirudh an hour ago | parent | next [-]

This used to be the case when the platforms were much younger and new features were introduced every year. But I would say it’s mostly stabilized now. React native had day 1 support for Liquid Glass and new AI APIs introduced on iOS 26.

▲

sofixa 2 hours ago | parent | prev [-]

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

▲

thegrim33 an hour ago | parent | next [-]

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 29 minutes ago | parent [-]

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 7 minutes ago \| parent [-]
		What makes you think Expo is not going to just be more of the same? Genuine question.

▲

cosmic_cheese 2 hours ago | parent | prev | next [-]

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/ 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 2 hours ago | parent | prev | next [-]

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.

▲

JimDabell 2 hours ago | parent | prev [-]

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