Flutter 和 React Native 还在打，第三个竞争者已经悄悄从边上超过去了

Flutter 和 React Native 还在打，第三个竞争者已经悄悄从边上超过去了。

不是选哪个框架的问题，是选哪种思路的问题。

2026年的跨平台移动开发，看起来是 Flutter 和 React Native 两强争霸。但Kotlin Multiplatform（KMP）已经从第三的位置挤了上来，而且这次不是配角——它的玩法跟前两个完全不一样。

发生了什么

KMP 的采用率在一年内从 7% 跳到了 23%。这个数字本身不是最重要的，重要的是背后是谁在用：Airbnb 在 2025 年重新回到跨平台赛道，用的就是 KMP，六个月内实现了 95% 的代码共享，发版周期从每月一次变成了每周一次。McDonald’s 的应用每月处理 650 万次交易。Google Docs 的 iOS 版跑在 KMP 上。Cash App 已经跑了七年以上的 KMP 生产环境。这些不是实验项目，是日均百万级以上的真实流量。

KMP 这次真正突破的原因不是某一个功能，而是三个变化同时发生：JetBrains K2 编译器让编译速度提升了 40% 以上；Google 把 Room、DataStore、ViewModel 这些第一方库全部迁移到了 KMP；2025 年 5 月，Compose Multiplatform 的 iOS 版正式标记为稳定版，96% 的早期测试团队没有报告重大性能问题。

Flutter 的思路是「我自己画所有像素」，React Native 的思路是「我直接用原生组件」，KMP 的思路是「我只共享业务逻辑，UI 交给每个平台自己画」。这三个思路在 2026 年已经各自找到了自己的生态位，不再是相互替代关系。

为什么 iOS 团队现在开始愿意接受它

这是关键的变化。

早期 KMP 在 iOS 侧最大的问题是：iOS 开发者要接触 Kotlin，要学会阅读和调试 Kotlin 代码，而 Xcode 对 Kotlin 的支持基本为零。这是一个文化壁垒，不只是技术壁垒。

Booking.com 在迁移自己的实验框架时做了一件很聪明的事：他们把 Kotlin 代码编译成预编译二进制，通过 CocoaPods 分发，iOS 工程师完全不需要接触 Kotlin 源码，只需要调用接口。迁移期间启动时间增加了约 140 毫秒，App 体积增加 2.5MB，验证完成后实际 iOS 启动时间反而变快了，因为 Kotlin 协程比原来的 Objective-C 线程模型表现更好。

Booking.com 还设立了明确的「退出机制」：如果 KMP 在指定指标上失败，项目直接撤回原生 Swift 重写。这个机制消除了沉没成本焦虑，反而让 iOS 团队更愿意认真评估。

Swift Export 是最后一块拼图。JetBrains 在 Kotlin 2.2.20 引入了直接 Swift 导出，不再经过 Objective-C bridging header，Swift 开发者可以直接调用看起来像原生 Swift 的 KMP 代码。这一步解决了 KMP 在 iOS 侧最后一个工程层面的摩擦点。

现在的局面是：KMP 在 Android 侧是完全原生体验，在 iOS 侧已经有可行的工程路径，在商业逻辑共享上的效率已经被 Booking.com、Airbnb、McDonald’s 多个大型项目验证过了。

什么时候选 KMP 而不是 Flutter 或 React Native

KMP 适合：你的团队有强 Kotlin 背景，主要维护 Android 应用，iOS 侧是并行维护而不是核心优先，想先共享业务逻辑而 UI 保持原生体验。KMP 在这个场景下的ROI是最高的——团队不需要学新语言，可以直接用现有 Kotlin 技能覆盖双端业务逻辑。

Flutter 适合：你要做设计系统高度统一的产品，UI 自定义程度高，有大量自定义动画和视觉组件，团队没有现有平台包袱可以从零开始学 Dart。

React Native 适合：团队有 React 和 JavaScript 背景，要和现有 Web 前端共享代码，追求最大的招聘池。

KMP 还有一个实际优势：对现有代码库的侵入性最低。你可以从一个模块开始，不需要重写整个应用，不需要切换主语言。Booking.com 的做法是把一个实验框架先用 KMP 重写，然后和旧实现并行跑了几个月，验证输出一致后再切换。这是可以在生产环境中操作的渐进式迁移，而不是一次性的豪赌。

接下来的问题是：你的团队是哪种情况？