原生开发重新成为 Shopify 移动端的未来

Native is now the future of mobile at Shopify — simonwillison.net · 11 小时前 · ⚙️ 工程

Shopify 宣布「原生是移动端的未来」，把 2020 年从原生转向 React Native 的决定反向撤销，重新维护独立的 Swift 与 Kotlin 代码库。文章回顾了当初迁移时给出的三条理由——不要为 iOS 和 Android 重复实现同一个功能、让开发者能跨整个技术栈工作、减少在功能对齐上的消耗从而把时间花在交付价值上——并指出这些理由赖以成立的假设正在被 AI 辅助编码推翻：当代码生成、跨语言移植和样板代码补全的成本被大幅压低，「同一功能写两遍」不再是一笔不可接受的重复开销，而 React Native 长期累积的成本反而开始占上风，包括桥接层的性能损耗、第三方依赖与 RN 版本升级的连锁成本、平台新 API 与系统特性的支持滞后，以及调试时必须在 JavaScript 与原生两层之间来回切换的心智负担。作者的观察不是「React Native 已死」这种口号，而是一个更普遍的判断：技术选型的成本结构会随着工具链变化而反转，当年算得过来的账今天可能算不过来，反之亦然，因此架构决策必须被当作有时效的假设来定期重算，而不是一次性的定论。对读者的启示是，如果 AI 真的让重复劳动变得便宜，那么「多写一份代码、少做一层抽象」可能重新变得划算，这与近年一些团队重新评估跨平台框架、甚至主动选择原生双端的动向一致。值得注意的是，Shopify 的体量与移动端业务占比让它有能力承担两支原生团队的成本，这个决定对中小团队未必可复制；而 React Native 本身也在演进，新架构在渲染与线程模型上做了不少改进，所以这更像是一次基于自身成本结构的重新计算，而不是对某个框架的判决。

核心论点

• Shopify 在 2020 年从原生转向 React Native 时给出的三条理由被原文引用：不要为 iOS 和 Android 重复实现同一个功能、让开发者能跨整个技术栈工作、减少在功能对齐上的消耗从而把时间花在交付价值上。这套逻辑在当时成立的前提是「写两遍」的成本高得无法接受，而 React Native 承诺用一份 JavaScript 代码覆盖两个平台，把重复劳动和功能对齐问题一次性解决掉。
• 撤销决定背后的关键变量是 AI 辅助编码带来的成本反转：当代码生成、跨语言翻译和样板代码补全把「同一功能写两遍」的边际成本压到足够低时，React Native 换来的那点复用收益就不再能覆盖它的长期代价——桥接层的性能损耗、第三方依赖与 RN 版本升级的连锁成本、新系统特性支持滞后，以及调试时必须横跨 JS 与原生两层的复杂度。
• 更普遍的判断是技术选型的成本结构会随工具链变化而反转：Shopify 的决定不是「React Native 已死」，而是承认 2020 年那笔账在 2026 年算不过来了。作者同时提醒，React Native 自身也在演进，新架构在渲染与线程模型上有所改进，而 Shopify 的体量与移动业务占比让它有能力养两支原生团队，因此这个结论对中小团队未必可复制。
• 对行业的启示是：如果 AI 让重复劳动变便宜，那么多代码库、少抽象可能重新变得划算，这与近期一些团队重新评估跨平台框架、甚至主动选择原生双端的动向一致。这篇文章的价值在于给出一个可迁移的思维模型——把「我们用不用跨平台框架」当成一道需要定期重算的题目，而不是一个已经结案的历史决定。

💡 为什么值得读: 它用一个真实的战略反转案例说明 AI 正在如何改写跨平台与原生之间的成本公式，读它能让你重新审视自己团队那个「早就定了」的技术选型。

🏷️ React Native, Swift, Kotlin, mobile

---