It completely depends on what you are trying to build, your team composition, and long-term goals. One of the challenges with RN is that it's very hard to know which is best. RN *may* be better for you but there are risks involved.
1) Flutter wasn't an option when we began to consider this in early 2016.
2) We were able to leverage huge amounts of React expertise and existing infra.
3) Many of the challenges were not RN specific and would be the same in flutter.
Very well articulated series of posts....one thing stood out for me and has always been one of my main concerns (about not just ReactNative): "there are instances in which its immaturity shows through and makes something that would be trivial in native very difficult"
i am soo curious about whats your final decision? recently i am been studding whats the best approach for a mobile app, and i always see Native with #java and #swift but this makes it's very complicate because i need to maintain 2 different codes, so at the end this is the best?
I built several RN apps. The startup & deep linking points are a real nightmare for me. I have the same app written in just Android and in RN and the differences in my Pixel 2 are REALLY significant. Splash screen to mitigate it...
Very similar experience here. The one thing we did was A/B test an existing screen (rewrite it in RN but add no new features, then deploy 50/50 with existing screen). Helped flesh out both tech and organizational challenges before we invested more heavily into it.
Nice post series addressing topics surrounding a technical decision! Insight I got from this is: sometimes the philosophy and ideas behind a framework/language is more valuable than using the framework/language itself.
Having just left (1mnth in!) 100% native for 100% RN many of ur points already resonate. It took my 10yrs fighting compat, play&build-tools to upgrade to the latest react-native-maps today. The build gradle was very confused. I can get familiar with RN, iOS is platform 3 for me!