Shopify 重返原生开发：AI 会如何改变 React Native

Shopify 从 React Native 转回原生移动开发，对它曾大力推动的生态系统而言是个重大变化。我多年来一直支持 React Native，最近也同时开发了 React Native 和原生应用。我想看看公司的理由、可能失去的优势，以及智能体改变了什么。

Shopify 表示，2020 年转向 React Native 是成功的：团队共享功能，让没有移动开发背景的开发者参与，并减少了保持平台同步的工作。公司仍认为它是出色的框架。新的问题是，编程智能体变强后，分别用 Swift 和 Kotlin 开发的成本是否已经改变。

我认为公司的解释更强调跨平台代码共享，而我看重的其他优势没有得到同等关注。Shopify 说，它在性能、框架基础和依赖升级上投入了大量精力，但此前收益仍大于成本。当基本假设发生变化后，公司重新审视了决定。

Shopify 用智能体重建了几个大型应用的核心部分。公司表示，智能体能够以一个平台为参考实现另一个平台的功能，也能帮助开发者在主要技术栈之外作出贡献。两个原生应用仍需分别维护；公司认为实现和保持功能一致的工作已不像以前那样具有决定性。

公司也看重更直接地使用平台能力和第一方工具。我不认为这能证明原生开发永远更好。不同团队的依赖、更新需求和专业经验不同，Shopify 的内部配置也是其特定决策的一部分。

这次转向也影响社区使用的库。Shopify 表示 React Native Skia 将由维护者以新名称迁往新的位置，过渡完成后归档旧仓库。公司计划继续修复 FlashList 的关键兼容性问题，同时讨论长期维护安排，并打算归档 Restyle。

对于大型应用，Shopify 比较了渐进迁移与从头重建。根据原型结果和重新开始的好处，公司选择了全新构建。公司报告说，Shop 从概念验证到重建后在 App Store 发布用了 12 周；另一个更大的 Shopify 应用迁移也在进行中。

Shopify 表示，直接让大语言模型一次性重建功能会产生难以维护的代码。它的 Helix 流程会为每个屏幕提出小型检查点。每个检查点都需要通过测试和视觉审查、接受两轮对抗性审查，并获得人工批准，才能进入下一步。

我不喜欢这个流程的某些部分，认为团队有时会过度重视现有实现。这是我的解释，并不是 Shopify 选择该方案的原因证据。公司的流程明确表明，使用智能体并不能省去验证行为和管理迁移风险。

公司发现，即使有热更新，模拟器交互仍然缓慢且容易出错。它描述了将业务逻辑与界面分离，并提供命令行接口，让智能体不必每次操作模拟器也能检查状态和执行行为。我认为这对他们的应用来说过度设计，但这只是针对特定方案的判断。

Shopify 感谢 Meta、Software Mansion 和其他贡献者对 React Native 的建设。生态系统的投入是这个框架能够发挥作用的原因之一。考虑平台价值，以及大型贡献者改变方向的影响时，这一点很重要。

我认为讨论低估了空中更新的价值。在 React Native 应用中，符合条件的 JavaScript 包可以在不替换原生二进制的情况下更新。这有助于团队向没有立即安装应用商店更新的用户交付兼容的修复。它不能改变原生代码，也仍受平台政策和兼容性要求约束。

假设一次界面改动在测试手机上正常，在较小屏幕上却被截断。原生修复可能需要重新构建、审核和发布，而用户仍在运行旧版本。我在 Twitch 观察到许多用户落后了几个版本；那是特定应用和时期的情况，不是普遍更新率。

我的类比是一间厨房：原生组件负责烹饪，JavaScript 层提供指令。替换兼容的指令可以改变行为，而不必换掉底层原生代码。这个类比简化了架构，但能解释我为什么重视这种分发灵活性。

我讨论了用更新交付小修复，或打开、关闭已有体验。商店政策决定了什么做法被允许；不是每项改动都能通过空中更新交付，原生依赖、二进制兼容性和用户更新行为仍然重要。团队应核对当前平台规则，不应假定所有功能都能绕过审核。

Expo 为 React Native 提供构建、更新和开发工具。我把它比作让框架更易使用的平台。视频中关于 Shopify 采用 Expo 程度的讨论来自文章和对话中的推断，并非我对其内部情况的全面确认。

我的原生 iOS 开发配置需要为某些功能处理签名和权限。我维护单独的配置，以便测试基本界面改动时不必复制所有授权步骤。使用合适的预构建 React Native 开发客户端，队友可以更容易迭代 JavaScript；但修改原生代码仍需要相应构建。

我也重视 Expo 的模拟器和 Web 支持，它们可以帮助智能体完成部分迭代。Web 构建有助于测试共享逻辑和界面，但不能替代在目标设备上测试平台特有行为。我认为 Shopify 可能没有获得其中一些好处，但它的需求和集成成本也可能不同。

React Native 确实有缺点。包含原生组件的依赖可能带来棘手的构建和链接问题，尤其涉及多个平台工具时。我对打包和升级可能出错的方式感到沮丧，即使 JavaScript 部分看起来很简单也一样。

人们经常提到应用大小。在我讨论的 Shopify 例子中，重建的原生应用并没有明显缩小；但单次比较不能证明应用大小在所有场景都无关紧要。资源、国际化、依赖以及重写本身都可能影响结果。

编程时也有容易踩到的坑。处理不当的副作用或渲染会损害移动体验，框架对新手友好也不保证应用质量。我在视频中对开发者平均水平作了宽泛判断；那是个人观点，没有数据支持。

React Native 的架构变化和依赖升级可能造成干扰，尤其是应用包含大量自定义原生集成时。我讲述了自己升级困难的经历。依赖 Meta 或某个库暴露新平台功能，也可能让使用新功能变慢，不过团队可以自行编写原生集成。

我不认为整体性能必然是 React Native 的弱点。后台执行是一个确实受平台限制的例子：iOS 应用休眠时 JavaScript 可能不再运行，因此某些工作需要原生支持，并且仍须遵守操作系统限制。框架与原生代码可以共存。

Shopify 表示，探索原生开发时恰好面临 React Native 新架构的重大投入。团队需要权衡将现有原生集成迁移到新架构，还是直接原生重写。我认为有必要在匹配条件下比较旧架构、新架构和原生实现。

新架构改善了 JavaScript 与原生组件的交互，也带来了布局等方面的改进。我预计这可能改变性能比较结果，但视频没有提供受控的三方基准。Shopify 的迁移负担和应用特有需求同样重要。

接下来我讨论一项关于 Shopify 首席执行官 Tobi Lütke 如何作技术决策的公开指控。这是有争议的说法，我没有通过亲身经历证实。Lütke 回应说，所举的内部工具案例涉及过于复杂的架构，团队有时也会请他作出艰难决定。

我同意，小型内部工具可能被不必要的层次拖累。不过在 Twitch，我们也有理由让内部系统和公开系统共享技术，包括方便工程师流动和试验想法。合适的架构取决于团队和工作，而不是单一规则。

Lütke 说，他通过内部播客解释决策，帮助大家学习背后的推理。读完回应后，我更能理解领导者帮助团队作出艰难决定的做法。他的回应对原指控的部分细节提出异议；这里没有独立核实双方说法。

我自己的原生实验开始时，手头有模型访问权限和剩余额度，但时间不多。T3 Code 已经有 React Native 移动应用。我让智能体构建原生版本，大约两小时后看到能运行的原型，感到很惊讶。

后来我用计算机操作和不同配置重复实验。我误说了适用于 macOS 的 AppKit；一次运行推断我指的是 UIKit，另一次却生成了 SwiftUI。根据我的记录，最终得到两个 iOS 原型，与 React Native 应用并存，每个都在三小时内生成。

在我看来，原生构建在某些导航和后台数据场景中感觉更好，但 SwiftUI 列表更糟。这只是我对自己应用早期实现的观察，不能证明任何框架在所有场景都更快。React Native 版本也有很出色的滚动实现。

导航经历暴露了一个重要的可用性细节。我从左边缘滑动返回，而有些队友从更靠近中间的位置开始。我们的 React Native 应用里，残留的抽屉手势拦截了边缘的一小块区域，因此不同的人遇到的行为不同。我们发现并移除了这个问题。

SwiftUI 版本则有另一种问题：在我的配置中，默认导航手势没有覆盖一位测试者预期的区域。我说在部分系统内置应用中看到更宽的滑动范围，最后重建了导航，以支持用户尝试的手势。我的经历不能证明所有版本的平台 API 行为都相同。

AI 让实现改动更容易，却不能代替发现和理解交互问题的工作。我花了时间观察不同手势，并请另一个人测试。使用平台原生组件，并不能自动保证应用符合每位用户的预期。

我的经验是，给智能体源码、模拟器和现有实现，它常常能生成有用的迁移版本，并在收到反馈后修复问题。我推测 Shopify 的不同经历可能与模型或工具选择有关，但我不知道它内部的实际原因。我的应用也比 Shop 简单。

我展示了一个持续维护的 SwiftUI 分支，智能体根据 React Native 应用的改动更新它，并报告迁移了多个功能、使用了模拟器。我本人使用这个版本，但没有审查每一行代码；一次成功的个人工作流不能证明所有应用都有同样的可维护性或功能一致性。

我还讨论了 Legend List，我们的团队用它在 React Native 和 Web 上处理长列表。它的 JavaScript 实现使 Web 版本成为可能，根据我们的经验表现不错。库作者对基准的正面评价仍应放到实际应用和工作负载中检验。

React Native 需要大量工作，才能通过面向 JavaScript 的接口暴露平台功能。我赞赏构建这些集成的原生工程师，并认为团队从他们的专业能力中受益。我对历史团队规模的估计来自个人了解，视频没有核实人员数字。

我认为编程智能体可以缩小一部分专业能力差距，而这种差距曾促使团队选择共享框架。但这不会消除 React Native 开发流程、更新机制或成熟库的价值；智能体生成的原生应用仍需要维护和审查。

我对 Meta 在 React 和 React Native 方面的投入及人员变化表示担忧，提到了人员离开和自己对组织的了解。视频没有证明团队当前的完整人数、计划或质量。我对未来维护可能变慢的预测属于推测，而非已确认的结果。

我把 Shopify 的转向看作值得观察的实验，正如 React Native 曾经是对移动开发另一种方式的重大押注。公司的决定反映它自己的工具、人员和优先事项。其他团队应借此检查自己的假设，而不是自动照搬选择。

在我看来，React Native 从来不只是“一次编写，到处运行”。熟悉 React 可以帮助团队学习并跨平台工作，但理解移动端行为仍然重要。无论应用使用原生还是跨平台技术，都应在 iOS 和 Android 上测试，并关注真实用户如何操作。