原生开发现已成为Shopify移动端的未来（2026）

# 原生开发是Shopify移动端的未来（2026）- Shopify 来源：https://shopify.engineering/back-to-native 早在2020年，我们就决定全面投入（https://shopify.engineering/react-native-future-mobile-shopify）React Native，而这一押注取得了巨大成功。我们节省了大量重复构建功能的时间，让没有移动端背景的开发者也能为我们的应用做出贡献，并让我们从不断追求功能一致性的压力中解放出来。 2025年1月，我曾写道（https://shopify.engineering/five-years-of-react-native-at-shopify），React Native的未来一片光明，Shopify计划持续投入。基于当时所知的情况，这确实属实。React Native为我们运作良好，它依然是一个优秀的框架。但自那时起，编程模型发生了巨大变革，对于我们的应用和团队而言，用Swift和Kotlin分别构建相同功能的代价已不如以往高昂。 我们不会仅仅因为某个决策在过去成功就固守它。当核心假设发生变化时，我们愿意回过头来重新审视它是否仍是最佳选择。大语言模型改变了我们2020年决策背后的一个核心假设，因此我们从第一性原理出发，重新评估了我们的移动技术栈。 我们的发现指引我们回到了原生开发。 ## 为何切换回原生开发 2020年我们决定从原生切换到React Native，原因有三： - 避免重复构建相同功能 - 让开发者能够跨技术栈工作 - 减少追求功能一致性的耗时，将更多精力投入价值交付 React Native始终如一地带来了这些好处。我们发现自己投入了大量时间和资源来优化性能、改进React Native的关键基础领域，以及跟进框架更新和外部依赖，但这些都是可接受的权衡。使用React Native带来的好处，远远超过了我们在这些方面必须做出的投入。 Shopify自2021年起（比ChatGPT还早一年！）就使用大语言模型构建软件。最初，我们用它们来实现功能、调查修复Bug以及审查代码。随着模型能力的提升，我们托付给它们处理的工作复杂度也随之提高。到2025年底，它们已不仅仅帮助我们更快地编写代码，而是让我们开始质疑：重复构建软件是否仍意味着双倍的工作量。 我们决定重新评估移动技术栈，并开始制作原型，以验证我们的技术选择是否依然成立。我们使用大语言模型，用Swift和Kotlin重建了几个核心应用的核心部分，其成效令人惊讶。AI智能体： - 能够以iOS版本为参考在Android上实现功能，反之亦然 - 帮助开发者快速上手并有效贡献代码，即使在其主要技术栈之外 - 通过共享规范、测试和审查检查点，显著降低了保持平台间一致性的成本 原生开发仍然意味着在两个平台上构建和维护软件，这一成本并未消失。改变的是，智能体现在能够完成足够多的实现、翻译、测试和审查工作，使其不再是2020年那样的决定性因素。 React Native应用可以很快，我们的就是。我们做出这一改变，是因为智能体减少了共享实现的优势，而为每个平台构建的优势依然存在。原生开发让我们更贴近平台能力和一等工具，我们的代码与平台之间的框架和依赖层也更少。 ## 我们的React Native开源库的未来 在详细介绍迁移方式之前，我们希望确保平稳过渡。从一开始，我们就想回馈React Native使其变得更好。我们发布的开源库已成为各自领域的首选。我们感谢社区的热烈支持，并致力于确保这次过渡平稳顺利，不会有意外。 ### React Native Skia (https://github.com/Shopify/react-native-skia) Shopify将继续赞助该项目直到2026年底，之后William Candillon (https://x.com/wcandillon)将继续维护。他将在未来几个月内fork该仓库，并以新名称发布该库。过渡完成后，原始仓库将被归档。我们会持续更新进展，让大家有充足时间迁移。如果你的应用依赖此库，请考虑赞助它。 ### FlashList (https://github.com/Shopify/flash-list) 该库每周下载量约200万次，已成为React Native中渲染高性能列表的默认方式。鉴于它对生态系统的重要性，Shopify将继续修复破坏兼容性的关键问题。我们目前正在与几家公司在商讨长期维护FlashList的事宜。如果你有兴趣，请在此联系我（https://x.com/mustafa01ali）。 ### Restyle (https://github.com/Shopify/restyle) Restyle的用户基数比我们的其他库小，因此我们将归档此仓库。我们会让它持续运行到2026年底，之后将停止维护。任何人都欢迎fork并继续开发，如果有团队愿意接手，我们将协助交接。 ## 我们如何进行迁移 Shopify拥有多个大型应用（Shopify (https://apps.apple.com/us/app/shopify-sell-online-in-person/id371294472)、Shop (https://apps.apple.com/us/app/shop-track-pay-discover/id1223471316)、Point of Sale (https://apps.apple.com/us/app/shopify-point-of-sale-pos/id686830644)、Inbox (https://apps.apple.com/us/app/shopify-inbox/id1301681854)）。全球数百万商家和买家每天依靠它们谋生，从他们喜爱的品牌购买心仪的产品。 我们曾权衡是渐进式迁移到原生（棕地开发）还是从头开始重建（全新开发）。过去迁移到React Native时，对于一些最大的应用，我们选择了棕地方式，因为重写需要数年时间，并且在此期间必须停止发布新功能。 然而，这次全新开发凭借以下原因胜出： - 大语言模型擅长以React Native版本为参考，用Swift和Kotlin构建功能 - 它为我们提供了一张白纸，可以不受以往任何约束，以最佳方式重建 - 我们的原型表明，我们可以比编程智能体出现之前更快地重建这些应用 Shop应用是首个完成迁移的，它通常在应用商店的购物类别中名列前茅。在AI的辅助下，团队仅用12周就从概念验证完成到完全重建并发布原生应用。我们已在此（https://shopify.engineering/shop-app-migration）深入撰文介绍了这次迁移。 Shopify应用（我们最大的应用，拥有300多个屏幕、主屏幕和锁屏小组件、Apple Watch应用、复杂功能、Siri快捷指令等）的迁移也已进行中，并将于今年晚些时候发布。其余应用也将很快迁移。 ### 防止生成垃圾代码 直接让大语言模型参考React Native代码库，试图一次性生成原生版本的相同功能，这是很诱人的，但行不通。即使你要求它事先收集尽可能多的信息，将其固化为规范、任务文件，然后再实现，最终也会得到大量无法维护、无法发布的代码。 为解决这个问题，我们构建了一个名为Helix的系统，它采用更渐进的方式。它不期望第一次输出就正确，而是建立了一个循环，一个不完善的尝试只有在变成一个好结果后才能继续推进。 开发者将Helix指向一个屏幕。Helix读取React Native代码，并提出一系列检查点（有序的小任务切片），可在几分钟内完成审查。然后，它逐个检查点进行构建：每个检查点都必须用测试证明其行为，在视觉审查中与运行中的应用匹配，经受两名对抗性代码审查员的考验，并在提交并开始下一个之前获得人类的认可。每次审查的反馈都会被记住，因此随着迁移的进行，这个循环会变得更加自主。 ***Helix使用Swift和Kotlin重建Shopify移动应用中的一个屏幕* 这种方法效果极佳，使我们能够以极少的时间重建我们的应用。 ### 实现快速反馈循环 智能体控制模拟器一直是个瓶颈。我们发现自己不得不持续看管它们，因为它们无法可靠地构建、测试和迭代。我们构建了工具（https://x.com/mustafa01ali/status/2035155157982289998），允许智能体自主复现Bug、修复并验证修复，但这个过程既慢又脆弱。React Native的热模块重载（HMR）有助于改善这种情况，但由于模拟器控制缓慢，它并未完全解决。这主要是因为依赖于无障碍树或截图来获取应用状态、执行操作和验证结果。智能体可以在几秒钟内做出代码更改，但测试输出却需要几分钟。这使得迭代极其缓慢和手动。如果模型无法快速测试其工作，无论模型多好都无济于事，这在移动端尤其困难。 我们正通过设计同时适用于人类和智能体的应用架构来解决这个问题。这里的核心原则是，业务逻辑应与UI完全解耦，并能够在桌面端无头运行。然后，我们通过一个CLI使其对智能体可用，允许他们在毫秒而非分钟内迭代，无需涉及模拟器。 *使用CLI导航应用并执行操作* CLI允许智能体检查应用状态、在不同部分间导航并执行操作，所有这些都无需接触UI。这实现了极快的反馈循环，允许智能体一次自主工作数小时。 当需要模拟器交互时，CLI可以通过远程模式连接到模拟器，并通过命令驱动UI，无需检查布局或无障碍树。这实现了闪电般的性能和端到端测试。 *这是实时速度（未加速）* ## 下一步 我们将使用AI将所有移动应用迁移到Swift和Kotlin。Shop应用已作为完全原生应用发布，Shopify应用正在迁移中，其余应用也将很快跟进。我们正在快速推进，但并非降低标准。每次重建都必须达到或超越人们现今期望的性能、稳定性、可访问性和产品质量。这不仅仅是将相同应用用不同语言重写。我们正在重建它们，以便人类和智能体都能快速理解、测试和更改。 迁移并非终点线。成功意味着我们的团队能比以往更快地为商家和买家提供更好的体验。我们将通过产品速度、应用质量以及智能体自主完成工作的量来衡量这一点。 我们将分享沿途的所学，包括对Helix、我们面向智能体的架构以及我们如何使用智能体构建移动应用的深入探讨。我们曾坦诚分享从React Native中学到的东西，我们打算对这次转变也同样坦诚。 这是我们承担过的最雄心勃勃的移动工程项目之一。如果你想帮助构建Shopify下一代移动应用，我们正在招聘（https://www.shopify.com/careers）移动工程师、基础设施工程师以及从事AI与软件工程交叉领域工作的开发者。 ## 致谢 原生开发是Shopify现在的正确选择，但React Native是Shopify在2020年的正确选择。这一成功只有因为那些让它得以实现的人们才成为可能。 ### **Meta** 感谢React Native团队在Meta担任框架的优秀维护者，倾听我们的反馈，并与我们紧密合作多年。由于你们在架构、性能、工具和社区方面的投入，React Native今天已大幅改进。 ### **William Candillon** 感谢你创建React Native Skia，并将其发展到超出我们所有人想象的地步。你重新定义了React Native中图形和动画的可能性，我们期待看到你接下来的发展方向。 ### **Software Mansion** 感谢你们在Reanimated上的所有工作，倾听我们的反馈，并帮助我们解决应用中一些最棘手的动画和性能问题。 ### **Shopify工程师** 数百名工程师为采用React Native、迁移我们的应用、构建共享基础、改进性能、维护集成以及回馈生态系统做出了贡献。你们中的许多人成为了初学者，挑战了长期持有的假设，并在持续为商家和买家交付功能的同时，成功完成了这次过渡。谢谢你们。 ### **React Native社区** 感谢所有使用我们开源库、贡献代码、报告问题、挑战我们的决策并分享所学的人。你们的贡献和反馈，包括那些尖锐的，让我们的工作变得更好。 过去六年里构建的工具、经验教训和人际关系，将继续塑造我们在Shopify构建移动应用的方式。我们深深感谢每一位参与者。