Shopify is moving from React Native back to Swift and Kotlin

来源：HackerNews

Shopify 弃用 React Native，回归 Swift 与 Kotlin 原生开发

原文链接：https://shopify.engineering/back-to-native

来源：HackerNews

背景与概述

2019 年，Shopify 在收购 Tictail 团队后高调宣布全面押注 React Native，认为"在移动端，任何不共享的代码都疑似缺陷"。这一决策在当时引起了巨大反响，许多团队将其视为跨端方案的教科书级背书。然而五年之后，Shopify 工程团队发布了一篇名为《Back to Native》的文章，宣布正式弃用 React Native，移动应用回归 Swift（iOS）和 Kotlin（Android）原生开发。

这个转变并非一时兴起。Shopify 在文中坦承，React Native 并没有成为他们期待的"银弹"——共享代码带来的收益被日益增长的隐性成本所吞噬。更重要的是，原生开发生态本身发生了翻天覆地的变化：SwiftUI 和 Jetpack Compose 的成熟、AI 编程助手的崛起、以及移动端用户对性能和平台体验要求的提升，共同改变了跨端技术的成本收益方程式。

这一决策在 HackerNews 上引发了热烈讨论，因为它触及了移动端开发一个经久不衰的争论：跨端共享代码与原生体验之间，到底该如何取舍？ Shopify 的答案是——在这个时间节点，原生重新赢了。

核心内容

Shopify 在文章中给出了回归原生的几大理由，可以归纳为以下要点：

1. 共享代码的收益被高估了

Shopify 发现，他们的应用中真正能够跨平台共享的业务逻辑远比想象中少。大量代码实际上是与平台紧耦合的——导航、手势、动画、无障碍支持等。所谓的"共享层"往往只是薄薄的一层状态管理，却需要付出维护两套桥梁（Bridge）、处理平台差异的成本。

2. SwiftUI 与 Jetpack Compose 成熟了

2019 年时，声明式 UI 框架还是 React Native 的专属优势。但如今 SwiftUI 和 Jetpack Compose 已经成熟，原生开发同样能享受到声明式、响应式的开发体验，而且与系统 API 零摩擦。React Native 曾经的"代差优势"已不复存在。

3. 平台新特性需要第一时间跟进

iOS 的 Widget、App Intents、Dynamic Island，Android 的 Material You、预测性返回手势等特性，跨端框架的支持总是滞后。对于 Shopify 这样追求顶级用户体验的公司，等待框架适配的窗口期是无法接受的代价。

4. 调试与发布的一致性问题

React Native 的调试构建和发布构建在行为上存在差异（如 Hermes 引擎、代码压缩），导致一些 bug 只在生产环境出现。这种"在我机器上是好的"问题消耗了大量工程师时间。

5. AI 辅助编程改变了游戏规则

这是文章中最具前瞻性的观点。当前这一代 AI 编程助手（如 Copilot、Claude 等）对 Swift 和 Kotlin 的训练语料质量更高、覆盖更广。一个由原生代码构成的代码库，反而比混合栈更容易获得 AI 的高质量辅助——AI 一次只需精通一门语言和一个平台。

技术分析

从技术架构角度看，Shopify 的决策反映了跨端方案的几个结构性问题：

桥接层的固有开销。 React Native 的 JS 线程与原生 UI 线程之间需要序列化通信，即使有了新架构（JSI、Fabric），复杂的交互动画仍需借助 Reanimated 等方案绕开桥接。对于电商应用这种重列表、重手势的场景，原生渲染管线（Core Animation / RenderThread）依然是最短路径。

双语言心智负担。 RN 团队实际需要掌握 JS/TS + Swift + Kotlin + C++（原生模块），��术栈复杂度不降反升。回归原生后，每位工程师只深耕一个平台，代码评审、on-call、知识传递的成本都显著下降。

此外值得注意的是，Shopify 并非全盘否定跨端——他们明确提到共享代码仍适用于后台管理系统（Admin）这类"效率优先"的内部场景。关键洞察是：面向消费者的 App 和面向内部的工具，应该用不同的技术栈来服务。 消费者 App 中 80% 的体验是平台特有的，而内部工具恰恰相反。

实践建议

对于正在技术选型十字路口的团队，Shopify 的经历提供了宝贵的参考：

诚实地评估"可共享代码比例"。 用数据说话：统计你应用中真正平台无关的业务逻辑占比。如果不足 30%，跨端框架的杠杆效应有限。

区分产品类型。 内部工具、B 端应用优先考虑 Flutter/RN 降低成本；面向 C 端的旗舰 App，原生 + 声明式 UI（SwiftUI/Compose）往往是更稳的选择。

拥抱声明式原生框架。 如果你的团队停留在 UIKit/View 系统时代，迁移到 SwiftUI 和 Compose 的成本远低于引入跨端框架，且能获得接近 RN 的开发效率。

关注 AI 对技术栈选择的影响。 AI 助手正在重塑开发效率曲线。选择训练语料充足、社区活跃的原生技术栈，意味着能借 AI 之力放大单兵产出。

小步迁移，而非大爆炸重写。 Shopify 采用了逐屏替换的策略：新功能直接用原生开发，旧 RN 屏幕随迭代自然消亡，避免了高风险的重写。

总结

Shopify 回归原生不是跨端技术的"死刑判决"，而是一次冷静的算账：当 SwiftUI、Jetpack Compose 和 AI 编程助手抹平了跨端框架的效率优势后，共享代码剩下的就主要是妥协。这个故事的启示在于——技术选型没有永恒的正确答案，只有与当前生态和团队阶段匹配的答案。 五年前 RN 是 Shopify 的最优解，五年后原生是，而这种敢于推翻自己、用数据驱动决策的工程文化，或许比结论本身更值得借鉴。

文章摘要