Shopify 原生移动端回归，AI 改变了权衡

Shopify 正在以原生移动端开发取代 React Native，结束实施六年的战略，因为编程智能体改变了维护两套应用的成本。Shopify 将使用 Swift 开发 iOS 软件，并使用 Kotlin 开发 Android 软件。该公司表示，智能体如今已能承担足够多的翻译、测试和审查工作，使维护独立代码库变得可行。

这一决定挑战了跨平台开发最具吸引力的承诺之一。React Native 让团队能够在 iOS 和 Android 之间共享应用的大部分实现。Shopify 采用这一模式，是为了避免重复开发功能，让 Web 开发者也能参与，并保持两个平台的一致性。

Shopify 并未宣称 React Native 速度慢或不成功。它表示，该框架实现了其在 2020 年移动端决策中所承诺的收益。这次转向基于另一项判断：AI 已降低共享实现所节省的人力成本，而原生软件仍能更直接地接入各个平台。

这一差异的重要性不止于 Shopify。如果编程智能体让并行实现变得负担得起，工程团队就必须重新审视衡量代码复用的方式。有价值的共享层可能会从源代码转移到规范、测试、设计系统和审查流程之中。

Shopify 原生移动端取代成功的 React Native 战略

Shopify 正在淘汰一套成功的架构，因为支撑它的经济假设已经改变。

该公司于 2026 年 9 月 10 日宣布重返原生开发。其主要移动产品包括 Shop、Shopify、Point of Sale 和 Inbox。Shopify 表示，数百万商家和买家依赖这些应用。

该公司在 2020 年全面押注 React Native。React Native 是 Meta 推出的框架，可使用 JavaScript 和原生平台组件构建 iOS 与 Android 界面。Shopify 希望采用统一技术栈，减少在两个操作系统之间重复开发的工作。

早期成果支持了这一决定。该公司称，后来的 Shop 应用 Arrive 实现了 95% 的代码共享，Compass 则达到 99%。还有一个团队在使用 React Native 重写 Arrive 后，感到生产效率提高了一倍。

随后，Shopify 将其最大的商家应用逐步迁移至该框架。这款产品在每个平台上都拥有超过 300 个页面。与为彻底重写而停止功能开发相比，渐进式迁移最初看起来更为稳妥。

这一战略需要大量组织投入。Shopify 通过内部 React Native 项目培训原生开发者，打造共享基础设施，并向更广泛的生态系统贡献库。当仍需开展平台特定工作时，它还建立了将原生代码与 React Native 混合使用的流程。

截至 2025 年 1 月，Shopify 仍称 React Native 的前景光明。其五年回顾赞扬了 Meta 的维护工作，并承诺继续投资共享基础设施。它还推广了一个重新启动的工作组，面向使用该框架的企业。

因此，这项新公告代表着一次真正的转向，而非对失败实验的迟来否定。Shopify 表示，React Native 节省了时间，扩大了可参与开发的人群，并减少了追赶功能一致性所需的投入。

不过，这些收益也伴随着持续成本。团队需要优化性能、维护基础组件、跟进框架变化并管理外部依赖。在共享实现能消除大量重复工作时，Shopify 认为这些成本可以接受。

编程智能体改变了这一计算。Shopify 表示，自 2021 年起便开始将大语言模型用于软件开发。早期用途包括实现功能、调查 Bug、修复问题和审查代码。

到 2025 年末，该公司已开始信任智能体处理更复杂的工作。团队开始测试 iOS 实现能否指导 Android 实现，以及反向流程是否同样有效。这些原型促使 Shopify 转向独立的 Swift 和 Kotlin 应用。

该公司的新原生战略仍承认核心劣势：原生开发要求团队将软件构建和维护两遍。Shopify 表示，AI 已减轻了这一负担，但尚未将其完全消除。

这一举措意义重大，因为 Shopify 曾为大规模 React Native 应用提供了异常有力的证据。它并非仅在一个小功能上使用该框架，而是迁移大型应用、培训团队、建设基础设施、赞助维护者，并发布可复用的库。

如今，同一家公司认为，实现复用已不应再占据同等权重。这正是本文的核心张力。Shopify 的 React Native 迁移历史表明该框架确实有效，而 Shopify 的智能体则削弱了继续保留它的商业理由。

编程智能体让跨平台团队面临压力

直接压力落在那些将共享代码视为移动端效率主要衡量指标的组织身上。

跨平台框架结合了两类杠杆。它们让开发者只需表达一次行为，也让企业能够围绕更少的语言和工具组织移动端工作。这两种优势既能减少编码时间，也能降低协调成本。

Shopify 的论点直接削弱了第一项优势。智能体可以检查已有的 iOS 功能，生成相应的 Android 实现，并协助验证行为一致性。源代码虽不相同，但大量人力投入已不再需要手工重复。

这使关注点转向第二项优势。独立平台仍需要不同的构建系统、依赖项、发布流程、测试环境和专业判断。智能体可以协助完成这些任务，但团队仍须对每一个发布结果负责。

框架维护者如今面临更复杂的价值主张。当软件翻译成本低廉时，“一次编写”就不再那么有说服力。跨平台工具必须通过可靠性、迭代速度、团队流动性、生态系统质量和降低协调开销来证明价值。

移动端工程负责人则面临来自另一方向的压力。高管可能将 Shopify 的 Swift 和 Kotlin 开发解读为：每家公司都可以放弃共享代码库。这个结论会忽视 Shopify 围绕智能体构建的系统。

Shopify 并未要求一个模型一次性重建整个应用。它建立了结构化工作流、审查检查点、测试工具和架构约束。经验丰富的工程师仍负责需求、平台决策和生产质量。

这次迁移还以一个特别有利的输入为起点：一款正常运行的 React Native 产品。该应用充当了页面、交互、导航、分析和数据行为的可执行规范。智能体是在翻译已定义的行为，而不是从头构想整个产品。

这一差异让文档欠缺的应用承受更大压力。AI 生成的移植依赖清晰的参考行为和可观察的结果。模糊的遗留系统会让智能体有更多机会复现 Bug、遗漏边缘情况，或生成不兼容的模式。

开发者同样受到影响。React Native 曾让具备 Web 经验的人也能开发移动端功能，从而扩大 Shopify 的贡献者群体。原生代码传统上更看重 Swift、Kotlin、iOS 和 Android 等专业知识。

Shopify 表示，智能体如今可帮助工程师在主要技术栈之外参与开发。熟悉的声明式界面模式，也让 React Native 开发者更容易学习 SwiftUI 和 Jetpack Compose。SwiftUI 和 Jetpack Compose 分别是 Apple 和 Google 通过应用状态定义界面的现代框架。

这并不意味着平台专业能力变得可有可无。原生工程师仍然理解生命周期行为、无障碍访问、内存、后台处理、平台惯例和发布限制。生成的代码看似正确，却可能造成架构漂移或细微的性能问题。

必要的应对并不一定是迁移框架。团队如今需要重新计算共享代码究竟在哪些方面带来了真实节省。他们还需要证据证明，智能体能否在自身环境中维持两套实现的质量。

对于 React Native 团队而言，最有力的回应将是运营层面的，而非意识形态层面的。他们可以衡量更新工作量、依赖维护、崩溃率、启动速度、构建时间和平台特定例外情况。这些指标能揭示共享实现是否仍值得其抽象层成本。

对于原生团队而言，Shopify 的结果提高了证明 AI 生产力的标准。仅有代码补全并不足够。可信的智能体工作流必须保留分析、无障碍访问、导航、测试、发布安全性和一致的产品行为。

因此，长期压力将指向两个阵营。跨平台倡导者必须量化代码复用之外的收益。原生倡导者则必须证明，在迁移热潮过去后，智能体辅助的重复实现仍然可维护。

这次转向关乎复用，而非 React Native 性能

Shopify 的决定将代码复用与产品一致性区分开来，将它们视为不同的工程问题。

React Native 在历史上将这两个目标联系在一起。共享组件或功能通常会在各个平台上表现相似，因为两个应用执行了大部分相同的实现。这种关系减少了平台版本可能产生差异的范围。

Shopify 的新模式在放弃共享界面代码的同时保留一致性。团队将使用共同的规范、测试、设计规则、分析契约和审查检查点。随后，智能体会利用各平台的原生框架实现相同的预期行为。

这比切换编程语言更深层。该公司正在将事实来源上移。它不再将共享代码视为主要产品契约，而是将经过审查的意图和可观察的行为视为契约。

这种方法保留了多项原生优势。开发者可以在 Apple 和 Google 发布第一方 API 时直接使用它们。他们可以遵循平台惯例，而无需协商共享抽象。他们还移除了应用与操作系统之间的框架和依赖层。

这一变化发生时，Shop 正面临另一项重大的 React Native 投入。该应用需要采用框架的新架构，该架构改变了渲染、原生模块集成，以及共享代码与平台特定代码之间的边界。

在进行这项投入前，Shopify 测试了使用 SwiftUI 和 Jetpack Compose 进行直接开发。一名工程师花了一周时间使用编程智能体，将尽可能多的 Shop 内容迁移到原生 iOS 原型中。

该原型尚未达到生产就绪状态。不过，它复现了足够多的页面、交互和应用流程，使完整迁移看起来可以实现。智能体在能够基于已定义功能和可见行为开展工作时表现最佳。

随后，一个由六名工程师组成的核心团队构建了原生基础能力和 Shop 的主要用户流程。功能团队在中途加入，以验证各自负责的领域并处理边缘情况。Shopify 在 12 周内将项目从概念验证推进到应用商店中的原生应用。

这些数字解释了为何这次转向变得可信。传统的绿地重写，即不沿用既有架构、从头构建的新实现，可能耗费数年。它也可能冻结产品开发，并带来长期的功能一致性问题。

Shopify 曾在相反方向上经历过这一挑战。此前逐步迁移至 React Native 的过程中，公司曾一度同时维护三套架构：iOS、Android 和 React Native。2022 年的一份说明称，按最初的节奏，迁移将需要四到五年。

Shopify 选择以绿地方式回归原生开发。该公司表示，编程智能体可以将现有 React Native 应用作为参考，而全新的代码库则摆脱了旧有架构的限制。原型表明，应用可以比过去快得多地完成重建。

Shop 的成果也提供了性能方面的证据。Shopify 报告称，原生 iOS 应用达到首页可见内容的时间为 2,466 毫秒，而此前为 3,200 毫秒。这意味着启动时间缩短了 23%。

在 Android 上，启动时间从 4,433 毫秒降至 2,233 毫秒，降幅为 50%。Android 发布版本的体积也从 293 MB 缩小至 184 MB，而 iOS 构建体积则从 67 MB 增至 68 MB。

Android 发布版本的构建时间下降约 75%。Shopify 还展示了原生 Android 应用在 Pixel 设备上滚动信息流和导航时达到每秒 120 帧。

会话稳定性从历史上的至少 99.5% 提升至原生版本发布后的至少 99.95%。Shopify 将这一变化描述为崩溃会话数量减少了十倍。

这些是公司自行报告的对比数据，而非独立基准测试。此次迁移还包括产品简化，一些页面被下线，另一些则被精简。因此，很难将每一项改进都完全归因于原生技术。

Shopify 自身也避免作出这种断言。它明确表示，其 React Native 应用运行速度很快，React Native 仍然是一个出色的框架。其核心论点在于：当智能体降低重复劳动后，共享实现的相对价值发生了变化。

这一差异避免得出“React Native 对阵原生”的误导性结论。Shopify 并非在为所有应用提供通用基准。它报告的是，其团队、工具、架构和产品规模如今更适合另一种平衡方式。

Helix 说明这次迁移不只是代码生成

Shopify 通过将迁移转化为受控验证循环，使原生开发中的重复工作变得可控。

该公司发现，一次性转换会产生过多难以维护的代码。即使在前期给出详细规格，也无法让整套自动化重写变得可靠。输出结果可能看似完整，却暗藏不一致的模式和缺失的行为。

Shopify 创建了 Helix，将迁移工作拆分为多个小型检查点。开发者将系统指向某个页面后，Helix 会读取 React Native 实现，随后提出一套按顺序执行、可供人工快速审核的工作步骤。

每个检查点都必须通过测试展示其行为。它还需要经过视觉对比、两次对抗式代码审查和人工批准，才能进入下一个检查点。反馈会被保留，使该工作流随着时间推移变得更加自主。

这一机制比原始生成速度更重要。当错误累积的速度超过审查者理解它们的速度时，软件迁移就会失败。小型且被接受的单元，限制了进入新应用而尚未验证的行为数量。

Shopify 还在独立工作树中运行了多个智能体会话。专门的子智能体检查现有代码、记录行为、准备平台计划、实现功能，并审查一致性。工程师会在开发推进前批准需求和实现计划。

计划批准与已审核内容的哈希值绑定。如果计划发生变化，原先的批准就会失效。这一设计降低了智能体在获准后悄然执行不同计划的可能性。

该工作流审查的不只是可见的界面元素。Shopify 表示，其源代码审查覆盖了状态、导航、分析、无障碍功能和数据行为。这些领域往往包含最棘手的迁移失败，因为仅凭截图无法揭示它们。

分析数据的保留尤为重要。推荐系统和其他下游系统依赖预期的事件及上下文字段。即使应用在视觉上正确，若事件名称、数量或载荷关系发生变化，仍可能损害决策系统。

Shopify 开发了另一款工具 Tardis，用结构化形式暴露实时应用事件、日志和状态。智能体可以向应用发送命令、调查问题、检查导航，并以更少的手动交互验证修复结果。

在一致性审查中，Tardis 会从 React Native 和原生应用中捕获命名检查点处的截图和事件窗口。智能体会对比事件字段，同时考虑时间戳和唯一页面标识符等合理差异。

该架构也解决了模拟器延迟问题。移动端智能体通常依赖无障碍树或截图来理解界面状态。它们可以在数秒内修改代码，随后却要花数分钟通过模拟器构建和测试。

Shopify 发现，这种缓慢循环需要频繁的人工看护。React Native 的热模块重载改善了迭代效率，但并未消除模拟器瓶颈。当反馈依然缓慢且脆弱时，模型能力的价值有限。

该公司通过将业务逻辑与界面分离来应对这一问题。无头业务逻辑可以在不显示应用的情况下运行。Shopify 通过命令行界面暴露这部分逻辑，让智能体能在桌面端以毫秒级速度执行它。

这就是 Shopify 原生移动开发背后的机制。智能体并非只是用生成代码取代六名工程师。Shopify 围绕机器参与重新设计了应用架构、反馈系统、审查关卡和测试访问方式。

这项工作改变了表面上的经济性。维护两套实现之所以成本更低，部分原因在于组织投入建设了一套共享验证系统。共同资产不再是界面代码，而是描述和检查预期行为的机制。

这一模式也类似于团队如何构建可搜索的技术决策记录。规格、计划、审查发现和测试结果都会成为可复用的上下文。一个工程知识库可以帮助人们跨文档追溯这些决策，尽管它无法替代仓库级测试。

这种方法更适合拥有成熟基础设施的大型组织。Shopify 可以创建定制工具、维护广泛的自动化检查，并安排经验丰富的工程师负责架构与审查。规模较小的团队可能更能从通过共享代码提供协作能力的框架中获益。

因此，真正的竞争在于共享实现与共享意图。React Native 通过可复用源代码直接编码一致性。Shopify 的新流程则通过规格、可观测性工具、测试和受控转换来编码一致性。

Shopify 的成果并未终结 React Native 与原生开发之争

一次成功的 12 周重写，并不能证明两套原生代码库在整个生命周期内始终成本更低。

迁移速度只是最初的衡量指标。更艰难的考验会在两个应用开始独立演进后到来。新功能、操作系统变化、紧急修复和人员流动，将揭示智能体能否让两套实现保持一致。

功能一致性仍是一项明确要求。Shopify 表示，Android 和 iOS 必须始终保持一致。此前，共享的 React Native 代码在结构上保证了这一条件的大部分实现。新流程必须通过开发与发布控制来确保这一点。

这会引入多种失效模式。智能体可能实现等效行为，却采用不兼容的架构模式。它可能将 iOS 的假设复制到 Android，或因参考应用本身包含该问题而保留旧有 bug。

生成的代码也可能在通过测试的同时增加重复逻辑或技术债务。Shopify 承认存在架构漂移、重复逻辑和性能问题等风险。仓库指南、代码检查、静态分析、性能检查和人工审查仍然必不可少。

因此，原生开发专业能力变得更重要，而不是更不重要。工程师必须判断生成的 Swift 是否遵循 Apple 规范，以及生成的 Kotlin 是否符合 Android 架构。他们还必须识别模型虽忠实复现、却不应继续保留的行为。

Shop 迁移得益于一个稳定的参考实现。新产品开发则带来不同的问题。当两个平台都没有已被接受的版本时，智能体无法从已知来源转换行为。团队必须先将意图定义得足够清晰，供两套实现共同遵循。

产品探索可能使这变得困难。设计师和工程师经常会在使用早期版本的过程中完善行为。共享的 React Native 组件可以立即将这种调整应用于所有平台，而原生团队则必须将其分别传播并验证两次。

性能对比同样需要谨慎看待。Shopify 在干净的基础上重建了 Shop，并简化了部分产品。原生框架、减少依赖、下线页面和架构清理，都可能促成了报告中的提升。

这些测量来自 Shopify，而非独立测试机构。由于它们描述的是生产环境部署，因此仍具有价值，但不应被视为通用比例。不同应用会有不同的启动路径、原生集成和团队结构。

React Native 仍提供编程智能体无法消除的优势。共享实现减少了业务逻辑可能出现分歧的位置。其生态系统还提供库、调试实践、部署工具，以及庞大的 React 开发者群体。

Shopify 自身也曾强调这些优势。其此前的迁移构建了共享基础能力，并帮助开发者在不同应用间流动。该公司还表示，React Native 让团队无需持续协调平台差异，便能交付价值。

开源转型又增加了另一层不确定性。Shopify 计划资助 React Native Skia 至 2026 年底，之后维护者 William Candillon 将以新名称继续维护它。原始仓库最终将被归档。

FlashList 则呈现出不同路径。Shopify 表示，这个高性能列表库每周约有 200 万次下载。该公司计划修复关键兼容性问题，同时与其他组织讨论长期维护安排。

Restyle 的用户规模较小，将被归档。Shopify 表示，它将在 2026 年底前继续可用，并可能为另一位维护者提供交接支持。这些转变会给依赖 Shopify 库的开发者带来实际的规划工作。

它们也说明了：即使不否定一项技术，一位重要用户的离开依然会影响整个生态。React Native 将失去一位重要采用者带来的工程投入、实际场景测试和机构性倡导。社区维护可以替代这部分贡献，但这种交接必须成功。

该公司的更大规模迁移尚未完成。Shop 是首个迁移的应用。主 Shopify 应用包含超过 300 个页面、组件、一个 Apple Watch 应用、复杂功能以及 Siri Shortcuts。

Shopify 表示，该应用将在 2026 年稍晚时候以原生形式发布，其余应用将随后跟进。与 Shop 相比，这些项目提供了更严苛的测试，因为它们包含更广泛的平台集成和对商家至关重要的工作流。

在此之前，负责任的结论应当保持有限。Shopify 证明了，借助代理的原生迁移可以在一款大型应用上快速奏效。但它尚未证明，在其完整移动产品组合中，这种方式的长期维护成本如何。

三个信号将揭示 Shopify 的押注是否成立

接下来的证据必须证明可重复性、持续的功能一致性，以及稳定的开源交接。

第一个信号是主 Shopify 应用的原生版本发布。其超过 300 个页面和广泛的 Apple 集成，使其成为比 Shop 更困难的迁移项目。如果能够按时发布并保留原有功能，将强化 Shopify 关于其方法可扩展的主张。

该版本的质量比发布日期本身更重要。启动性能、会话稳定性、构建时间、无障碍功能、分析数据连续性以及商家工作流，都应达到或优于 React Native 版本。延期或体验不均衡的发布，将削弱快速绿地迁移的论据。

第二个信号是，在独立功能开发开始后能否持续保持一致。Shopify 必须证明，iOS 和 Android 能够继续发布等效功能，而不会增加审核延迟。来自多个发布周期的证据，将比迁移吞吐量更有说服力。

这一测试直指 Shopify Swift Kotlin 开发的核心。代理可以翻译一个已完成的功能，但产品团队也会在实施过程中调整需求。持续一致的分析数据和行为表现，将说明共享规范能否长期替代共享源代码。

第三个信号是 Shopify 的 React Native 库的未来。顺利完成 React Native Skia 分叉、对 FlashList 进行持久维护，以及提供清晰的 Restyle 指引，将支持 Shopify 关于其正在负责任地处理退出事宜的说法。

维护工作若受到干扰，则会说明另一种情况：架构调整带来的成本不止会影响一家公司的代码库。这些成本将由那些基于 Shopify 早期承诺制定计划的开发者承担。

工程负责人应在效仿这一决策前关注这些信号。他们还应为崩溃率、启动时间、应用体积、构建时长、框架维护和一致性工作建立自己的基准。

随后，他们可以使用真实功能开展范围受限的原型测试。测试应涵盖分析、无障碍功能、导航、错误状态和平台惯例，并衡量审核时间和缺陷发现情况，而不仅仅是生成的代码行数。

Shopify 的原生移动开发之所以重要，是因为它为代理时代重新定义了复用。它并未给出 React Native 与原生开发孰优孰劣的普遍答案，而是提出了一个更具挑战性的问题：当实现成本变得低廉时，工程组织应将其单一事实来源置于何处？

团队应以生产环境证据来回答这个问题。追踪代理是否能在多个发布周期中降低总体审核和维护成本。如果可以，彼此独立的原生应用将更具吸引力；如果协调成本的增长快于代码生成能力的改善，共享实现方式依然值得保留。