Shopify弃用React Native回归原生：AI如何改写移动开发技术选型

Shopify的技术转向：从跨平台回归原生开发

Shopify近日发布了一篇引人深思的工程博客《Native is now the future of mobile at Shopify》，宣布将其移动应用从React Native迁回原生的Swift和Kotlin独立代码库。这一决定颇具象征意义——Shopify曾是React Native生态最坚定的企业级支持者之一，如今却选择回归原生。

你可能没注意到，Shopify并没有贬低React Native。在这篇措辞严谨的博客中，他们充分肯定了React Native在过去六年里对公司的价值。这不是一次带着怨气的分手，而是一次基于技术现实变化的理性重估。

当初Shopify为什么选择React Native？

回顾2020年，Shopify决定从原生切换到React Native，理由几乎是所有采用跨平台方案的团队的共同动机：

• 避免重复造轮子：不用把同一个功能在iOS和Android上各写一遍
• 打通技术栈：让开发者能够跨端工作，不必严格区分iOS工程师和Android工程师
• 聚焦价值交付：把时间花在发布新功能上，而不是追赶两个平台之间的功能一致性（feature parity）

这三条理由在当时无懈可击。原生开发的最大痛点在于两套代码库带来的双倍维护成本，以及iOS与Android之间难以避免的功能与体验差异。React Native用一套JavaScript/TypeScript代码解决了这些问题，因此成为了众多大型企业的合理选择。

AI编程助手改写了成本方程式

那么，是什么让Shopify改变了主意？答案指向了近两年最热门的变量——AI编程助手。

Shopify在博客中给出了关键判断：

原生仍然意味着要在两个平台上构建和维护软件，这个成本并没有消失。真正改变的是，AI Agent现在已经能够完成足够多的实现、翻译、测试和评审工作，以至于它不再是2020年时那个决定性的因素了。

这段话的分量不容小觑。它意味着，跨平台框架赖以存在的核心价值主张——降低双平台维护成本——正在被AI编码工具所削弱。

从「省人力」到「AI补齐」：开发效率的范式转变

过去，团队最担心的是「同一个功能要写两遍」。现在，AI Agent可以承担大量重复性实现工作：将一个平台的功能「翻译」到另一个平台、自动生成测试用例、辅助执行代码评审。当这些工作的边际成本被AI大幅拉低后，原生开发固有的双倍成本就不再是难以逾越的门槛。

换句话说，React Native最初解决的是「人力成本」问题，而AI Agent则从另一个方向解决了同一个问题——不是让你只写一遍，而是让另一遍变得几乎不费力。当两条路殊途同归时，原生方案在性能、平台能力、用户体验上的天然优势就重新占据了上风。

对React Native开源生态的连锁影响

Shopify不仅是React Native的使用者，更是这个生态的重要贡献者。它维护着三个颇有影响力的开源库：

• react-native-skia：基于Skia图形引擎的高性能渲染库，被大量项目依赖
• flash-list：高性能列表组件，是社区广泛使用的FlatList替代方案
• restyle：一套类型安全的样式系统

Shopify的处理方式相对负责任：react-native-skia和flash-list这两个使用广泛的项目正在寻找新的维护者，确保社区不会突然失去支持；而用户基数较小的restyle则将在2026年底归档。

这一安排传递出明确信号：Shopify正在有序退出React Native生态。对于依赖这些库的开发团队而言，尽早评估替代方案和迁移路径是当务之急。

跨平台方案是否迎来黄昏？

需要冷静看待的是，Shopify的选择并不代表React Native或跨平台方案的终结。这更像是一家拥有充足工程资源、对原生体验有极高要求的头部企业，在AI能力逐步成熟后做出的针对性决策。

对于大多数中小团队而言，AI同样可以反过来强化跨平台方案的开发效率，未必需要回归双代码库的模式。真正的启示在于：AI正在重新定义技术选型的成本模型。许多在2020年前后确立的架构决策，其背后的成本假设可能已经悄然失效，值得重新审视。

Shopify这次回归原生开发，与其说是技术钟摆的简单回摆，不如说是AI时代下工程决策逻辑被重构的一个标志性案例。当实现、翻译、测试这些工作的成本被AI大幅压缩后，我们衡量「什么是好架构」的标准，也需要随之更新。