AI 时代 iOS/Android 跨平台框架的尴尬未来

跨平台幻象：工程、官僚主义与 AI 时代

我曾在中国大陆几家最大的互联网公司工作了十多年。后来，我移居海外，加入了一家业务遍及全球、但不在中国大陆运营的全球性科技公司。再后来，我在海外创办了自己的公司。

这些经历让我得以从不同的视角，重新审视自己在中国见到的工程文化和技术决策。

我对跨平台框架的怀疑始于 2024 年。

当时，我在业余时间开发一款 ASR/TTS 移动应用。我不想依赖云端计算，而是希望利用设备本身的算力，因为 iOS 和 Android 都已开始支持能力日益增强的机器学习 API。

我也已经开始使用 Cursor 进行 AI 辅助开发。

在为自己的应用研究跨平台方案时，我得出了一个结论：在 AI 时代，iOS/Android 跨平台框架会变得越来越无足轻重。

而且，或许早在 AI 出现之前，它们的价值就被高估了。

最近，我读到了 Shopify 的工程文章：原生开发如今是 Shopify 移动端的未来。文章讲述了他们从 React Native 回归原生开发的决定。

它让我想起了自己在 2024 年对跨平台框架的那些疑问，也促使我终于把自己的想法写下来。

Shopify 声称，React Native 在 2020 年是正确的选择。我并不那么确信。

Shopify 自己也承认，在性能优化、框架改进和依赖维护上投入了大量时间和资源。但这些只是跨平台开发成本的一部分。那么，维护开发者生态系统的隐性成本、组织开销，以及错失的商业机会呢？

Shopify 是否曾完整核算过这一决策真正的经济成本？我对此深表怀疑。

我的结论主要基于以下几点：

• AI 编程智能体正在大幅降低原生应用的开发和维护成本。
• 端侧 AI让原生开发更具吸引力，而跨平台框架往往落后于平台的新能力。
• **隐性成本，**包括框架维护、内部开发者生态、跨团队协调和组织政治，经常被低估。
• **新冷战与 AI 军备竞赛：**我们如今正处于一场新冷战之中，AI 已成为其中最重要的战略战场之一，就像上一次冷战中的战略防御倡议（星球大战计划）一样。随着竞争加剧，相比开发成本，产品上市速度和用户体验变得越来越重要。

不过，在讨论 AI 之前，我想先分享一些自己在中国互联网行业观察到的事情。

一次编写，到处运行？

在我工作过的几家中国大型互联网公司里，跨平台框架常常被宣传为降低开发成本的手段。

但它们的野心远不止于在 iOS 和 Android 之间共享代码。

公司希望代码只写一次，就能在所有地方运行：iOS、Android、H5、微信小程序、支付宝小程序，有时甚至包括更多平台。

这个说法听起来很简单：一次编写，到处运行。

但现实要复杂得多。

• **只写一次？未必。**有时开发者最终需要写三遍代码：iOS 一遍，Android 一遍，跨平台框架再一遍。支持 Web 或小程序平台还可能带来更多工作。
• **性能与用户体验。**要接近原生性能，往往需要投入大量工程工作，而且某些限制无法彻底消除。
• **平台 API 的滞后。**iOS 和 Android 的新能力，并不总能立即通过跨平台框架使用。
• **协调开销。**跨平台开发在业务团队、框架团队和原生平台团队之间引入了额外的依赖。
• **组织政治。**有些工程项目似乎更关注技术成就、团队扩张和晋升，而不是实际业务价值。
• **不必要的迭代。**业务真的需要如此频繁地修改应用吗？还是说，有些项目仅仅是为了工作而制造出来的工作？

而每增加一层复杂性，都要付出代价。

即使一个框架缩短了开发时间，我们又该如何衡量在这个过程中牺牲的性能、用户体验和商业机会？

隐性成本：内部开发者生态

构建跨平台框架时，最容易被低估的成本之一，就是维护它的开发者生态。

Apple 和 Google 在开发者生态上投入巨大，因为这些生态直接增强了它们的平台和业务。

但当一家互联网公司构建自己的跨平台框架时，实际上是在公司内部创建了另一个开发者平台。

它必须维护原生 API 桥接、UI 组件、构建工具、调试工具、测试基础设施、文档、SDK 集成，以及向后兼容性。

而这个内部生态必须持续跟进 iOS、Android 的演进，有时还包括 Web、小程序和 HarmonyOS。

这家公司不再只是在开发一个应用，而是在维护一个平台之内的平台。

使用 React Native 这样的成熟框架可以减轻这种负担，因为 Meta 和开源社区维护了它的大部分生态。但大型公司最终往往还是会围绕它构建大量内部基础设施。

那么，把这个生态自身的开发和维护成本算进去之后，它究竟节省了多少钱？

构建它，到底是因为业务需要，还是因为一个工程组织需要找些东西来做？

热更新与被制造的需求

跨平台和动态化框架在中国互联网行业如此流行，还有另一个原因：热更新。

许多公司希望更新应用时，不必每次都走传统的应用商店审核和发布流程。

对于那些不断开展营销活动、促销活动和频繁产品实验的公司来说，这尤其有吸引力。

但回头看，我有一个疑问。

用户真的需要这么多变化吗？

那些活动和持续迭代，真的创造了足以覆盖其成本的业务价值吗？

还是说，其中一些仅仅是被需要更多项目、更多活动和更多业绩的大型组织制造出来的？

一个能让不必要的开发变得更快的框架，并不一定能让公司更高效。

它可能只是让公司更擅长制造不必要的工作。

而且，无论工程基础设施变得多么精密，公司都无法靠上线更多功能来解决根本性的业务问题。

工程效率并不必然转化为业务效率。

应试型工程与被制造的复杂性

我在中国互联网行业还观察到另一个问题：一种应试型的工程文化。

中国的应试教育体系训练人们解决难题，却很少鼓励他们追问：这些问题是否本来就不该存在？

这种思维方式可能延续到工程组织之中。

有些工程师非常擅长解决复杂的技术问题，却很少质疑这些问题是否有必要解决。

有时，他们甚至会在没有问题的地方制造问题。

软件工程没有完美的架构，没有完美的框架，也没有普遍正确的解决方案。只要拿出足够多的论据、基准测试和精心挑选的权衡，几乎任何技术决策都能被合理化。

这给组织政治留下了充足的空间。

只要一个提案听起来在技术上合理，并让关键的人满意，工程团队就几乎可以为任何事情找到理由。

造一个新框架。重写一个现有系统。再引入一层抽象。创建一个新的技术标准。

然后，利用项目的复杂程度、参与工程师的人数，以及所谓的技术成就，来获得晋升。

目标不再是解决问题，而是制造值得拿来晋升的问题。

而且，因为不存在完美的架构，总会有另一个问题可以解决，另一个框架可以构建，以及另一个让组织继续忙碌的理由。

真正的问题——这一切是否创造了足以覆盖成本的价值——却往往被顺手忽略。

当工程复杂性成为晋升的通道，简单就成了威胁。

当抽象制造更多抽象

这里有一件近乎荒诞的事。

在某家中国互联网公司里，曾经同时存在多个跨平台框架。

最终，又有人开发了另一个框架，用来让这些已有框架彼此兼容。

想想这件事。

我们为了降低复杂性而构建抽象，然后又构建另一层抽象，来管理那些抽象制造出来的复杂性。

荒谬。

而这发生在 AI 编程智能体开始改变软件开发经济规律之前。

跨平台开发的经济账

这一切都可以用一个简单的公式来审视。

先定义变量：

• $V_{cross}$

  — 采用跨平台框架所带来的净经济价值。

• $C_{saved}$

  — 通过跨平台代码复用实际节省的开发与维护成本。

• $C_{complexity}$

  — 抽象、兼容性问题、调试和性能优化带来的额外成本。

• $C_{ecosystem}$

  — 维护开发工具、SDK、测试基础设施和平台 API 兼容性的成本。

• $C_{organization}$

  — 协调、官僚主义、组织政治和晋升驱动型项目带来的额外成本。

• $C_{opportunity}$

  — 上市延迟、平台 API 滞后、较差的用户体验，以及丧失平台差异化所带来的机会成本。

公式如下：

只有当跨平台框架实际节省的成本超过它引入的额外成本时，它才创造了正的经济价值。

而这在 AI 出现之前，就已经是一个值得追问的问题。

AI 时代跨平台开发的经济账

现在，来看看 AI 如何改变这个等式。

第一，AI 编程智能体正在大幅降低原生开发的成本。

因此，跨平台框架最初试图节省的开发成本正在缩小。

第二，新冷战和 AI 军备竞赛正在让原生平台能力变得越来越有价值。

端侧 AI，或者说边缘 AI，将不可避免地成为 iOS、Android 及其他计算平台的重要组成部分。

原生开发能更快地使用新 API，提供更好的性能、更容易的集成，以及对平台专属软硬件更直接的访问。

但还有另一个值得问的问题。

为什么 iOS 和 Android 应用一开始就应该一模一样？

Windows 和 Linux 应用不一定外观相同、行为一致。为什么移动应用就应该如此？

不同平台拥有不同的硬件、操作系统、AI 能力和用户预期。

未来几年，Apple 和 Google 将继续发展各自的端侧 AI 能力、模型、硬件加速、隐私机制和系统级集成。

为什么一个产品要把自己限制在这些能力的公共子集之中？

在技术竞争激烈的时代，平台特有的差异可以成为竞争优势，而不是有待消除的问题。

而当公司在性能、用户体验和创新速度上竞争时，开发成本的相对权重就会下降。

这提高了依赖跨平台框架的机会成本。

第三，AI 并不会消除跨平台框架引入的复杂性。

AI 编程智能体可以帮助开发者更快地构建原生模块、适配新 API，以及维护跨平台框架。

但写代码只是问题的一部分。

跨平台框架仍然会引入额外的运行时层、集成边界、兼容性要求和调试复杂性。

出问题时，开发者可能需要判断：问题来自操作系统、原生实现、框架，还是它们之间的集成？

AI 可以降低处理这些问题的成本，却无法让架构复杂性消失。

与此同时，AI 正在让原生开发变得更便宜，而且不需要那些额外的抽象层。

AI 降低了实现抽象的成本，却没有消除这些抽象引入的复杂性。

因此：

跨平台框架的经济价值正在受到两头挤压。

原生实现正在变得更便宜，而平台特有的能力正在变得更有价值。

复用核心，不一定复用整个应用

2024 年开发那款 ASR/TTS 应用时，我最终选择不使用跨平台应用框架。

我希望直接使用原生能力，包括 Core ML，以及围绕 Whisper 的 C/C++ 推理生态。

有意思的是，whisper.cpp 本身就是一个跨平台项目。

但这是一种本质上不同的代码复用。

在不同操作系统之间共享一个 C/C++ 推理引擎，与强行让整个应用经过同一套 UI 框架、运行时和开发者生态，并不是一回事。

原生 iOS 应用可以使用 SwiftUI 和 Core ML。原生 Android 应用可以使用 Kotlin 和 Android 特有的加速能力。两者仍然可以复用同一个推理核心中适合共享的部分。

跨平台代码复用，不等于跨平台应用框架。

我反对的不是共享代码，而是“共享整个应用的实现总能带来经济收益”这个假设。

而 AI 让这种区分变得越来越重要。

尴尬的中间地带

对于简单应用、内容驱动型产品和频繁更新的页面，为什么不直接使用 Web 技术？

Web 已经提供了一个成熟、受到广泛支持、拥有庞大开发者生态的平台。

对于功能丰富的应用，尤其是那些深度集成端侧 AI、硬件加速和操作系统能力的应用，为什么不使用原生开发？

跨平台应用框架正越来越尴尬地夹在中间。

当然，它们在某些场景下仍然有价值。一个小团队，如果在开发复杂度适中、对平台特有能力需求有限的应用，可能会从 React Native 或 Flutter 中获得很大收益。

但这种价值应当被证明，而不是被假定。

我们也应该停止把代码复用视为不容质疑的工程美德。

几十年前，Java 普及了“一次编写，到处运行”的理念。现代软件工程的很大一部分沿着同一个方向前进：引入抽象，降低支持不同平台的成本。

AI 正在改变这一决策背后的经济逻辑。

我们可能会再次为不同平台构建独立实现，不是因为忘记了过去的经验，而是因为实现本身的成本已经改变。

未来或许不是消除平台差异。

而是拥抱这些差异，同时让实现它们的成本大幅下降。

复用核心。自动化实现。保留平台特性。