Shopify在工程博客宣布，iOS和Android客户端将从统一的React Native代码库，重新拆分成独立维护的Swift和Kotlin原生项目。这家电商巨头2020年才把移动应用从原生迁到React Native，六年后又迁了回去。
Shopify没有说React Native不行。文章里明确给六年的React Native表现记了功。真正被点名的变量是AI编程代理——它们现在能替团队分担足够多的实现、翻译、测试和代码审查工作,让当年选择跨平台的成本账,算出了不同的结果。
2020年选跨平台，2026年拆回原生：变的是分母
Shopify当年转向React Native的理由很典型：不想同一个功能写两遍，想让开发者能跨iOS和Android协作，想把追平两端功能的时间省下来做产品价值。这三条理由撑起了过去十年React Native、Flutter这类框架的市场位置。
这些理由今天依然成立。变化的是分母：AI代理能替团队完成足够多的实现、翻译、测试和审查，2020年那道决定性的成本门槛，不再是决定性因素。
Shopify原文写道：原生仍然意味着在两个平台上构建和维护软件，这项成本从未消失。变化的是，代理现在已经能完成足够多的实现、翻译、测试和评审工作，让它不再是2020年那样具有决定性的因素。
这句话比"抛弃React Native"重要得多。它把讨论焦点从"哪个框架更好"，拉到了"AI压低了哪些成本"。
真正该问的问题：AI能省多少钱，不是框架谁更强
对正在评估技术路线的移动团队，Shopify这次给出的不是答案，是一道新的算术题。跨端框架省的是人力，原生省的是"两端表现要不要打折"的产品分歧。性能上限、平台适配、系统API的第一时间可用性,这些原生天然占优的地方，过去因为人力成本被搁置，现在被AI代理摊薄之后重新划算。
但这道题不是所有团队都能同样解。Shopify是量级足够大、原生技术底子本来就在的公司，拆回原生的门槛天然更低。
| 团队画像 | 更适合的路线 |
|---|---|
| 双端人力紧张，AI辅助编程工具还没跑顺 | 先继续用React Native，把AI代理实际能省下的工时摸清楚 |
| 已有原生技术栈沉淀，只是历史原因迁到RN | 拆回原生的门槛较低，可参考Shopify这条路径 |
| 高频依赖三方RN生态库 | 先确认库的维护状态，再决定要不要现在动手迁移 |
AI能降低原生双端维护的边际成本，但降不掉平台差异、应用商店审核周期和长期人力投入。原生路线的隐性成本没消失，只是被重新定价。Shopify没有公布迁移完成时间表和团队规模，这部分目前还看不清。
开源生态先感受到变化：谁该现在动手
Shopify同时是三个知名React Native开源库的维护方：渲染引擎react-native-skia、长列表组件FlashList，以及样式方案Restyle。前两者要寻找新的维护团队，Restyle因为用户规模较小，计划在2026年底归档。
这对依赖这几个库的团队是近期问题，不是远期风险。react-native-skia和FlashList的用户需要盯着社区谁来接手。Restyle的用户该现在就规划迁移路径，不要等到归档倒计时才动手。
接下来最该观察的是两件事：有没有其他大型团队跟着做同样的选择，以及AI代理省下的成本能不能被量化成具体数字。目前只有Shopify一家公开表态，样本还太小，下结论还早。