我现在依然使用 RN 方案来做公司主要业务开发，也服务过一些中小客户（项目金额大概 10-100W 之间）。针对楼主附言提到的问题，我认为大部分都是不是 RN 自身的问题，是团队的开发方式需要优化，不应该把锅甩给框架。
我一条条列一下我的观点：
1. 百度移动统计每次都需要手动埋点，无法实现自动埋点
自己的 RN 业务一般要自行封装导航路由和公共组件，完全可以实现自动埋点，梳理一下内部规范即可。我们现在用 AppCenter 来做的，相比原生差不了多少。
2. 很多三方的 SDK 都只有原生端接入，没有 RN 接入方式，需要自己封装一层 native 接口供 JS 调用
分开说：
- Native Module 一般工作量不大，主要接口调用，一次性工作。
- Native UI Component 相对复杂一些，最好 Native UI 封装完再套一层 React Native Component 封装，但对于整体工作量来说，比两端纯 Native 开发还是会小不少的（大部分场景）
3. 很多参数，例如：设置页面参数，通道参数，都是写在 RN 层，与原生层交互需要多一层逻辑
多的这层逻辑指的是 Native Module 封装，实际会影响性能和体验么？这样业务层 Android 、iOS 只写一遍岂不是更好？
4. RN 写的界面，没办法实现复杂的手势操作逻辑，例如：坐标定位不方便，无法解决兼容性问题。还有
手势传递、冲突等一系列问题也没有很好的解決方案。
这确实是个问题，对于高要求的复杂手势和动画来说有一些实现难度，可能封装 Native UI 会更好。对于一般手势交互效果，基本 react-native-gesture-handler + animated2 都能应对。
5. RN 本身也是一个框架，存在很多 Bug ，用原生写则不会有这些 Bug 。每次升级 RN 的版本都会是一个
大动作，不敢轻易升级，因为每次升级都会出现新问题，现在 RN 仍然有几百个 Bug 没有解决。
0.60+ 之后比较稳定了，目前没有遇到特别卡壳的问题
6. 一些界面没办法用 RN 实现，或者说在 RN 上找不到实现方案，例如 Android 的悬浮窗，ios 的画中画
功能。
这部分通过封装 Native Module 模块来解决就可以，一般都是特殊场景，特殊处理
7. RN 的性能、体积问题。性能问题：FlastList 列表渲染在有大量数据刷新，或者有复杂的列表功能时，
渲染卡顿，发热，用原生的 RecycleView 则不会有这些问题。RN 的 apk 包会比原生的大。RN 多了一
层 JS 与 Native 之间的一层 Bridge ，这层桥接也会影响性能。
我们有在业务场景中遇到过列表显示大量监控数据时的卡顿问题，换原生 TableView/RecycleView 也卡，主要还是数据处理上下功夫，通过优化渲染逻辑的方式可以解决。对于 RN 多的 Bridge ，新的版本有 JSI ，性能提升还是很显著的。
8. 三方支持库不如原生的多，＃且基本上不怎么维护了，质量参差不齐，不少需求都需要自己造轮子
我认为原生库的封装成本不高，我们之前的业务就是从原生切到 RN 的，总体开发成本下降非常多，周期和质量都有显著提升。
9. 国际化问题：如果一些界面是原生写的，这些界面也需要国际化文本，那么文案要么在 native 做一套单
独的，这样就需要维护 json 和 xml 两套文本了，要么就需要从 RN 层传到 native 来显示。
这个可以同一套...写个脚本 XML 转 JSON ？
10. 测试同时没办法写自动化测试，因为 RN 界面的元素、控件，全部没有 ID ，无法定位。
我们有些 RN 业务界面室友做自动化测试覆盖的，可以使用 Detox 。对于 ID ，我想你说的是 testID ，在 0.5x 的版本中确实有一定问题，对于现在 0.60+ 来说，可以直接添加 testID 属性，文档地址：
https://reactnative.dev/docs/view#testid11. 和 native 强相关的功能，基本起不到什么作用：例如 IM 、OTA 升级，各种 so 库、蓝牙、SPP 通信。
没做过 IM 的业务，我知道极光有 RN IM SDK 。对于 OTA 升级、蓝牙通信，使用 RN 开发应用在业界是非常普遍的，比如小米的米家、涂鸦智能的涂鸦 app ，他们做物联网业务的必备功能。我这里自己接了几个出海项目，也有包涵这些特性，出货都没什么问题。RN 解决的是跨端界面的交互开发，就算用其他跨端方案，也是需要 Native 接口的封装。