oh yeah, disclaimer: I write UI frameworks and dabble in PLs.
Is that something we should be engineering for right now?
Now this is somewhat problematic if someone wants to implement better fine grained reactive systems. And I posit that the next paradigm is going to be in that direction given what I've been working on (furthering current reactive systems which only go halfway).
The abstraction is huge advantage, especially when targeting different devices and screen sizes. We (and that includes Apple) have been learning the value of those kinds of abstraction boundaries for years, well before React.
It's also important to note that SwiftUI and UIKit are composable, so if some small part of your app needs low-level, finer grained control, then go ahead and use UIKit/Core Animation/Metal and SwiftUI for the rest.
Then you can only have islands of either paradigm within each other. UIKit and SwiftUI do indeed compose, albeit coarsely.
I can't blame them, they got influenced by react. Don't even blame react, it was a good attempt. Basically trying to build a UI from a snapshot of a tree. Except this is too simplistic a model. They designed it as if you could equate the number of games and the number of positions in chess. Like a markov chain. Except playing chess has side effects. A mere snapshot does not encode those.
I understand the mistake.
It also depends on features. Many apps don't rely on platform features (widgets, watch apps) and are essentially webviews, and those will continue to do just fine on RN.
We have small shims for IOS or Android BLE. But otherwise the discussion of should you go native is really a discussion of how many employees do you have to throw with this?