Shopify 正在从 React Native 回退到 Swift 和 Kotlin
Shopify 正在把其移动应用从 React Native 重写回完全原生的 Swift 和 Kotlin，理由是现代 AI 编码代理已经消除了维护两套代码库的大部分历史成本。评论者认为这反映出更广泛的趋势：如果 LLM 能处理重复性的跨平台工作，大公司可能会更倾向于原生性能、更紧密的平台集成，以及更少的框架开销，即便代价是失去单一共享技术栈。也有人提醒说，跨平台之间的一致性、测试和长期维护仍然是难题，而对于小团队来说，React Native、Flutter 或基于网页的方法在经济性上可能仍更有吸引力。
Shopify 此次转向的感知原因
- 许多人认为，这一转变主要是为了摆脱 React Native 的“税”：痛苦的升级、依赖项频繁变动，以及上游框架的不稳定性。
- 也有人认为，真正的驱动因素是内部偏好和政治因素，而不只是 AI 或客观成本。
- 还有几位指出，Shopify 本来就已经被迫进行一次重大的 RN 重构（“新架构”），因此重新评估技术栈的时机很合适。
AI/LLMs 与原生开发的经济性
- 普遍认为，编码代理大幅降低了构建和移植原生应用的成本；多位评论者表示，小到中型应用可以在一夜之间或非常快地完成 RN → Swift/Kotlin 的迁移。
- 支持者声称，“一个 RN 应用 vs 两个原生应用”如今是个错误的二选一：AI 可以维护两者，尤其是当规格和测试是共享的时候。
- 怀疑者则反驳说，AI 同样也让 RN 更便宜；多年后的功能对等与维护成本仍不清楚，也未经验证。
React Native、Flutter 与其他替代方案
- RN 被描述为能用但脆弱：频繁的破坏性变更、笨拙的升级、库质量不均，以及性能/用户体验上的代价，尤其是在 Android 上。
- Flutter 既受到称赞（“仍然很喜欢它”），也受到否定（“死胡同”）；有人认为其基于 Skia 的栈天生就很重。
- Kotlin Multiplatform、Rust+UniFFI，以及原生 .NET 被提到为更适合共享核心逻辑、同时保留原生 UI 的方式。
App Store 审核、OTA 与发布
- 对当前 iOS 审核时间存在强烈分歧：有人报告少于 24 小时，也有人说需要 2–7 天甚至更久，而且波动很大。
- RN 的空中更新（OTA）被视为在快速修复 bug 和落实合规变更方面的巨大实际优势；对这次转向持批评态度的人担心 Shopify 正在放弃这一点。
一致性、复杂性与组织成本
- 多位评论者表示，最难的并不是最初重写，而是在多年内保持 iOS/Android 行为一致：实验、分析、可访问性、边缘情况。
- 共享规格和测试被认为是必要的，但其长期有效性“并不清楚”；人们想要硬数据（工时、缺陷率、漂移事件、模型支出）。
AI、质量与安全担忧
- 有些人拥抱“代理式”开发，几乎不读 Swift/Kotlin 的输出，而是依赖测试和额外的模型审查者。
- 其他人警告说，这会导致不可维护的“凭感觉编码”原生应用，存在隐藏 bug、安全问题（密钥、OAuth、WebView），以及人类并不真正理解的脆弱代码。
更大的趋势
- 许多人预计，资金雄厚的大型组织会回到原生开发，而小团队和 MVP 则会继续使用 RN/Flutter/网页方案。
- 还有几位预测，随着代码变得“便宜”，但复杂性和运行时臃肿依然昂贵，整个行业会更广泛地从 Electron 和沉重的跨平台栈转移开去。