But then you have double the work, in double the languages/frameworks for the two platforms.
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.
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.
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.
It’s night and day compared to using RN directly
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.