适用于 iOS 的 Kotlin Multiplatform
iOS 版 Kotlin Multiplatform：关于集成、性能和工作流的误解
如果你已经从事 iOS 应用开发多年，你可能会有这样的疑问：使用 Kotlin Multiplatform 会损失性能吗？我是否在放弃 Swift 的强大功能和优雅特性？开发者体验会不会像是在使用某种“二等公民”式的权宜之计？这些是大多数资深 iOS 工程师在面对 KMP 时都会提出的问题。
本文根据实际使用经验，剖析了 iOS 开发者对 Kotlin Multiplatform 最常见的一些顾虑，旨在让你对 Kotlin Multiplatform 的 iOS 开发实际感受有一个切实的了解。
Kotlin Multiplatform 对 iOS 开发者意味着什么
Kotlin Multiplatform 是一项允许你按需共享代码的技术——从单个模块到大部分业务逻辑，甚至在合适的情况下，还可以使用 Compose Multiplatform 共享 UI。
它并不是要取代原生开发。相反，KMP 让你在跨平台共享代码的同时，能够完全控制哪些部分保持原生。
在最高层面上，KMP 赋能团队能够：
- 无缝共享业务逻辑。
- 让 Kotlin 代码可以从 Swift 中调用。
- 在 Kotlin 代码中充分利用 iOS API 的强大功能。
- 使用 Compose Multiplatform 创建可以嵌入 SwiftUI 的屏幕，或者完全用 Kotlin 构建整个用户界面。
- 直接从 Kotlin 代码中使用 MapKit 或 AVFoundation 等平台特定框架。
KMP 仅仅是又一个跨平台抽象层吗？
并非如此——KMP 不会取代 SwiftUI 或 UIKit。相反，它是对原生开发的补充。
在实践中，这意味着你可以：
- 利用原生 Swift 代码，在 SwiftUI 或 UIKit 中创建 UI。
- 直接访问 iOS API，无需包装器或间接层。
- 在任何有价值的地方集成共享代码，而不是默认在所有地方集成。
KMP 对 iOS 开发者真的有用吗？
虽然 KMP 是 Kotlin 生态系统的一部分，但它并不仅限于 Android——它是一种在跨平台共享功能的通用方法，iOS 团队可以根据自己的需求来使用它。
对于面临逻辑重复、跨平台行为不一致以及维护成本不断攀升的团队来说，它尤为有用。使用共享层可以消除重复，同时保持完全的原生控制。
核心原则很简单：
- 共享合理的部分，例如业务逻辑、数据和网络。
- 保持必要的部分原生，例如平台特定的功能，并根据每个项目决定 UI 是共享还是原生。
- 随着时间的推移，根据需要调整这种平衡。
Kotlin Multiplatform 不是一个以 Android 为中心的解决方案；它是一项通用的技术，可以帮助开发团队在不损失原生体验的情况下提高一致性。
关于 KMP 的性能、复杂性和原生控制权丧失的误解往往流传甚广，但这些并不能准确反映它的实际工作方式。让我们用基于经验的答案来逐一化解这些误解。
误解：跨平台框架会损害 iOS 的性能和体验
一个常见的顾虑是 Kotlin Multiplatform 会损害 iOS 应用的性能或体验。这种假设通常源于以往使用 React Native 等带有桥接器或专有运行时的框架的经验。
KMP 的运行方式不同。它使用 LLVM（与 Swift 相同的工具链系列）为 iOS 生成共享代码。这里没有 JavaScript 桥接，没有集成的运行时层，在你的代码和 iOS 之间也没有抽象。这意味着你的应用将继续作为完全原生的二进制文件运行，其性能特征与典型的 iOS 开发保持一致。
误解：Kotlin Multiplatform 是一项小众或有风险的技术
你可能仍然会将 Kotlin Multiplatform 与其早期的实验阶段联系在一起。然而，Kotlin Multiplatform 已于 2023 年 11 月正式达到 Stable 状态，并已在所有支持的平台上实现生产就绪。KMP 已被 许多知名公司用于真实的、大规模的 iOS 应用程序中，例如 Google、Duolingo、Booking.com、Sony、Philips 和 McDonald's。
生态系统也在持续成熟：用于 iOS 的 Compose Multiplatform 已在 2025 年达到 Stable 状态，使得除了共享业务逻辑外，构建生产就绪的共享 UI 也成为可能。根据 2025 年 Kotlin Multiplatform 调查，KMP 现在被认为具备生产可行性，约 70% 的插件用户表示满意或非常满意，约 80% 的用户正在使用 Compose Multiplatform。
KMP 由 Kotlin 的开发者 JetBrains 提供支持。它不是一个边缘项目，而是一项战略投资，将通过强大的工具、定期更新和不断增长的生态系统支持持续演进。
误解：Kotlin Multiplatform 仅适用于 Android 开发者
Kotlin Multiplatform 常被感知为“Android 优先”，iOS 开发者只是顺带参与。
Kotlin 是一种通用语言，KMP 中的共享代码只是代码库的另一个方面，并不是由单一平台拥有的。iOS 开发者可以阅读并贡献代码，塑造 API，并影响跨平台设计。
在实践中，各团队采用不同的模式。许多 iOS 开发者继续主要使用 Swift 工作，尤其是在 UI 密集型功能上，而共享业务逻辑则由团队协作开发，或由专注于跨平台代码的工程师开发。
这带来了更好的协作：团队共同拥有逻辑的所有权，减少了不一致性，并能一次性修复问题，避免了重复劳动。
误解：我的 iOS 工作流将变得更加复杂
关于 KMP 的主要顾虑之一是它可能会干扰已建立的 iOS 工作流。如果你已经经历了 Objective-C → Swift → SwiftUI 的转变以及不断的工具链更迭，增加“又一个东西”的想法可能会让人感到疲惫。这种顾虑是合理的，这也正是 Kotlin Multiplatform 被设计为渐进式采用而非一蹴而就的原因。
你不需要一夜之间接受一套全新的工具链。对于许多 iOS 开发者来说，可以从仅消费一个共享模块开始使用 KMP。这意味着在评估其有用性时，你的日常工作流可以保持相对不受影向。
随着深入使用，学习曲线是平缓的，而非全盘接收：
- 从使用共享的 Kotlin API 开始。
- 学习足够的 Kotlin 知识以阅读和排查共享代码。
- 在合适的情况下为共享逻辑做贡献。
误解：Kotlin Multiplatform 会生成不地道的 Swift API
Kotlin Multiplatform 中的 Swift 互操作性仍然是一个受关注的问题。目前，Kotlin 代码是通过 Objective-C 桥接呈现给 iOS 的，这可能会让 Swift API 感觉不够自然，特别是在命名、为 null 性、泛型或异步模式方面。
是的，如果管理不当，它确实感觉不像 Swift。然而，如果在开发共享代码时考虑到 iOS，构建优秀的 Swift API 是可能的。以下是一些最佳做法：
- 保持 API 简单且目标明确。
- 避免无法正确转换的 Kotlin 模式。
- 根据需要添加薄薄的 Swift 包装器。
- 直接在 Xcode 中验证 API。
你还可以观看演讲录像“Kotlin Multiplatform 炼金术：让你的 Swift 互操作点石成金”。
Kotlin 的新工具——特别是 Swift Export ——正在迈向一个未来的愿景，即 Kotlin API 将更直接、更地道地与 Swift 集成，从而进一步减少摩擦。
Swift Export 旨在移除 Objective-C 层，而 Interopedia 则作为实用文档，帮助开发者了解 Kotlin 代码是如何暴露给 Swift 的，以及应该预期哪些模式。像 KMP-NativeCoroutines 和 SKIE 这样的库更进一步，磨平了当前互操作模型中的棱角，改进了协程映射到 Swift async/await 的方式，并使生成的 API 对 Swift 更加友好。
误解：共享 UI 意味着失去原生的 iOS 体验
一种普遍的错觉是，使用 Kotlin Multiplatform 需要放弃完全原生的 iOS UI。事实并非如此。
KMP 根本不要求共享 UI。你可以只共享底层功能，而让其余部分保持原生：
- UI 可以使用 SwiftUI 或 UIKit 编写，利用原生 Swift 代码。
- 动画和交互可以保持完全原生。
- 平台 API 可以直接访问，无需包装器。
你必须使用共享 UI 吗？
这一策略完全是可选的，由每个团队自行定义。核心前提很简单：Kotlin Multiplatform 不会限制你设计界面的方式。你可以使用 SwiftUI 或 UIKit 保持完全原生的 UI，使用 Compose Multiplatform 引入共享 UI，或者根据你的需求结合这两种方法。
你最常用的屏幕（如仪表板 and 核心产品流程）通常最好使用完全原生的 UI 实现，这样可以发挥最大性能和平台特定的打磨。对于影向力较低的区域，Compose Multiplatform 非常契合。诸如设置页面或不常使用的流程（如身份验证）是共享 Compose UI 的理想候选，在这些地方，开发速度和代码重用比深度原生优化的需求更重要。
重要的是，Compose Multiplatform 与传统的 iOS UI 之间存在互操作性，这意味着你可以将共享组件与原生视图并排嵌入，或者随着时间的推移逐步采用它们。这允许团队在不预先承诺单一方法的情况下演进其 UI 策略。
误解：采用 Kotlin Multiplatform 意味着不再需要 Swift
一个常见的担忧是，引入 Kotlin Multiplatform 会使 Swift 变得过时。但 KMP 并不是来取代它的——Swift 仍然是 iOS 开发的核心。
你继续为所有让 iOS 应用感觉像 iOS 的部分编写 Swift 代码：
- 使用 SwiftUI 或 UIKit 的 UI。
- 导航、动画和用户交互。
- 平台特定的功能和集成。
- 应用生命周期和系统 API。
KMP 只是在旁边增加了一个共享层。这意味着 iOS 开发者继续拥有原生体验，共享业务逻辑通常是跨平台的共同努力，一些 iOS 工程师会贡献 Kotlin 代码，而另一些则主要关注 Swift。
在现有项目中集成 Kotlin Multiplatform iOS
在现有应用中进行 Kotlin Multiplatform iOS 集成的最佳方法是从小处着手。你不必推翻重做应用、重构一切，也不必从第一天起就致力于全盘跨平台。
在现实中，共享模块通常以以下形式提供给 iOS：
- 从通用代码创建的框架。
- 用于在构建目标中部署的 XCFramework。
- 根据团队的工作流，可能会使用 Swift Package Manager 集成依赖项，或者采用自定义设置。
关键点在于集成并不是天生具有侵入性的。你并没有替换应用的架构、UI 层或现有的 Swift 代码。你正在创建一个共享模块，你的 iOS 代码可以在任何合理的地方使用它。
这就是为什么一个切实的起点通常是一个小的、低风险的区域，例如：
- 数据模型
- 验证逻辑
- 网络
- 单个功能模块
这允许团队在保持原始 iOS 体验的同时，观察 KMP 如何适配代码库。大多数团队选择渐进式采用：他们引入通用代码来解决特定问题，然后仅在收益切实可见时才进行扩展。这使得所有权易于维护。
何时适合（以及何时不适合）使用 Kotlin Multiplatform
当 iOS 和 Android 逻辑之间存在重叠，且这种重复开始带来困扰时，Kotlin Multiplatform 就非常有意义。对于那些希望在跨平台共享业务规则、网络、数据处理或领域逻辑的同时保持原生 iOS 体验的团队来说，它尤为有价值。
KMP 通常在以下情况下是 理想选择：
- iOS 和 Android 应用使用相同的基础产品逻辑。
- 团队需要两次修复相同的错误。
- 平台行为持续出现不同步的情况。
它在以下情况下可能 不太适合：
- 应用程序具有高度的平台特定性。
- 大部分复杂性存在于 UI 层。
- 没有足够的逻辑来证明额外的设置和协调成本是合理的。
结论
使用 KMP，你可以减少重复，同时增加一个需要维护的共享层。你在实现一致性的同时，引入了跨团队协调，并保持了原生 UI，但需要接受一定的互操作性和工具复杂性。
当共享代码能提供清晰的价值时（无论是小的、专注的逻辑片段还是较大的领域层），且不逾越到那些由平台处理更好的领域时，Kotlin Multiplatform 的效果最佳。
常见问题解答
Android 和 iOS 之间实际可以共享多少代码？
没有固定的百分比；大多数团队共享业务逻辑、网络和数据层。确切的数量取决于你的应用以及平台之间的重叠程度。带有 Compose Multiplatform 的 Kotlin Multiplatform 允许你共享多达 100% 的应用代码（包括 UI），同时仍然可以与原生 API 集成。
Kotlin Multiplatform 会影响 iOS 应用性能吗？
没有内在影响。共享代码是原生编译的，因此性能与典型的 iOS 代码相当。
Kotlin Multiplatform 如何与 Swift 配合工作？
共享的 Kotlin 代码会被转换为 Swift 可以使用的原生框架。在当前的模式中，互操作性依赖于 Objective-C 桥接，这可能会引入一些摩擦。展望未来，这一点正在演进：JetBrains 的 Swift Export 旨在完全移除 Objective-C 层，从而实现与 Swift 更加直接、地道的集成。
iOS 开发者需要学习 Kotlin 才能使用 KMP 吗？
不一定。你可以从消费共享的 Kotlin 代码开始，然后在需要调试或做贡献时逐步学习 Kotlin。
我必须通过 Kotlin Multiplatform 共享 UI 吗？
不，UI 共享是可选的。许多团队保持 iOS UI 完全原生，仅共享底层功能。但由于在 iOS 上的效果非常自然，越来越多的公司选择共享 UI 代码。