Of course some stuff sometimes doesn't work well, react-native link versus Pods, native modules or various SDK integration, navigation is sometimes tedious to work with but it is worth it really.
I don't regret at all the choice of migrating our app to RN one year and a half ago.
After 3 times using RN and having to go back to native... never again. When even simple things like navigation or animations take hours of research to get right.
The hardest part for me was getting React-Navigation and RN-Web to play nicely together so I could have substantially one codebase for 3 platforms. That was admittedly a fair bit of googling and fiddling.
The documentation and tutorials leave a lot to be desired, too. A lot of this stuff is outdated, and the official documents are imprecise and feel like a draft (even when compared to what the much less mature Flutter brings to the table in this regard).
Tooling is far behind what you get if you go native. Eg. support for refactoring, whatever editor you use, will be more than rudimentary and virtually nonexistent in comparison to what Android Studio offers. The same goes for unit testing / integration testing support, it's rather iffy.
One of the more important UI Android features - Material transitions - is pretty much impossible to recreate in React Native.
This isn't meant to be a rant: just an honest summary of my few weeks of experience fiddling with RN. You mention your native development was done in Swift; I heard that React Native is allegedly much more reliable for iOS than Android development. I can't really verify it either way, but potentially this might be why our mileages vary.
The upsides? React Native pretty much abstracts away the lifecycle concerns, which are still a pain in the neck for a native Android dev. Hot reloading. No obsolete APIs maintained for backwards compatibility; understandably. Asynchronous programming is simple enough (although with Kotlin's coroutines arguably on their way to become the go-to solution on Android, it's not necessarily a win over native). Nothing else has impressed very much me so far. I used Xamarin for a commercial project once, and it felt considerably better, even though it was three years ago.
If we cared about platform perfect compliance with standard UX, it might be more challenging. Of course, if cared about native perfection, we probably wouldn’t be trying an inherently cross-platform tool.
This despite the fact that React Native was in fact a giant pain in the ass for a bunch of reasons. Native Android styling's that bad. Also saved me having to run Android Studio most of the time, which is a bonus. Though to be fair AS is more pleasant than Eclipse was, at least.
When a developer suggests spending "hours of research" on a problem is enough to make them abandon a potential technology, I don't often think the problem lies with the technology.
For what it's worth my team uses React Native and we've faced the same problems; we solved it by making sure every project has one dev capable of doing the lower level native work. That still means the rest of the team can be web developers, who are much easier to hire because more people know that stack. That alone makes RN a good bet despite its quirks.
Core navigation still doesn't "just work" for RN. At all. The pure JS solutions are garbage and limit what you can do tremendously. The native solutions have tons of other issues you have to hack around.
Only use platform languages for production code, anything else just adds more FFI, debugging effort, lack of tooling and impedance mismatchs.
So for portable mobile apps, I am a big supportive of C++ with native views, or just plain mobile Web, specially now with PWAs.
For customers only focused in a specific platform, then full native.
So the fact that some projects are using some new server driven technology for some features doesn’t really prove anything.
Unless they specifically announce they are dropping RN support from the app or you see a big drop off in pull request activity I wouldn’t jump to any conclusions.
>The path of a world that is 100% native or 100% React Native is relatively straightforward.
but ultimately... hybrid apps are hard. Airbnb had a ton of infrastructure that needed porting over to RN that often required contributing upstream to fix issues they found. If you're starting from scratch you can get pretty far sticking to React/JS.
imo I can't imagine a startup using anything other than RN (or react-native-web) because of how quickly you can build things.
Server-driven UI rendering and Litho/ComponentKit are also growing along with React Native. Facebook app has a big enough surface that it makes sense to have different rendering strategies for different use cases.
That's an odd statement. Playing mix-n-match with rendering strategies without a very clear UX justification for doing it is an invitation for designers and mediocre product people to indulge themselves at the expense of the overall UX.
I wonder why they even bother with supposedly following semver at this point. 0.59? This seems to mean they can break anything at any point and it's technically still "following semver". I guess I just don't understand it. This library is used by thousands and consumed by millions (billions?). Why not just use dates as versions?