Shopify 曾在 2020 年全面押注 React Native，但编程智能体显著降低了 Swift 与 Kotlin 双平台实现、测试和维护的成本。本文译自 Shopify Engineering，介绍其回归原生开发的技术判断、迁移路径，以及 Helix 和面向智能体的快速反馈架构。
原文：Back to Native，作者：Mustafa Ali，发布于 2026 年 9 月 10 日。
本文为简体中文译文，不是本站原创。本文由 LobsterAI 自动翻译和发布。
编程智能体改变了为移动应用开发两套实现的成本。以下是 Shopify 从 React Native 回归 Swift 和 Kotlin 的原因。
作者：Mustafa Ali
发布日期：2026 年 9 月 10 日
原文：https://shopify.engineering/back-to-native
早在 2020 年，我们就决定全面押注 React Native，而这次押注取得了巨大的成功。每项功能只需开发一次，为我们节省了大量时间；没有移动开发背景的开发者也能参与应用开发；我们也不必再不断追赶两个平台之间的功能一致性。
2025 年 1 月，我曾撰文表示，React Native 前景光明，Shopify 计划继续投入。根据当时掌握的信息，这个判断是成立的。React Native 在我们这里运行得很好，直到今天，它依然是一个优秀的框架。但此后，编程模型的能力取得了巨大进步。对于我们的应用和团队而言，分别用 Swift 和 Kotlin 实现同一项功能，已经不再需要付出过去那样的成本。
我们不会仅仅因为一个决策当初取得了成功，就一直坚持它。当核心假设发生变化时，我们愿意回过头来，重新判断它是否仍然正确。大语言模型改变了我们 2020 年决策背后的一项核心假设，因此，我们从第一性原理出发，重新评估了移动端技术栈。
评估的结果，让我们重新走向原生开发。
为什么回归原生开发
2020 年，我们决定从原生开发转向 React Native，主要出于三个原因：
- 不再把同一项功能开发两遍。
- 让开发者能够跨技术栈工作。
- 少花时间追赶功能一致性，多花时间交付价值。
React Native 一直兑现着这些收益。我们发现，自己需要投入相当多的时间和资源来优化性能、改进 React Native 的关键基础部分，以及跟进框架更新和外部依赖，但这些都是可以接受的取舍。使用 React Native 的收益，远远超过了我们在这些方面必须投入的成本。
Shopify 从 2021 年就开始使用大语言模型开发软件，比 ChatGPT 出现还早一年！最初，我们用它们实现功能、排查和修复缺陷，以及审查代码。随着模型能力提升，我们放心交给它们的工作也越来越复杂。到了 2025 年末，它们不再只是帮助我们更快地写代码。它们已经强大到足以让我们重新思考：开发两套软件，是否仍然意味着要做两倍的工作？
我们决定重新评估移动端技术栈，并开始制作原型，看看原来的技术选择是否依然成立。我们用大语言模型，以 Swift 和 Kotlin 重建了几款最大应用中的若干核心部分，效果好得让我们吃惊。智能体能够：
- 以 iOS 版本为参照，在 Android 上实现同一项功能，反过来也一样。
- 帮助开发者快速上手，在自己主要技术栈之外有效地参与开发。
- 通过共享规格说明、测试和审查检查点，大幅降低维持平台间一致性的成本。
原生开发仍然意味着要在两个平台上开发和维护软件，这笔成本并没有消失。改变的是，智能体如今能够承担足够多的实现、代码转换、测试和审查工作，让这笔成本不再像 2020 年那样成为决定性因素。
React Native 应用完全可以很快。我们的应用就是如此。我们做出这次改变，是因为智能体削弱了共享实现的优势，而针对每个平台单独开发的优势依然存在。原生开发让我们更贴近平台能力和第一方工具，也让代码与平台之间少了几层框架和依赖。
我们的 React Native 开源库将何去何从
在讨论如何迁移之前，我们希望先确保妥善完成这次转变。从一开始，我们就希望回馈 React Native，让它变得更好。我们发布的开源库，已经成为各自类别中的首选。社区给予的热烈支持让我们十分感激，我们也承诺确保这次交接平稳进行，不让大家措手不及。
React Native Skia
Shopify 将继续资助 React Native Skia，直到 2026 年底，而 William Candillon 在那之后也会继续开发它。他将在未来几个月内 fork 这个代码仓库，并开始以新的名称发布该库。交接完成后，原仓库将被归档。我们会持续发布进展，让所有人都有充足的迁移时间。如果你的应用依赖这个库，请考虑资助它。
FlashList
FlashList 每周下载量约为 200 万次，已经成为在 React Native 中渲染高性能列表的默认选择。考虑到它对整个生态的重要性，Shopify 将继续修复会破坏兼容性的关键问题。我们目前正在与几家公司讨论，由它们承担 FlashList 的长期维护责任。如果你感兴趣，可以在这里联系我。
Restyle
Restyle 的用户规模比我们的其他库更小，因此我们将归档这个仓库。我们会让它保持可用，直到 2026 年底，之后停止维护。欢迎任何人 fork 并继续推进；如果有团队愿意接手，我们也会协助交接。
我们如何迁移
Shopify 拥有多款大型应用（Shopify、Shop、Point of Sale、Inbox）。世界各地数百万商家和买家每天都依赖它们谋生，或从喜爱的品牌购买心仪的商品。
我们讨论过，是在现有应用中逐步迁移到原生开发，也就是渐进式改造（brownfield），还是从零重建，也就是全新开发（greenfield）。过去迁移到 React Native 时，我们为几款最大的应用选择了渐进式改造，因为重写它们需要好几年，而且在重写期间，我们将不得不停止推出新功能。
但这一次，从零重建明显胜出，原因如下：
- 大语言模型擅长以 React Native 版本为参照，用 Swift 和 Kotlin 实现功能。
- 这让我们可以从一张白纸开始，不受过去的限制，以尽可能好的方式重建。
- 原型验证表明，我们重建这些应用的速度，可以远远超过编程智能体出现之前。
经常位居应用商店购物类别榜首的 Shop，是第一款完成迁移的应用。在 AI 的辅助下，团队仅用 12 周，就从概念验证走到了完整重建的原生应用在应用商店上线。我们已经撰文深入介绍了这次迁移。
Shopify 应用的迁移也在进行中，将于今年晚些时候发布。这是我们最大的应用，包含 300 多个页面、主屏幕和锁屏小组件、Apple Watch 应用、表盘复杂功能、Siri 快捷指令等。其余应用也将很快完成迁移。
防止生成低质代码
直接把大语言模型指向 React Native 代码库，试图让它一次性用原生代码实现相同功能，这种做法很诱人，但行不通。即使你让它预先尽可能多地收集信息，将这些信息固定为规格说明和任务文件，再去实现，最终仍然会得到大量无法维护、不能发布的代码。
为解决这个问题，我们构建了一个名为 Helix 的系统，采用更渐进的方式。它不指望第一次输出就是正确的，而是建立一个循环：一次不完善的尝试，在变成合格结果之前，根本无法进入下一步。
开发者指定一个页面，交给 Helix。Helix 读取 React Native 代码，并提出一系列检查点，也就是将工作拆成有先后顺序的小块，每块都能在几分钟内审查完毕。然后，它逐个检查点进行构建：每个检查点都必须通过测试证明行为正确，在视觉审查中与实际运行的应用一致，经受住两位对抗式代码审查者的检验，并获得人的认可，之后才能提交，再开始下一个检查点。每轮审查的反馈都会被记住，因此随着迁移推进，这个循环的自主程度会越来越高。
Helix 使用 Swift 和 Kotlin 重建 Shopify 移动应用中的一个页面。
这种方法效果非常好，让我们只需过去一小部分的时间就能重建应用。
实现快速反馈循环
让智能体控制模拟器一直是个瓶颈。我们发现自己总得盯着它们，因为它们无法可靠地完成构建、测试和迭代。我们开发了工具，让智能体能够自主复现缺陷、修复缺陷并验证修复结果，但整个过程缓慢且脆弱。React Native 的热模块替换有所帮助，但由于模拟器控制速度慢，它并不能解决问题。这主要是因为智能体需要依赖无障碍树或截图，来获取应用状态、执行操作并验证结果。智能体几秒钟就能改完代码，却要花好几分钟才能测试输出。这让迭代极其缓慢，而且需要大量人工介入。如果模型无法快速测试自己的工作，那它再强也无济于事，而在移动端，快速测试尤其困难。
我们正在解决这个问题：让应用架构同时适合人类和智能体。核心原则是，业务逻辑应当与 UI 完全解耦，并且能够在桌面端无界面运行。随后，我们通过命令行接口（CLI）把这些能力提供给智能体，让它们无需调用模拟器，就能以毫秒而不是分钟为单位完成迭代。
使用 CLI 在应用中导航并执行操作。点击上图观看原文演示视频。
CLI 让智能体无需触碰 UI，就能检查应用状态、在不同部分之间导航并执行操作。这带来了极快的反馈循环，也让智能体能够一次自主工作数小时。
需要与模拟器交互时，CLI 可以通过远程模式连接模拟器，直接用命令驱动 UI，无需检查布局或无障碍树。这使运行速度和端到端测试速度都大幅提升。
这是实时演示，没有加速。点击上图观看原文演示视频。
接下来做什么
我们将把所有移动应用迁移到 Swift 和 Kotlin，并在整个过程中使用 AI。Shop 已经作为完全原生的应用发布，Shopify 应用正在迁移，其余应用也会很快跟上。我们推进得很快，但不是靠降低标准。每次重建都必须达到或超过人们如今所期待的性能、稳定性、无障碍支持和产品质量。这不只是换一种语言重写同样的应用。我们正在重建它们，让人类和智能体都能快速理解、测试和修改。
迁移不是终点。成功意味着，我们的团队能够比过去更快地为商家和买家交付更好的体验。我们将通过产品交付速度、应用质量，以及智能体能够自主完成的工作量来衡量这一点。
我们会分享沿途的经验，包括深入介绍 Helix、我们面向智能体调用的架构，以及我们如何与智能体一起开发移动应用。过去，我们公开分享从 React Native 中学到的经验；这次转变，我们也打算保持同样的开放态度。
这是我们开展过的最具雄心的移动工程项目之一。如果你想参与打造下一代 Shopify 移动应用，我们正在招聘移动工程师、基础设施工程师，以及在 AI 与软件工程交叉领域工作的开发者。
致谢
原生开发是 Shopify 现在的正确选择，但 React Native 是 Shopify 在 2020 年的正确选择。当时之所以能够成功，离不开那些让它真正发挥作用的人。
Meta
感谢 Meta 的 React Native 团队，出色地维护和推动这个框架，倾听我们的反馈，并在这些年里与我们密切合作。正是由于你们对架构、性能、工具和社区的投入，今天的 React Native 才有了长足进步。
William Candillon
感谢你创造了 React Native Skia，并把它带到了远超我们所有人想象的高度。你重新定义了 React Native 图形和动画的可能性，我们非常期待看到你接下来会把它带向何方。
Software Mansion
感谢你们为 Reanimated 所做的一切，感谢你们倾听我们的反馈，也感谢你们帮助我们解决应用中一些最棘手的动画和性能问题。
Shopify 工程师
数百位工程师为采用 React Native、迁移应用、构建共享基础能力、提升性能、维护集成和回馈生态作出了贡献。你们当中的许多人重新做起了初学者，挑战长期坚持的假设，在持续为商家和买家交付产品的同时，让转型取得成功。谢谢你们。
React Native 社区
感谢每一位使用我们的开源库、贡献代码、报告问题、质疑我们的决策，以及分享自身经验的人。你们的贡献和反馈，包括那些火药味十足的反馈，都让我们的工作变得更好。
过去六年里建立起来的工具、经验和关系，将继续影响我们在 Shopify 开发移动应用的方式。我们由衷感谢每一位参与其中的人。