Shopify 的人最近正式回应了「从 RN 回到原生」和「为什么不用 KMP」 这个两个问题，因为它们才在 2025 年刚总结过五年 RN 实践，那时候还是所有移动 App 都已经迁到 React Native，Shopify App 做到了 P75 页面加载低于 500ms、超过 99.9% 的 crash-free sessions，甚至都已经迁移到 RN 新架构上了，那时候还明确把这次迁移说是巨大的成功。

然后现在突然就说回归原生，原因是 AI 来了之后，“React 这个共享语言，现在被 English 取代了”。

也就是对于 Shopify 来说，跨平台的一致性需求现在从「共享代码」变成「共享行为、测试和验证标准」，因为 AI 可以负责把同一个意图分别实现成 Swift 和 Kotlin，测试系统负责证明两份实现还是同一个产品。

所以整个变化类似于：

成本	2020 年	Shopify 2026 年的做法
功能实现	Swift/Kotlin 人工做两遍，贵	Agent 大量承担第二份实现
双端同步	靠人追 Feature Parity	Agent 比较实现和自动化测试
人员技能	往往需要 iOS/Android 专长分别覆盖	同一个开发者可以借 Agent 跨栈工作
原生能力	RN 需要框架、Binding、第三方库	Swift/Kotlin 直接使用第一方能力

当然，这也不是「有手就行」的能力，把 Swift 和 Kotlin 都生成出来其实不算难，真正麻烦的是时间长了以后，比如：

• iOS 修了一个边界 Bug，Android 有没有跟？

• 一个 analytics event 的 payload 两边是不是一致？

• 无障碍行为有没有漂移？

• 某个 Experiment 是否只在 Android 落了？

以前 React Native 的优势在于大量业务逻辑天然只有一份，所以很多差异从源头就不存在，但是到原生，这些东西可不是用了 AI 就白送，因为 AI 会飘，会作弊，会幻觉，会偷懒，只有没经历过真正工程开发的才会觉得，用了 AI 就可以立马 double native 。

这里我觉得可以看英伟达最近用 AI 给 KDA 做性能优化的一个例子就很经典，为了作弊，AI 做了很多骚操作：

• 发现 Q/K 输入总是某种高斯分布，干脆不算真实 L2 norm，直接写死一个 0.1778209953 常数

• 发现测试里的 sequence layout 固定，就把 cu_seqlens 的动态逻辑写死

• 发现测试数据里旧 history 影响不大，就只留最近 32 token，把历史直接砍掉

• 使用一种计算 decay 的快速方式，测试数据能跑，但衰减稍大就数值 underflow，真实模型直接 NaN

看不懂是什么无所谓，但是你可以知道，AI 在做需求的时候，它是不可靠的，AI 不保证你给 Android 代码就能跑出来一样的 iOS 代码，你如果什么都不做想着它对着 Android 就能生成 iOS ，那只会得到一大坨屎山，Shopfiy 的迁移一开始也是这样。

所以 Shopify 后来做了很多东西来维持着迁移和双端的一致性，其实就是把“一致性”从源码层搬到验证层：

用一套共享测试来验证 Swift 和 Kotlin 里面实现的业务逻辑，同一 Feature 只有两端都通过相同测试才能发布，而且这些逻辑还能脱离模拟器，直接 headless 跑在桌面环境里，给 Agent 一个非常快的反馈循环。

也就是，以前跨端框架承担的是一种结构性约束，大家只能共享同一套实现自然不容易分叉，然后 Shopify 现在改成另一种约束：

允许代码长得完全不同，但要求最终行为持续满足同一份 contract。

这也为什么现在 Shopify 还是要求“一个开发者同时负责两个平台”，他们没有重新拆出传统的 iOS Team 和 Android Team，还是同一个人保留产品上下文，然后让 Agent 帮他跨越陌生技术栈，这样做的目的是减少的“两个团队之间解释同一个 Feature”的沟通成本，而 Swift/Kotlin 的实现差异交给工具去吸收。

所以 Shopify 没有因为用会原生就加人，还是原本的人，只是跨平台框架变成了 Agent 跨平台框架，把代码成本变成验证成本。

然后在这个过程，它们做了 Helix， 拿迁移一个订单页面举例：

• 工程师告诉 Helix 要迁哪个 screen

• Helix 先读取现有 RN 原始需求实现，把任务切成几个很小的 checkpoint

• 然后先搭页面骨架，再实现订单 header，再接 action，再补复杂状态

• 每完成一个 checkpoint，先用 CLI 行为测试证明逻辑正确，然后把 RN 旧页面和新原生页面放到相同状态，通过视觉模型检查布局和 UI 差异

• 之后再交给两个彼此隔离的 reviewer agent 检查架构和代码质量，最后才轮到工程师确认

然后 Shopify 还专门做了 Tardis，把运行中的日志、事件、状态暴露给 Agent，同时允许它发送命令，之后做 parity review 的时候，Tardis 还可以同时捕获 RN 和 native App 的截图、analytics event 以及 payload，再让 Agent 检查两边是否对应。

这样后续 iOS 和 Android 在推进过程也可以享受这套 infra 。

所以不是没有成本，实际成本比 RN 还高了，但是收益也很明显，Shopify 能够放弃 shared codebase，很大程度依赖他们有一套 shared verification system，回到原生后，对 Shopify 来说最直观就是性能收益：

指标	React Native	Native	变化
iOS 冷启动	3200 ms	2466 ms	-23%
Android 冷启动	4433 ms	2233 ms	-50%
Session stability	99.5%+	99.95%+	Crash session 降 10 倍
Android App Size	293 MB	184 MB	-37.2%
Android Release Build	—	—	时间降 75%

至于 KMP ，它恰好处在 RN 和完全双原生之间，KMP 在 AI 时代可能反而会更受欢迎，因为它以前用起来很麻烦，门槛也高，但是现在 AI 能帮忙抹掉这些问题。

但是它对于 Shopify 来说还是没意义，因为用了 KMP 反而多了一些其他问题要处理，比如关于 iOS 上模块垃圾回收和调试问题的性能开销，在有一整套 AI infra 之后，维护 infra 就足够维持两套原生代码对比，这样性能问题直接就是附赠，升级适配也是 P0 可以完成，不需要等框架，所以干脆没必要上 KMP ：

而且就像作者说的，原生的成本低了，对跨平台来说也一样更低了，双端脱离跨平台的长时间迭代成本是需要有基建不断来维持，所以这个过程只是把成本转移到了其他地方，但是收益也是很明显，性能和适配就是最直接的收益。