Shopify弃用React Native回归原生开发：AI代码重写引发行业争议

Shopify回归原生：一则引发热议的技术决策

Shopify宣布将其移动应用从React Native迁移回原生的Swift（iOS）和Kotlin（Android）开发，这一消息在技术社区掀起了广泛讨论。对于一家曾大力推广跨平台方案的电商巨头而言，这样的"回归"本身就足够引人注目，而其背后借助AI工具进行大规模代码重写的做法，更是让整个决策充满争议。

正如社区中一位开发者所言："选择从一个成熟的、手写的代码库，迁移到一个完全由AI生成、并且使用工程师并非最熟悉语言的应用……这确实是个大胆的选择。"这句评论精准地概括了外界的疑虑：这究竟是一次深思熟虑的技术升级，还是被AI浪潮裹挟下的一次冒险？

React Native中的"Native"到底意味着什么？

要理解这次迁移的意义，首先需要厘清一个常见的误解：React Native中的"Native"究竟指什么。

UI层原生渲染，业务逻辑非原生

社区讨论中有开发者提出疑问："React Native真的算'原生'吗？我一直以为这里的'Native'更多是指它感觉起来、运行起来像原生，跑在一个（据称）轻量级的JS引擎上，从开发者角度看仿佛在为一个抽象平台编写原生代码。"

这一疑问得到了较为准确的澄清：React Native的UI渲染确实运行在原生UI栈上，但业务逻辑是通过JavaScript运行时执行的。换句话说，用户看到的界面组件是真正的原生控件，但驱动这些控件的逻辑层却隔着一层JS引擎的抽象。

正是这层抽象，成了Shopify官方给出的迁移理由之一——他们希望减少抽象层级，让应用更贴近底层、更接近每台设备的硬件能力。

Shopify官方的迁移理由站得住脚吗？

然而，社区对Shopify"降低抽象层级"的说法并不完全买账。

一个不需要深度底层访问的应用

一位开发者尖锐地指出："这个解释在向高层汇报时听起来有点含糊其辞，作为商业理由并不充分。Shopify这类应用其实并不需要深度的底层访问权限。它本质上是一个简单的应用，根据服务器指令重绘界面即可。"

这个观点值得深思。对于Shopify这样的服务器驱动型UI（Server-Driven UI）应用来说，绝大部分功能只是根据后端返回的数据渲染界面。真正涉及平台特定能力的场景相当有限——比如支付、相机、推送通知等API。而这些恰恰是React Native生态中早已被解决的成熟问题。

因此，如果应用的核心逻辑并不依赖底层硬件的深度访问，那么"降低抽象层级"作为迁移的主要动机就显得说服力不足。

社区推测的三种真实迁移动机

面对官方语焉不详的解释，开发者们提出了几种更贴近现实的猜测。

动机一：React Native长期维护的痛点积累

第一种可能是React Native的开发痛点已经积累到难以承受的程度。例如，新版iOS或Android操作系统发布时往往会破坏现有功能，导致持续不断的兼容性维护成本。不过持怀疑态度的开发者认为，如果真是这个原因，官方应该会在公告中明确提及。

动机二：AI编程工具对Swift和Kotlin支持更好

第二种推测颇具时代特色：AI编程工具对原生语言的支持可能更加成熟。Swift和Kotlin作为主流语言，拥有更庞大的训练数据集，从而让大语言模型在生成这类代码时表现更好。这一猜测虽然缺乏确凿证据，但它反映了一个正在浮现的趋势——技术选型正在被AI工具的能力边界所影响。

动机三：绩效考核与晋升驱动的技术决策

最被社区认可的，反而是一个带有讽刺意味的推测：有人在为晋升铺路。一位开发者半开玩笑地写道："某人正在寻求升职。他们可以炫耀AI在如此短时间内写了多少代码，还有什么比把所有东西重写一遍——甚至两遍——更能刷数据呢？"

另一条评论则更加辛辣："不然，新上任的'移动创新副总裁'要怎么才能升到'执行高级副总裁'呢？"这种对企业内部政治与技术决策关系的调侃，道出了不少一线工程师对大公司技术转向的复杂心态。

从Airbnb到Shopify：维护三个代码库的历史教训

讨论中还有一个值得重视的技术现实：迁移到原生意味着放弃跨平台的代码复用优势。

有开发者提醒道："或者他们发现需要维护三个代码库，而不是两个。Airbnb早就发现了这个问题。"这里指的是Airbnb在2018年那次著名的"抛弃React Native"决定——当时Airbnb发现，采用React Native后不仅没有减少工作量，反而要同时维护iOS原生、Android原生和React Native三套代码，得不偿失。

这一历史案例形成了有趣的对照：跨平台方案承诺的"一套代码走天下"，在大型复杂应用中往往难以兑现。当一家公司选择原生开发时，实际上是在"两套原生代码"和"两套原生+一套跨平台"之间做取舍。

AI时代的代码重写经济学：成本降低背后的风险

这次事件真正的新意，或许不在于"回归原生"本身，而在于AI大幅降低了大规模代码重写的成本。

过去，将一个成熟的、手写的代码库完全重写是一项风险极高、投入巨大的工程，通常会被管理层否决。但当AI能够快速生成大量代码时，重写的门槛被显著拉低。这既带来了机遇——快速现代化技术栈；也埋下了隐患——用AI生成的、团队并不完全熟悉的语言代码，去替换一个经过长期打磨、稳定运行的系统。

有开发者指出，这种做法或许受到了Bun等项目"用现代工具重写基础设施"思路的启发。但代码库的成熟度和稳定性本身就是一种价值，用AI生成的代码替换它，需要格外谨慎地评估其质量与可维护性。

结语：一个值得持续观察的行业样本

Shopify的这次技术转向，本质上是一个多重因素交织的复杂决策：技术上对抽象层级的权衡、组织层面的绩效驱动、以及AI工具带来的重写成本变革。

无论真实动机如何，这一案例都为整个行业提供了一个值得观察的样本：在AI辅助编程日益普及的今天，技术选型的逻辑正在被重新书写。跨平台与原生之争这个老话题，因为AI的加入而有了新的变量。至于Shopify的选择究竟是明智的技术现代化，还是被工具能力和组织政治推动的冒险，恐怕只有时间才能给出答案。