各位 Vibe Coder，上午好！
我最近读到一篇旧文，Shopify 在 2026 年 9 月 10 日宣布从 React Native 回到 Swift 和 Kotlin。
这就很有意思了！
因为在 2020 年，Shopify 决定全面采用 React Native，而且认为这个选择非常成功。
功能只需开发一次，节省了大量时间；没有移动开发背景的开发者也能参与应用开发；再也不用一直追着补齐两个平台的功能。
甚至在 2025 年 1 月，AI Coding 已经初露锋芒的时候，Shopify 也坚持认为 React Native 前景光明，会继续投入。
如果根据当时 Shopify 能掌握的信息，这个判断并没有问题。
React Native 很好地满足了他们的需求，直到今天，它依然是一个优秀的框架。
不过，从那以后，编程模型的能力有了大幅提升。对于 Shopify 的应用和团队来说，用 Swift 和 Kotlin 分别实现同一个功能，成本已经不像过去那么高了。
于是，Shopify 今年又从最基本的问题出发，重新评估了移动端技术栈。
评估的结果，就是回到原生开发。
为什么回到原生开发
2020 年，Shopify 从原生开发转向 React Native，主要是为了三件事：
- 不再把同样的功能开发两遍；
- 让开发者可以跨技术栈工作；
- 少花时间补齐两端功能，多花时间交付有价值的功能。
这几年，React Native 确实做到了。虽然 Shopify 也花了不少精力优化性能、完善基础能力，以及跟进框架和外部依赖的更新，但按照他们的说法，这些投入是值得的。
那问题来了，同样的功能还是得写两遍，成本怎么就变了？
一个功能以前用 React Native 写一遍，现在用 Kotlin 和 Swift 分别写，为什么他们反而觉得值得？
有一点各位不知道的是，Shopify 从 2021 年就开始用 LLM 开发软件了，比 ChatGPT 还早一年！
最初主要用来实现功能、排查和修复 bug，以及审查代码。随着模型进步，交给它的工作也越来越复杂。
到了 2025 年底，Shopify 开始重新考虑一个问题：把软件开发两遍，还意味着要做两倍的工作吗？
于是，他们借助 LLM，用 Swift 和 Kotlin 重建了几款大型应用中的一些核心部分，验证实际效果。结果发现，智能体已经可以参考 iOS 版本实现 Android 功能，反过来也一样。
开发者也能借助智能体，更快地熟悉自己主要技术栈之外的工作。再配合共享的规格说明、测试和审查检查点，维持两端一致性的成本就降下来了。
当然，这不代表原生开发突然只需要维护一份代码了。两个平台仍然要分别开发、分别维护。只是智能体承担了足够多的实现、代码转换、测试和审查工作，让这部分成本不再像 2020 年那样，成为决定技术选择的关键因素。
但原生开发的一大优势还在：更直接地使用平台能力和官方工具，减少框架适配和依赖维护的负担。
换句话说，即使运行速度没有明显提升（话虽这么说，但是现在哪个跨平台框架的性能能媲美原生呢？），开发和维护上的收益也可能让 Shopify 觉得值得切换。你想想新的 API 适配过程，如果跨平台框架没有支持新的 API，那么就只能自己手写转接层，或者找三方库干这个事儿！
当然，React Native 应用可以很快，Shopify 的应用就是如此。他们这次调整，主要是因为共享实现带来的成本优势变小了，运行性能并不是决定性因素。
Shopify 的开源库怎么办
Shopify 转向原生，使用他们开源库的开发者怎么办？
下面是原文在 2026 年 9 月发布时给出的安排。
React Native Skia
Shopify 会继续赞助到 2026 年底，之后 William Candillon 仍会继续开发。他计划在接下来的几个月里 fork 仓库，以新名称发布这个库，过渡完成后再归档原仓库。
Shopify 表示会持续发布进展，给使用者留出迁移时间，也呼吁依赖这个库的团队考虑赞助。
FlashList
FlashList 每周下载量约为 200 万次，已经是 React Native 高性能列表的常用选择。Shopify 会继续修复破坏兼容性的关键问题，同时与其他公司讨论长期维护事宜。
有意接手的团队，可以联系文章作者 Mustafa Ali。
Restyle
Restyle 的用户群相对较小，Shopify 的安排是归档仓库，保障它正常工作到 2026 年底，之后停止维护。如果有团队愿意 fork 并接手，他们会协助交接。
12 周，重建一个原生应用
Shopify 具体是怎么迁移的？如果各位所在的团队有意做迁移，可以参考他们的做法。
Shopify 手里可不只有一个应用：Shopify、Shop、Point of Sale 和 Inbox，每天都有全球数百万商家和买家使用。
他们讨论了两种方式：在现有应用中逐步迁移，也就是 brownfield；或者从头重建，也就是 greenfield。
上次迁移到 React Native 时，几款最大的应用选的是渐进式迁移。因为从头重写需要数年，还得在重写期间停止交付新功能，这个代价太大了。
但这次，他们选择了从头重建。
读者应该已经猜到原因了：LLM 已经能参考 React Native 版本，用 Swift 和 Kotlin 实现功能；从头开始可以摆脱原有约束；前期原型也表明，重建速度比编程智能体出现之前快了很多。
第一个完成迁移的是 Shop，也就是经常位居应用商店购物分类榜首的那款应用。按照 Shopify 的介绍，借助 AI，团队只用了 12 周，就从概念验证走到了完整重建原生应用并上架应用商店。
注意，这个“12 周”说的是 Shop，不是 Shopify 旗下所有应用。
原文发布时，Shopify 应用还在迁移中，计划在 2026 年晚些时候发布。这是他们最大的应用，有 300 多个页面，还有主屏幕和锁屏小组件、Apple Watch 应用、表盘复杂功能（complications）、Siri 快捷指令等。其余应用也在后续迁移计划中。
怎么避免生成一堆低质量代码
看到这里，可能会觉得：既然有现成的 React Native 代码，让 AI 照着重写不就行了？
Shopify 试下来的结论是，这样不行。
即使先让模型尽可能收集信息，整理好规格说明和任务文件，再一次性实现，最后仍然会得到一大堆难以维护、无法交付的代码。
他们为此构建了一个叫 Helix 的系统。做法是把工作拆小，每完成一块，就验证一块。第一次输出可以不对，但没有改好，就不能往下走。
如果各位用过 Matt Pocock 的这套技能，应该对 /to-spec 和 /to-tickets 不陌生，很像对吧！
具体来说，开发者先指定一个页面，Helix 读取对应的 React Native 代码，再提出一组有先后顺序的检查点。每一块的工作量，都要控制在几分钟内就能审查完的程度。
然后，逐个检查点实现。每一块都需要：
- 用测试证明行为正确；
- 通过视觉审查，确认与运行中的应用一致；
- 接受两个审查者的对抗式代码审查；
- 最后获得人工认可，才能提交代码，开始下一块。
Helix 正在使用 Swift 和 Kotlin 重建 Shopify 移动应用中的一个页面
每次审查的反馈都会被保留下来。随着迁移推进，后续工作也能参考这些反馈，逐渐减少人工介入。
按照 Shopify 的说法，这套方式效果非常棒，让重建应用的时间缩短到了原来的一小部分。
改代码几秒，验证却要几分钟
拆小任务还不够，验证本身也得快。
Shopify 遇到的另一个问题，是智能体控制模拟器不够可靠，构建、测试和迭代经常需要人盯着。他们也开发了工具，让智能体自主复现 bug、修复并验证，但整个过程还是慢，也不够稳定。
为什么？
因为智能体通常要先通过截图或无障碍树获取应用状态，再执行操作、检查结果。代码几秒就改好了，验证却要花上几分钟，迭代自然快不起来。React Native 的模块热重载能缓解一部分问题，却解决不了模拟器控制本身太慢的问题。
Shopify 的处理方式，是调整应用架构：让业务逻辑与 UI 完全解耦，能够直接在桌面环境中无界面运行，再通过 CLI 把这些能力提供给智能体。
这样，检查状态、在不同区域之间导航、执行操作，就不必每次都启动模拟器、操作 UI 了。按照原文的说法，这部分迭代能从分钟级缩短到毫秒级，也让智能体可以连续自主工作数小时。
当然，需要验证 UI 时，还是要用模拟器。此时 CLI 可以通过远程模式连接模拟器，用命令直接驱动 UI，省去依赖布局或无障碍树来确定操作的过程，也能用于快速执行端到端（E2E）测试。
这里要分清楚：业务逻辑可以脱离 UI 快速运行，不代表整个应用的视觉效果和交互都不用验证了。前面 Helix 的流程里，视觉审查和人工认可仍然保留着。
接下来
按照原文给出的计划，Shopify 会把所有移动应用迁移到 Swift 和 Kotlin，并在整个过程中使用 AI。
他们也明确表示，每次重建都必须达到或超过现有的性能、稳定性、无障碍和产品质量要求。迁移完成以后，还要看产品迭代是否更快、应用质量是否更好，以及智能体能自主完成多少工作。
后续，他们计划继续分享 Helix、智能体可直接操作的应用架构，以及与智能体一起开发移动应用的经验。
文章最后，Shopify 仍然肯定了过去六年的 React Native 实践，并感谢参与其中的团队和社区。原生开发是他们现在的选择，React Native 则是适合他们 2020 年处境的选择。
篇外故事
其实今年早些时候，我的同事问过我：现在最好的跨平台开发框架是什么？
我：你打算支持哪些平台呢？
同事：移动、网页、小程序。
我说：要不你试试 Uni App。
我知道，包括我自己在内的很多开发者，一定认为 Uni App 是个垃圾堆框架，但不可否认的是，一旦你要做支持小程序的跨平台开发，Uni App 几乎是唯一的选择。我知道还有 Taro，但是它在国内的市场份额很小，几乎不会纳入考虑。
后来我问他：现在 2026 年了，你为什么要使用跨平台框架？
他的回答和 Shopify 早期的考虑一致：人少，想减少成本。
我说：那你知道维护跨平台的 bug 需要多少成本吗？
我当时已经给了一个结论，大模型第一个干掉的，就是跨平台。
当然，这话有些绝对。现在来看，可能换个表述更准确一点：大模型时代，跨平台不再是开发的第一选择！
一点想法
AI 如何改变技术选型时的成本考量？
过去，“同样的功能不用写两遍”很有吸引力；现在，如果分别开发两端的成本降下来了，更直接地使用平台能力、少处理一些框架适配和依赖问题，就可能值得多维护一套代码。
这里值得注意的是：Shopify 并没有把整个代码库丢给 AI，然后等它交付。他们拆小任务，保留测试、视觉审查和人工确认，还专门调整架构，让智能体能更快地验证代码。看起来，模型变强以后，团队依然得花心思让它用得上、验得快。
