上一篇文章讲 KMP 正在抢 Flutter 地盘，没想到评论区比文章还精彩。

Jerry 留言说：“所有跨平台框架都会死，因为 AI 分分钟给你翻译过去……实现 iOS/macOS，翻译成 android/windows，不香么？”

boyang 接了一刀：“还有 swift UI for android sdk. RN 必死。Flutter 和 dart 死亡也是时间问题。”

这两条评论代表了很多工程师的潜台词——跨平台框架的存在意义是什么？如果 AI 能把代码从一个平台翻译到另一个平台，那我们还需要 Flutter、KMP、RN 这些东西吗？

这是个值得认真讨论的问题，不是几句话能打发的。

先说"AI 翻译代码"这个论断

Jerry 的逻辑简洁：写一份代码，AI 负责翻译成多平台版本，跨平台框架就没存在必要了。听起来很有道理，但这个逻辑成立的前提是什么？

首先，代码翻译和代码运行是两件事。把 Swift 翻译成 Kotlin，AI 已经能做到相当的程度——语法映射、API 对应、设计模式转换，这些都有规律可循。但翻译完你得能跑起来，跑起来还得表现一致，这就麻烦了。

iOS 上 UIScrollView 的惯性滚动行为和 Android 上 RecyclerView 的滚动机制，语义相近但底层完全不同。AI 把 Swift 代码翻译成 Kotlin，它知道把 UITableView 换成 RecyclerView，但复杂的手势冲突、自定义动画、与系统组件的交互，翻译出来的结果大概率需要大量人工校正。

其次，翻译是一次性的还是持续的？

实际工程中，代码不是写完就不动了。业务持续迭代，每次改动都需要双端保持同步。如果依靠 AI 翻译，相当于每次改动都走一遍"翻译 → 验证 → 修正"的流程。这个流程有多贵，取决于代码复杂度和测试覆盖度。对于规模不大、迭代频率低的项目，可能真的可行。对于百人团队维护的核心 App，这条路非常陡峭。

第三，翻译的边界在哪？

UI 层的代码翻译相对容易，因为声明式 UI 框架（SwiftUI、Jetpack Compose）在抽象层次上越来越接近。但业务逻辑层涉及并发模型、协程机制、状态管理方式的差异，翻译成本会急剧上升。平台差异的本质不是语法，而是运行时模型的差异。AI 可以翻译代码，但不能消除两个平台在运行时层面的根本分歧。

所以，Jerry 的判断有一定道理，但"分分钟"这个时间尺度明显乐观了。AI 代码翻译会成为跨平台开发的一个补充手段，但在现阶段（以及可预见的几年内）不太可能成为主流工程实践。

RN 的处境：真的在走向终点

boyang 说 RN 必死，这个判断其实已经越来越接近行业共识了。

React Native 的架构问题由来已久。旧架构（Bridge 模式）的性能瓶颈在复杂列表、动画、手势这些场景下暴露得非常明显。Meta 用了将近五年推进新架构（New Architecture / JSI + Fabric + TurboModules），迁移路径漫长且充满兼容性坑。

更大的问题是生态的离心力。大量 RN 项目在实际落地中选择了 Expo 这条路，Expo 的体验越来越好，但它本质上是在 RN 之上又加了一层抽象，进一步拉大了与原生能力之间的距离。而随着 Flutter 和 KMP 的成熟，很多新项目直接跳过了 RN。

从技术选型的角度看，RN 的核心竞争力一直是"前端工程师可以写移动端"。但这个优势在 2026 年明显弱化了：

• 前端团队对移动端体验的要求越来越高，RN 的性能天花板越来越碍眼

• Dart 和 Kotlin 的学习曲线对前端工程师来说并没有高到拒绝的程度

• AI 辅助编码降低了学习新语言的成本，"会 JS 才能上手"的壁垒变低了

• Meta 自己的 App 已经在系统性地迁离 RN，信号意义明显

说 RN 会在未来几年内消亡可能还早，但它的市场份额在持续收缩是事实。对于新项目，选 RN 需要给出比以前更充分的理由。

Flutter 的真实处境：活得好，但天花板越来越明显

Flutter 现在的状态是"健康但焦虑"。

健康的部分：全球范围内有大量 Flutter 应用在生产环境运行，Impeller 渲染引擎解决了历史遗留的 Jank 问题，Dart 3 的性能和类型系统都有显著改善，社区生态相当活跃。Google 在 I/O 上持续投入，Flutter 并没有被边缘化的迹象。

焦虑的部分，来自几个方向：

Dart 的孤立性。 Dart 是个好语言，但它是 Flutter 专属的。学了 Dart，能用的地方就是 Flutter。这和 Kotlin 形成了鲜明对比——Kotlin 在 Android、服务端（Ktor、Spring）、数据科学领域都有真实的使用场景。这种语言的通用性，对工程师的职业发展有实际影响，会影响团队招聘和技术选型决策。

与原生生态的摩擦。 Flutter 的渲染是完全自绘的，这是它在视觉一致性上的优势，但也是它与平台原生组件产生摩擦的根源。文字输入、无障碍支持、键盘行为、平台特有的 UI 组件——这些地方 Flutter 处理起来要么需要大量适配代码，要么体验有明显的"不像原生"的感觉。

Web 和桌面的尴尬。 Flutter for Web 出来几年了，但实际上很少看到高质量的 Flutter Web 应用进入生产。性能、SEO、首屏加载都是硬伤。桌面端（Windows、macOS、Linux）也是类似的情况——Flutter 可以运行，但和原生桌面应用的体验差距相当明显。

Flutter 的定位越来越清晰：它是一个优秀的移动端跨平台 UI 框架，专门为那些需要"双端像素级一致"体验的产品而生。一旦跳出这个场景，优势就开始消退。

KMP 在 2026 年的真实选型价值

KMP（Kotlin Multiplatform）在这几年的变化是最值得深聊的。

KMP 的核心设计哲学和 Flutter 截然不同：Flutter 是"一套 UI 框架跑所有平台"，KMP 是"共享业务逻辑，各平台保持各自原生 UI"。这两条路线对应不同的权衡取舍。

KMP 的优势体系：

• 业务逻辑、网络层、数据层完全共享，这部分代码量在中大型 App 里占 40-60%

• 各平台 UI 完全原生，没有任何体验上的妥协

• Kotlin 语言本身有广泛用途，团队投入有复利

• JetBrains 工具链（IntelliJ、Android Studio）对 KMP 的支持已经非常成熟

• 与现有 Android 代码库的渐进式迁移路径非常顺滑

KMP 的短板也很明确：

• UI 不共享，iOS 端需要写 SwiftUI，双端 UI 工作量不减少

• Compose Multiplatform 虽然可以共享 UI，但在 iOS 端仍有坑（自定义字体、键盘适配、原生组件互操作）

• iOS 团队如果不会 Kotlin，初始学习成本不低

• 生态库的覆盖面不如 Flutter，尤其是 UI 组件库

用一个具体的判断维度来说：

如果你的团队以 Android 工程师为主，业务逻辑重，UI 定制化要求高，需要和平台原生能力深度集成，KMP 是目前最合理的选择。

如果你的产品需要视觉高度一致（两端 UI 规格一模一样），团队是跨平台背景，没有强烈的原生 UI 诉求，Flutter 依然是高效的选择。

两者并不是非此即彼的关系。实际上有不少团队在用"KMP 共享逻辑层 + Flutter UI"的混合方案——把 KMP 当做 Kotlin 写的业务 SDK，Flutter 负责 UI 展示，通过 Platform Channel 打通。这个组合相对复杂，但在某些场景下能把两个框架的优点同时拿到。

SwiftUI for Android：原生跨平台的另一条路

boyang 提到的"SwiftUI for Android SDK"是苹果在 WWDC 2025 上的一个重磅信号。

苹果通过开源 Swift Foundation 库，使得 SwiftUI 理论上可以在 Android 和 Linux 上运行。这个方向如果成熟，意味着 iOS 开发者可以用 Swift 写一套代码，覆盖 iOS、macOS 和 Android——这是"原生跨平台"路线的一个全新选项。

但必须泼一盆冷水：目前这个方案距离生产可用还很远。

• Android 端的 Swift 工具链支持非常初级，Xcode 不能编译 Android 目标

• SwiftUI 在 Android 上如何访问 Google Play 服务、Android 系统 API，目前没有清晰方案

• 包管理、调试、性能分析工具链在 Android 端几乎是空白

• 苹果的动力到底有多强？开放 Android 支持对苹果的商业利益并不明显

更合理的预判是：SwiftUI for Android 在 2-3 年内会成为一个可以玩的技术，但不会成为 iOS 团队向 Android 扩展的主流选择。它更可能的应用场景是 macOS/iOS 双端共享（这已经是成熟路线），而不是 iOS/Android 全平台覆盖。

但这个方向的信号价值很高：它说明连苹果都在往"一套代码多平台运行"的方向走，原生跨平台（相对于 Flutter 这样的虚拟渲染跨平台）会是未来几年的主要技术演进方向。

跨平台框架的"死法"：被谁干掉？

综合来看，跨平台框架面临的威胁来自两个方向，但性质很不一样。

威胁一：AI 代码翻译

前面分析过了。AI 翻译会降低跨平台框架的吸引力，因为它让"维护两套代码"的成本下降了。但这种影响是渐进式的，不是颠覆式的。在 AI 能完全可靠地做到"翻译 + 验证 + 同步迭代"之前，跨平台框架的存在理由不会消失。

更现实的情况是：AI 会让初级的跨平台适配工作自动化，但复杂的平台深度集成（相机、蓝牙、推送、支付）依然需要人工介入。跨平台框架的价值从"节省代码量"部分转向"提供稳定的抽象层"。

威胁二：原生跨平台成熟

这个威胁更致命，因为它解决的是跨平台框架的根本矛盾——"体验妥协"问题。

KMP 的模式是"原生 UI + 共享逻辑"，SwiftUI for Android 的方向是"苹果原生框架跨到 Android"，Google 在 Compose 上的投入也在持续加深 Android 原生的能力壁垒。这些力量合在一起，指向一个未来：平台的原生 UI 框架会越来越强，强到覆盖跨平台需求，同时业务逻辑共享通过 KMP 这样的工具解决。

在这个未来里，Flutter 的核心价值（自绘 UI、完全一致的跨端视觉）会变得越来越小众。不是死掉，是被边缘化到特定场景——比如游戏 UI、超高定制化工具类 App、海外市场双端需要高度一致的产品。

RN 面临的威胁则两个都有。AI 翻译让"前端工程师可以写移动端"的价值降低，原生跨平台成熟让它的技术路线越来越尴尬。RN 的衰退是结构性的。

给工程师的实际判断建议

说了这么多，最后落到具体的决策建议。

根据团队背景和产品类型，可以用下面这个简单框架来判断：

场景	推荐方案	核心理由
Android 为主，需要 iOS	KMP + SwiftUI	逻辑共享，UI 各自原生
强视觉一致性，设计主导	Flutter	像素级一致，快速迭代
全栈前端团队，移动权重低	Expo/RN（短期）或 KMP	RN 过渡用，长期看 KMP
iOS 为主，想覆盖 Android	KMP 或等 SwiftUI for Android	SwiftUI for Android 观察中
Web + 移动都要	原生各自做，或 Flutter（审慎）	Flutter Web 体验仍有限

几个补充建议：

• 不要在新项目里选 RN，除非团队已经深度 RN 且迁移成本极高。

• Flutter 不用急着迁移——如果跑得好，继续跑，但新项目要认真评估 KMP 路线。

• KMP 的 iOS 团队上手门槛被高估了。Kotlin 对 Swift 开发者来说并不陌生，现代 IDE 支持足够好，一个 iOS 工程师学 KMP 共享层一般两周内可以上手。

• AI 编码工具（Cursor、GitHub Copilot、Gemini Code Assist）会持续降低跨语言开发的学习成本，这是支持"走原生跨平台"方向的额外理由。

• 不要赌单一框架的长期存活，架构设计上尽量隔离 UI 框架依赖，保留切换的灵活性。

最后说几句

Jerry 和 boyang 的评论都触到了真实的技术趋势，但结论有些过于决绝。技术工具的消亡很少是因为被另一个工具"直接干掉"，更多是场景收窄、生态离心、新项目不再选择，然后在几年内慢慢淡出视野。

RN 的问题是真实的，它已经进入这个衰退通道了。Flutter 的问题是被边缘化而不是死亡，它会在特定场景里继续活得不错。KMP 的崛起是真实的，它代表了"原生跨平台"这条路线的成熟。

AI 代码翻译是一个长期趋势，但它改变的是开发效率，而不是框架的存在逻辑。只要平台差异存在，只要 iOS 和 Android 有各自的运行时模型和 UI 范式，就需要某种形式的"跨端解决方案"——无论是框架、工具链，还是 AI 辅助的多端同步流程。

值得继续观察的方向是：当 AI Agent 真的可以持续维护两套平台代码的同步（不是一次性翻译，而是每次 commit 后自动做双端适配和验证），跨平台框架的价值会怎么演变？这个问题的答案，可能在 2027-2028 年会开始清晰起来。

原文读者评论来自《别再说 Flutter 是唯一选择了——KMP 正在悄悄抢走它的地盘》（陆业聪，2026-04-02）