Kotlin 跨平台(KMP)在 iOS 端的实践与挑战

Kotlin 多平台（简称 KMP，也常被称为 KMM/Mobile 等）已投入生产环境多年，JetBrains 还整理了一份当前采用 KMP 技术的企业清单。

自我们熟知的移动平台诞生以来，“跨平台多端开发”就一直是市场热点——Cordova、Xamarin 等技术都曾尝试提供统一开发框架，核心思路是“一次编写，多端部署”，本质目标是降低开发成本。

但维护单一代码库的价值远不止“节省开支”，还包含以下优势：

质量提升：单一代码库更易于维护和审计，无需为不同平台单独开发，像 Bug 修复这类工作的效率会显著提高。
技术栈统一：招聘技术人才本就不易，资深工程师更是稀缺资源；让他们频繁切换技术栈更是难上加难。统一技术栈能减少团队对特定平台的依赖，同时降低招聘和维护成本。
按功能划分团队：移动端开发中常见“按平台分组”（如安卓组、iOS 组），但按功能模块分组会更聚焦——团队能深入理解某一功能的完整实现逻辑，长期来看效率更高。而统一技术栈正是实现这种协作模式的前提。

在 Android 团队中，KMP 的接受度很高，因为它的编程语言和大部分工具链都与安卓生态系统共享。JetBrains 的一次调研中可以看到 KMP 对于 Android 项目的代码占比非常乐观：

你的项目中，KMP 代码的复用率是多少？（数据范围：0%-100%）

0%-10%：18%
10%-30%：12%
30%-50%：27%
50%-70%：30%
70%-90%：20%
90%-100%：48%

近半数 KMM 用户（48.4%）的代码复用率超过 50%。

另外，采用 KMP 后，99% 的用户对性能、包大小、稳定性等方面的表现表示满意。

不过，若按平台拆分数据，结果可能会有所不同——iOS 开发者使用 KMP 会面临更多困难，这也是本文要探讨的“KMP 在 iOS 端的痛点”。

1. iOS 端调试难题

目前，iOS 端调试 KMP 代码主要有两种方式：

通过 Xcode 的 Kotlin 插件（由 Touchlab 开发，需在 Xcode 中安装）
通过 JetBrains 的 AppCode（需在 AppCode 中安装 Kotlin Multiplatform Mobile 插件）

Touchlab 为 Kotlin 和 KMP 社区做出了诸多贡献，但 Xcode 的 Kotlin 插件并不完美：自动补全失效、不同 Xcode 版本下出现崩溃等问题时有发生。毕竟这是第三方开发的插件，而苹果本身并不支持 Kotlin 生态，未来大概率也不会提供支持。而 KMP 依赖许多 JetBrains 无法控制的框架和平台。当新的安卓/iOS 版本、新的 Swift 版本发布时，代码可能会出现兼容性问题。

AppCode 是 JetBrains 开发的 Swift 开发 IDE，部分功能甚至比苹果官方的 Xcode 更强大（例如代码重构），界面和工具链也更友好。但它并非苹果官方 IDE，缺少“界面设计”等核心功能。

因此，目前 iOS 端调试 KMP 代码尚无完美方案，体验仍较为繁琐。

2. 基于 Objective-C 的互操作性限制

KMP 与 iOS 进行交互的桥梁是 Objective-C（而非 Swift），这会带来很多兼容性成本，典型问题可能包括：

枚举类型不兼容

Objective-C 中的枚举是“整数类型”，而 Kotlin 中的枚举是“引用类型”。若直接将 Swift 枚举映射到 Kotlin，会出现类型不匹配问题（Swift 枚举的实例数量有限，而 Kotlin 枚举无此限制）。

默认参数不可用

Swift 支持函数的“默认参数”，例如：

funcsample(name: String, nice: Bool = true) {if nice {print("hello \(name)!")    } else {print("no, it's \(name) again..")    }}

调用时可省略 nice 参数，直接使用默认值：

sample("Enrique")sample("Enrique", nice: false)

但 KMP 依赖 Objective-C 互操作性，而 Objective-C 不支持默认参数。因此，KMP 生成的代码中无法使用默认参数，必须显式传入所有参数。

3. 部分 iOS API 不支持

举个例子，比如 Codable 是 Swift 引入的序列化 API，用于将数据与 JSON 格式相互转换。Kotlin 本身拥有序列化工具（kotlinx.serialization），但通过 KMP 导出的 Kotlin 类无法直接生成 Codable 实现。

虽然技术上可以手动实现 Codable，但这违背了“使用 KMP 减少重复代码”的初衷。对于 Swift 开发者而言，无法使用 Codable 可能会让他们对 KMP 望而却步。

4. 原生依赖支持有限

Kotlin/Native 可与 CocoaPods 依赖管理器集成（CocoaPods 是 iOS 生态的主流工具），但如果项目依赖其他库，KMP 目前不提供支持（YouTrack 上已有相关需求提交）。

5. 并发模型复杂

KMP 的并发和内存模型较为复杂，这会导致不同平台间的行为不一致——相同的代码在不同端可能表现不同。不过目前协程实现了多线程支持，这一问题得到解决。

此外，“冻结对象（frozen objects）的工作原理”“如何处理不可变对象”等概念也容易让人混淆，对开发者来说学习成本较高。

KMP 适合投入生产环境吗？

适合——JetBrains 的调研数据已证明这一点，已经有不少企业都已在生产环境中使用 KMP。

但作为一项前沿技术，使用时仍需谨慎（毕竟 KMP 依赖许多 JetBrains 无法控制的框架）。在大规模落地前，建议先做好以下准备：

谨慎试用：无需直接进行 100% KMP 改造，可先在小模块中试点，评估实际收益。
共享组件先行：KMP 的核心价值是“代码共享”，因此可先从项目中可复用的组件入手（如业务逻辑、数据层），验证 KMP 是否能真正提升开发效率。
关注版本兼容性：KMP 本身迭代速度较快，版本更新可能影响稳定性。不过 JetBrains 维护了一份“Kotlin 组件当前稳定性”清单，可结合该清单与团队实际情况，判断 KMP 是否满足需求。

-- END --