Shopify 为何放弃 React Native 转向原生开发
Why has Shopify dropped React Native?
Shopify 宣布原生开发成为其移动端未来方向，将用 AI 把全部移动应用迁移到 Swift 和 Kotlin，其中 Shop 应用已在 12 周内完成原生重写。
开始之前：鉴于本文讨论的是原生移动开发，我想向所有读者免费提供我 2021 年的电子书《大规模构建移动应用：39 个工程挑战》（免费获取）（原价 20 美元）。这本书对于大规模移动应用需要解决的挑战依然具有现实意义，并列举了本文下面涵盖的技术，包括 Kotlin Multiplatform。
此优惠有效期至 10 月 2 日星期五。结账时，只需选择“The ebook: PDF & EPUB versions of the book.”。无需信用卡！欢迎将此链接分享给构建或从事移动应用的同事。
最近，Shopify 投下了一枚重磅炸弹，宣布原生开发现在是该电商平台移动开发的未来。这在移动开发社区引发了大量反响，其规模堪比六年前 Shopify 最初转向 React Native 时引发的轰动。
但时代已经变了，我们都知道这次的变革推手：AI 智能体！最新一代模型在编码能力上的提升，已经让 Shopify 不再满足于 React Native（RN），就像它去年那样。
本文探讨了这一切是如何发生的、Shopify 为何做出这一改变，以及更广泛的移动生态系统。我们涵盖：
Shopify 为何在 2020 年选择 React Native。首先，Android 应用的构建耗时过长，而且拥有一致的 iOS 和 Android 应用是件好事。
五年后依然满意。Shopify 将全部六款应用迁移到了 RN，大多数事情进展顺利，2020 年的这一举措被视为明智之举。
为何现在放弃 React Native？AI 现在非常擅长编写移动端代码以及后端代码，而 React Native 增加了原生所没有的抽象层。Shopify 仅用 12 周（！！）就将 Shop 应用重写为原生。来自 Shopify 移动团队的更多细节。
我们以前不是见过这种反复吗？Airbnb 做过类似的事情：2016 年采用 React Native，两年后又迁回原生。根本原因相同：性能。
自 2019 年起转向原生。迁移到原生过去需要很长时间，Notion 已经做了七年。当 Notion 完成这一过程时，一个合理的问题是：原生编辑器是否真的会拖慢他们的 Web 迭代速度，无论有没有 AI。
Kotlin Multiplatform（KMP）也想说两句。KMP 允许用 Kotlin 编写业务逻辑，并在 iOS 和 Android 之间共享，同时每个平台保持原生。这是一项感觉很有前景的技术，并且可能随着 AI 变得更受欢迎。
接下来是什么？编写原生 iOS 和 Android 应用比以前更容易了，但 React、Flutter 和 KMP 应用也是如此。
1. Shopify 为何在 2020 年选择 React Native
让我们回到 2020 年，当时 Shopify 决定全力投入 React Native（RN）。那时，移动端是该平台非常重要的渠道，十分之七的客户在移动设备上使用它。作为工程负责人，Farhan Thawar 当时写道：
“每个季度，大多数买家通过移动端购买（去年第三季度[2019年]，我们71%的买家通过移动端购买）。黑色星期五和网络星期一（合称BFCM）是我们商家一年中最繁忙的时期，这些天的购买活动是一个风向标。在今年的BFCM期间，Shopify商家的移动端购买量又增加了3%，平均占销售额的69%。”
移动端如此重要，难怪该公司为iOS和Android构建了原生移动应用；毕竟，原生移动端可以完全控制平台的能力、集成和性能，那为什么还要费心使用跨平台技术呢？
事实证明，原因之一是Android原生应用的发布延迟，Shopify和其他公司一样都在此挣扎。
当Android需要一年以上才能发布时：Clubhouse的失败
在本十年初的疫情期间，实时对话应用Clubhouse在2020年3月推出后大受欢迎。该应用在最初14个月仅支持iOS，因为团队无法发布Android版本。到了年底，使用量彻底爆发：
尽管如此受欢迎，Clubhouse当时在Android上却无法使用！
花了14个月才在Android上推出Clubhouse的测试版，等到2021年5月推出时，该平台已在几个月前过了巅峰期，使用量当时呈下降趋势。直到2021年7月才在全球推出Android版Clubhouse应用——比iOS版晚了16个月——此时已错过增长浪潮，这对这个前景光明的企业来说意味着厄运。
这是怎么发生的？有几个主要原因：
为Android做好开发比iOS更复杂：需要支持更多设备类型，以及支持使用不同API的更旧操作系统版本。
在低端Android手机上获得良好性能很困难。
我还怀疑Clubhouse的团队是在为一个从未实现的规模进行工程开发。也许他们试图构建一个“完美”的应用以在全球发布，但错过了增长浪潮，这意味着该应用最终与一个本可以更早发布、更及时地有利于业务的版本相比，显得“过度工程化”。
从零开始构建原生Android应用——即使有现成的iOS应用作为蓝图——在2010年代和2020年代初也是一项挑战。Clubhouse是一个企业出错的极端案例，部分原因是Android发布迟缓。
但客户习惯可能也起了作用：当时，大多数美国初创公司优先考虑iOS应用和功能，因为在美国，最有价值的用户越来越多地出现在iOS上。对于主要客户在美国的公司来说，优先考虑iOS具有商业意义，但对于业务遍布全球的公司来说则不然，因为亚洲等地区的智能手机用户主要使用Android。
React Native帮助Shopify更快地添加了Android支持
Shopify对React Native的首次积极体验是在2018年，当时是Shop app（当时叫‘Arrive’）。该公司总结道（强调为我所加）：
“2018 年底，我们决定用 React Native 重写我们最受欢迎的消费者应用之一 Arrive（现为 Shop 应用）。Arrive 可不容小觑；它是一款评分很高、性能出色的应用，在 iOS 上拥有数百万次下载。它是一个很好的候选，因为我们没有 Android 版本。我们的努力将帮助我们触达所有渴望使用 Arrive 的 Android 用户。现在它在 iOS 和 Android 上都是 React Native，并共享 95% 的相同代码。我们将在未来的博客文章中深入探讨 Arrive。
到目前为止，这次重写带来了：
iOS 上的崩溃比我们的原生 iOS 应用更少
推出了 Android 版本
一个由移动端 + 非移动端开发者组成的团队。”
转向 React Native 是加速推出新应用 Android 版本的最简单方法之一。2020 年，当 Shopify 宣布这一举措时，这就是其声明的意图：
“我们广受欢迎的 Shopify Ping 应用（现称为 Shopify Inbox）已支持数十万次客户对话，目前仅支持 iOS。2020 年，我们将在旧金山办公室使用 React Native 构建 Android 版本，并且我们正在招聘。”
2. 五年后依然满意
去年，Shopify 在一篇回顾文章《React Native 五年》中宣称对转向 RN 感到满意。这份总结堪称一场胜利巡礼：
“回顾一下，我们决定转向 RN 有三个主要原因：
一次编写 - 不再为同一功能构建两次，一次在 iOS 上，一次在 Android 上
人才可移植性 - 让开发者能够在 iOS、Android 和 Web 之间流畅工作
交付更多价值 - 花更多时间向用户交付价值，而不是追求功能对等
我们很高兴地分享，我们的过渡相当成功：
不必两次构建相同的功能，让我们的生产力有了阶跃式提升
工程师能够跨 Web 和移动端工作，使团队能够以相同的人数做更多事情，并解锁了新的增长机会
保持 iOS 和 Android 之间的功能对等已不再是问题，释放了交付更多价值的能力
我们的应用速度极快（屏幕加载 <500ms）且稳定（无崩溃会话 >99.9%）
我们继续在原生是最佳工具的地方利用原生，让我们兼得两者之长
在过去 5 年里，我们已将我们所有的应用迁移到 React Native。我们没有采用一刀切的方法，而是由每个团队选择何时以及如何迁移他们的应用。这使他们能够继续交付功能，同时与我们的 RN 利用战略保持一致。”
他们没有开玩笑：五年内，六个移动应用被迁移到 React Native：
Shopify 的工程团队表示他们很喜欢 React Native 的许多方面。Mustafa 解释道：
“速度。RN 应用很快。我们在 Shopify 应用中实现了低于 500ms（P75）的屏幕加载。我们在所有应用中都实现了类似的性能。就像原生一样，你必须应用良好的模式和技术来消除性能瓶颈。
热重载。这是我们使用原生时最大的痛点之一。鉴于我们代码库的规模，即使是最微不足道的更改，也需要几分钟才能在模拟器/物理设备上编译和运行。这浪费时间并打断开发者的心流。React Native 的热重载完全消除了这个问题。”
TypeScript 作为开发者的“共享”语言非常出色。 TypeScript 已经无处不在，我们也看到开发者在 React Web 和 React Native 之间转换取得了巨大成功。”
也出现了一些新的挑战：
调试更差： “React Native 中的调试不稳定，在 VS Code 中正确配置需要一些功夫。另一方面，iOS 和 Android 拥有强大的调试能力，开箱即用”
原生代码和原生开发者仍然重要。对于性能密集型代码、某些动画、长时间运行的后台任务和专用 API（如主屏幕小组件），你需要原生代码。
更多第三方库。 “React Native 框架与原生相比不够全面，因此你最终不得不使用更多第三方库。”
但科技界的变化能有多快……
3. 为什么现在要放弃 React Native？
本月 Shopify 宣布 Native 现在是 Shopify 移动端的未来，这意味着 RN 突然成为历史，这引起了广泛惊讶。
来自移动端负责人 Mustafa Ali（强调为我所加）：
“2025 年 1 月，我写道 React Native 的未来是光明的，Shopify 计划继续投资它。基于我们当时所知，那是真的。React Native 对我们运行良好，它仍然是一个优秀的框架。但自那以后，编码模型已经大幅进步，对于我们的应用和团队来说，用 Swift 和 Kotlin 构建相同的功能不再像过去那样带来成本。
原生仍然意味着在两个平台上构建和维护软件，这一成本并未消失。改变的是，智能体现在可以完成足够多的实现、翻译、测试和审查工作，使其不再是 2020 年那样的决定性因素。
React Native 应用可以很快。我们的就是。我们做出这一改变是因为智能体降低了共享实现优势，而针对每个平台构建的优势依然存在。原生让我们更接近平台能力和第一方工具，我们的代码与平台之间的框架和依赖层更少。”
当然，选择原生而非跨平台一直都有利弊。在 AI 之前，情况是这样的：
改变的是，AI 编码智能体现在在生成 iOS 和 Android 代码方面能力更强了。
React Native 如何渲染元素——回顾
毫无疑问，完全原生的应用构建良好，并且总是比基于 React Native 等跨平台解释器构建的应用更高效。尽管如此，RN 已经取得了长足进步，性能大幅提升——在 RN 代码和原生代码之间多了一个抽象层——尤其是自 2024 年的 新架构 以来。让我们可视化它的工作原理：
React Native 的核心哲学是尽量减少 UI 上使用昂贵渲染操作的更新。因此，RN 维护屏幕上视觉元素的 React 宿主树（可以理解为“逻辑树”），它转换为 宿主视图树，即在 iOS 和 Android 上的表示。React 本身巧妙地最小化重新渲染操作，从而节省计算资源。
为什么原生应用在性能上必然胜出
如上所述，一个编写良好的原生应用自然比 React Native 版本表现更优。要理解其中原因，最简单的方法是勾勒出原生应用渲染时发生的情况，并与 React Native 进行对比：
React Native 理论上可能性能更高，但前提是原生版本的结构编写不佳，或者 UIKit / Jetpack Compose 或任何其他原生库效率低到足以让这种情况发生——而这不太可能！但原生拥有的抽象层要少得多。
自从 Shopify 转向原生以来，一个常见的问题是，为什么 Shop 应用没有迁移到新架构以改善启动性能等方面。我就此联系了移动负责人 Mustafa Ali。他告诉我：
“我们实际上已经把其他大型 Shopify 应用迁移到了新架构。Shopify 和 Point of Sale 都已迁移，我相信我们是 Meta 之外最早这样做的大型团队之一。
这次迁移带来了一些性能提升，但幅度不大。Android 上的应用启动速度提高了约 10%，iOS 上提高了 3%，而一些复杂屏幕在调优之前实际上变得更慢了。”
该团队已经详细撰文介绍了迁移到新架构的过程。尽管如此，使用原生代码提供了更多提升性能的机会；毕竟，你现在可以控制完整的渲染栈！你甚至还可以抛弃 Apple 构建的系统库，如 UIKit 或 ComposeKit，并构建性能更高的替代品。Shopify 不打算走到这一步，但工程负责人 Farhan Thawar 告诉我，他们预期会获得性能提升：
“我认为这些原生应用能变得多好，我们才刚刚起步。我预计随着我们在迁移后逐步梳理代码库，它们会变得更快——比如启动时间更短、交互更灵敏。”
一名工程师，借助 AI 覆盖两个平台
React Native 的一个好处是，不必同时拥有 iOS 工程师和 Android 工程师。但有了 AI，一名工程师就能为两个平台构建软件，Mustafa Ali 告诉我：
“过去转向 RN 的一个文化好处是，我们不像大多数原生团队那样，有独立的 iOS 和 Android 团队。
我们只有一个团队，同一名开发者在 iOS 和 Android 上构建同一个功能。这让上下文保持在一处，没有沟通开销。
随着 LLM 让在你主要专业领域之外贡献代码变得容易，我预计这在未来几个月会变得更加普遍。”
Farhan 说得更简单：
“基本上，作为共享语言的 React，现在被英语取代了，这要归功于 LLM。”
借助 AI，共享代码库变得更简单
转向原生的另一个缺点是，需要维护两个代码库，它们在行为、功能和缺陷上往往会出现分歧。但有了 AI，Shopify 不再认为这是个大问题。Mustafa：
“在 LLM 出现之前，维护两个独立的代码库是件大事，但现在不是了。
智能体非常擅长将功能从 Android 移植到 iOS，或者反过来。 它们也很擅长长期比较两种实现。它们能发现代码中的差距，并通过并排测试来修复它们。”
Shopify 还在构建一个共享的验证测试套件，以验证两个应用完全一致。同样，来自 Mustafa：
“我们现在有一个共享测试套件，用于验证用 Swift 和 Kotlin 实现的业务逻辑。这意味着一个功能必须通过两个平台上完全相同的测试才能发布。该逻辑在桌面端无头运行，这为智能体提供了非常快速的反馈循环来进行迭代。”
聪明！这也印证了我的感觉：验证代码对于与智能体协作正变得非常重要，构建专门的验证层也是如此。
React Native 与原生开发如今的对比
让我们回到对比表，并根据原生 + AI 如何改变 Shopify 的处境来更新它：
我个人的感觉是，随着 AI 工具变得如此出色，原生开发的缺点正在消失，而 Shopify 现在完全掌控其原生应用的性能和架构。
随着决定借助 AI 全力投入原生开发，这家电商企业正承诺迁移其所有应用。有了 AI，这应该比当年迁移到 React Native 更快。Mustafa 再次表示：
“我们将把所有的移动应用迁移到 Swift 和 Kotlin，并在整个过程中使用 AI。
Shop 已在短短 12 周内作为完全原生应用发布，Shopify 应用正在进行中，其余的也将很快跟进。我们行动迅速，但不会降低标准。
每一次重建都必须达到或超越人们今天所期望的性能、稳定性、无障碍性和产品质量。这不仅仅是用不同语言重写同样的应用。我们正在重建它们，以便人类和智能体都能快速理解、测试和修改它们。”
祝团队在这次迁移中好运！我很期待听到他们从这一举措中学到了什么。
4. 我们以前不是见过这种反复吗？
来源：The Pragmatic Engineer · newsletter.pragmaticengineer.com