截至 2026 年 9 月 11 日，这条 Hacker News 讨论有 1078 points 和 760 条评论。Shopify 公开解释，他们在 2020 年押注 React Native，确实节省了重复开发时间，也让没有移动端背景的工程师更容易参与。现在他们重新增加 Swift 和 Kotlin 的比重，原因是代码模型让原生开发的边际成本下降了。
这件事真正改变了什么
很多团队把跨平台框架当成永久选择，实际上它更像一笔关于人力和产品节奏的预算。React Native 适合界面相近、平台差异有限、需要快速共享业务代码的产品。原生开发适合重度依赖系统能力、动画性能、后台任务、支付、相机或平台新 API 的应用。
过去，原生方案的痛点是同一功能要维护两套代码，招聘也要求团队同时懂两种平台。代码模型可以生成初稿、迁移样板和测试用例，却不能替团队决定生命周期、线程、权限和异常恢复。它降低了输入代码的成本，审查代码的成本仍然存在。
选框架时先算三笔账
第一笔是共享代码比例。不要只看业务页面，统计网络层、数据模型、埋点、缓存、权限和测试中真正能共享的部分。若共享的只有薄薄一层 UI，跨平台优势会缩水。
第二笔是平台特性变化。产品若经常追随 iOS 或 Android 的新能力，原生代码通常更早拿到完整接口。跨平台层需要等待适配，团队还要处理桥接层的性能和版本问题。
第三笔是排障路径。一次线上卡顿，能否快速定位到 JavaScript、桥接层、原生线程还是系统 API。层次越多，问题越难交给新人处理。
一个可执行的迁移办法
- 先按页面和系统能力盘点现有 React Native 代码，标出最常出问题的模块。
- 选一个高频但边界清楚的功能，用 Swift 和 Kotlin 重写，比较启动、滚动、包体和崩溃数据。
- 让代码模型生成重复性迁移工作，人工审查生命周期、线程切换、权限失败和降级路径。
- 保留跨平台方案处理变化少的业务模块，逐步把高风险系统能力移到原生层。
团队还要改什么
迁移时最容易漏掉的是组织结构。若 iOS 和 Android 仍各自排队，原生化只会把等待从框架适配换成团队协作。应把设计规范、接口契约、埋点命名和验收指标写在共同文档里，让两端差异集中在真正需要差异的地方。代码模型可以帮忙生成两端的重复实现，评审人仍要按同一份行为清单验收。
判断迁移是否成功，也别只看提交速度。观察线上启动、滚动、崩溃、包体、热修复和新系统适配时间。若某个模块原生化后性能没有改善，维护人数却增加了，就应停下来重新评估边界。
常见误区
把“代码模型更强”理解成“原生开发不需要经验”，会把审查成本隐藏起来。把“原生性能好”理解成“所有页面都该原生”，又会放弃共享代码带来的效率。框架决定的是约束，团队仍要用真实崩溃、性能和发布周期来校正选择。
FAQ
React Native 还值得用吗？值得。它仍适合跨平台界面和共享业务逻辑，关键在于别把所有系统能力都塞进同一层。
AI 编程会让跨平台框架消失吗？目前没有证据支持这种判断。它更直接的作用是让原生方案的试错和迁移成本下降。
最稳妥的路线是什么？保留现有稳定模块，先用数据找出最值得原生化的边界，再做小范围迁移。