2025年1月，Shopify工程博客还在说React Native“前途一片光明”，计划继续加码投入。二十个月后，同一个博客团队推翻了这句话：Shopify将把苹果、安卓两个客户端重新用Swift和Kotlin写一遍。不是产品出了问题，是六年前那个决定的前提，被AI改写了。
六年前为什么选React Native，现在为什么不选了
2020年，Shopify的理由很朴素：不想把同一个功能写两遍，想让开发者能跨栈干活，想少花时间追功能对齐。这套逻辑跑了六年，效果不差——2025年1月Shopify自己报的数字是：所有App迁移完成，P75加载低于500毫秒，崩溃免疫会话率超过99.9%。当年9月，还完成了React Native New Architecture的全量升级。
按这个进度，React Native本该继续用下去。变化出在别处：coding agent不再只是帮忙写代码，开始能“参照iOS版本实现Android版本，反过来也一样”。Shopify内部拿几个核心模块用Swift和Kotlin重写试了试，发现速度和质量比想象中好。于是2026年9月2日，官方博客把结论掉了个头：跨平台共享代码的收益被agent削平了，原生贴近系统、少一层框架的优势，一直都在。
数据是真的漂亮，流程也是真的复杂
Shop App是第一个被重写的应用，Shopify给了一组自报数字：iOS启动从3200毫秒降到2466毫秒，快了23%；Android从4433毫秒降到2233毫秒，快了一半；安装包从293MB减到184MB；构建时间降了约75%；崩溃免疫会话率从99.5%以上提升到99.95%以上。
这些数字背后，是一套叫Helix的工作流：agent不是一把梭哈把代码翻译一遍，而是把每个屏幕拆成一串检查点，每一步都要过测试、过视觉比对、过两轮“对抗性”代码审查、再拿到人工点头，才能进入下一步。配套工具Tardis负责把应用状态、日志、截图结构化，减少agent瞎猜的成本。
- 结论.Helix的关键不是让agent一次性写对，而是把每一步的不确定性都锁进检查点里，逼着差结果没法往下走。
开源社区拿到的是过渡期，不是保证
Shopify这些年在React Native生态里贡献了几个头部开源库，转向原生之后，三个库命运各不相同：React Native Skia赞助到2026年底，之后由原维护者另立门户；FlashList周下载量约200万，Shopify只负责修致命兼容性问题，长期维护权正在找下家；Restyle用户量较小，直接维护到年底后归档，欢迎社区fork。
- 风险.大厂用完开源库的红利，转身把维护责任留给社区，这次给了过渡期，但责任外部化的老问题没有变。
我不太买账的是“AI证明了原生更划算”这个说法
Shopify的叙事很克制，没说React Native失败，只说决策前提变了。这个态度值得认可。但把这件事读成“AI已经让原生开发普遍变便宜”，是过度解读。
2026年一项针对真实Swift/Objective-C混合代码库的移动agent基准测试显示，最好的配置下成功率只有12%。Shopify的Helix能跑通，靠的是检查点、对抗审查、专用CLI这套自建基础设施，把通用agent的短板一层层补上——这套东西，不是随便一个中小团队能在几个月里凑出来的。
行业里也不是只有一种答案。Airbnb在2017年就因为bridge性能和调试难度回过原生，但那是老版本React Native的问题。Discord的做法更折中：大部分功能留在React Native，只把内存和滚动敏感的组件单独用原生重写。Meta自己作为React Native的创造者，移动基础设施也一直是原生为主、React Native为辅。这次Shopify的选择，更像是“规模够大、生命周期够长、性能要求够高”这个特定条件下算出来的账，不是行业风向标。
此一时，彼一时；变的从不是框架好不好，是谁算得起这笔账。
对新起步的团队来说，2026年的答案没有变得更简单：手头没有Helix级别的agent基建，React Native加AI辅助大概率还是性价比更高的选项。Shopify给出的是一个上限案例，不是一份可以直接抄的作业。接下来真正该盯的，是FlashList最后交给谁维护，和Shopify那个300多个屏幕的主App，能不能在12周的光鲜数字之外，也扛住线上真实流量。