提升Kotlin/Native在iOS上的研发体验至一等公民水平

Question

作为KMP技术与实践系列的第四篇，本文聚焦于如何在iOS平台上将Kotlin/Native的研发体验提升到一等公民水平，即追平乃至超越Apple官方基于ObjC和Swift的研发范式。

Make the iOS Target a Pleasure to Work With

提升iOS目标开发的愉悦感，是KMP 2025官方路线图中明确提出的核心优先级第一位，其根本原因在于当前体验的“不愉悦”。我们团队作为重度依赖KMP技术的实践者，也将此问题置于最高优先级。

愉悦的定义可归结为最短的“改一行代码 → 看到结果”的内环反馈周期，涵盖编码、构建和调试三大环节：

然而，KMP官方生态在iOS平台的现状存在明显短板：

编码体验：尽管IDEA体系对Kotlin-Native提供了较好的支持，但多数iOS开发者仍使用Xcode，而官方推荐的黑盒交付方式（仅将xcodebuild作为容器）导致编译调试和调试器信息回环不够自然。
构建系统：KMP官方编译系统基于Kotlin Gradle Plugin（KGP），而Gradle在iOS生态中普及度低，且KGP的增量编译速度、稳定性和可预测性均不理想，难以实现“Never clean build”的目标。
调试体验：官方生态因与xcodeproj体系脱节，依赖第三方插件桥接，导致调试符号的source-map映射和konan.lldb.py版本映射等问题，使得调试体验大打折扣。

造成这一现状的核心原因是iOS社区工程化路径的割裂（如CocoaPods、SPM、Tuist等），缺乏统一标准，KMP难以对所有路径深度适配。因此，我们的目标是全方位提升体验：

编码：在Xcode上为Kotlin-Native提供与Swift/ObjC同等的read体验；在IDEA、VSCode上提供完整的read & write体验。
构建系统：基于Bazel替代xcodeproj，充分发挥其高并发、增量/分布式构建优势，并提升Kotlin-Native的并发编译能力。
调试：在Xcode和VSCode中实现Kotlin-Native与Swift/ObjC同等水平的调试体验。

Kotlin-Native的默认架构存在多个关键问题，严重影响了iOS平台的研发体验：

Issue 1: 缺乏Kotlin模块级接入：Kotlin仅提供.klib模块，未为其他语言（如.h或.module）提供模块级接入能力，默认只能将多个模块聚合为shared library供外部调用。
Issue 2: 二进制分发产物调试困难：分布式编译或缓存场景下，.klib产物的source map无法稳定还原，导致调试符号与断点失效。
Issue 3: 模块私有依赖能力缺失：KGP中所有依赖都以api方式递归穿透，导致增量编译效率低下，迫使工程采用编译防火墙设计，增加了研发心智负担。
Issue 4: IR阶段与最终产物阶段割裂：Kotlin IR编译与Final Artifact生成分属不同Action，后者过度正确性检查拖慢了编译速度。
Issue 5: 最终链接阶段并发度低下：Kotlin-IR到Object的编译聚合在最终链接阶段，形成长时任务瓶颈，限制了并发编译潜力。
Issue 6: 语言能力溢出导致符号冲突：Kotlin的重载、命名空间等特性在扁平化为ObjC/Swift符号时易产生命名冲突，影响ABI稳定性。

针对上述问题，我们重构了Kotlin-Native编译管线，具体优化措施如下：

产物分层处理：
- ori.klib：原始编译产物。
- abi.klib：仅保留元数据的轻量产物，用于编译参考。
- final.klib：修复fileEntries以正确还原source map。
- final_cinterop.klib：通过cinterop生成，用于C语言交互。
- .module/.h：为每个Kotlin模块生成独立的Clang module，通过Bazel CcInfo集成。
- ksp_generated.kt：基于ori.klib进行代码生成。
实现implementation_deps：在BUILD.bazel中分离deps与implementation_deps属性，精准切断私有依赖的传播链，提升增量编译效率。通过自定义Provider（KlibInfo）管理不同场景的依赖集合。
Parallel Compilation：
- 将每个kt_library模块独立编译为.a静态库，显著提升并发度。
- 最终链接器退化为简单的LLVM Linker，仅负责聚合，将最终产物编译耗时减少约98%。
- 在iOS和HarmonyOS平台上，Clean Build和Incremental Build均获得显著加速，特别是底层模块变更场景，增量编译速度提升可达40倍。
Kotlin模块级导出优化：
- 告别默认的“大一统”框架模式，为每个Kotlin模块生成独立Clang module，实现真正的模块化。
- 采用@ObjCExport注解精确控制导出范围，解决命名冲突问题，并自动分析依赖关系，隐藏链接上下文，对开发者透明。
- 避免了巨型头文件、ABI不稳定和递归重编等问题，提升了工程化可控性。

我们最初的目标是在iOS平台上将KMP研发体验提升至“一等公民”水准。通过对Kotlin-Native编译管线的深度重构，我们系统性地解决了模块化、编译并发和增量构建的核心瓶颈：

构建系统与编译速度：Parallel Compilation使最终产物编译耗时锐减98%，充分释放Bazel高并发优势，实现了“秒级反馈”的内环体验和可靠的远程缓存。
编码与跨语言交互：模块化Clang module导出和@ObjCExport注解提供了与原生无异的开发体验，增强了代码可控性。
调试与工程化：修复source map路径和实现implementation_deps确保了调试稳定性与构建确定性。

即使仅限iOS平台，深度工程化的KMP方案也能构建出比原生更高效、更稳定的研发体系。

为了进一步实现“在任何平台超越原生体验”的愿景，我们规划了以下方向：

统一开发环境：在VSCode中集成基于Bazel的Kotlin LSP扩展，在IDEA中深化sourcekit-lsp支持，打造无缝IDE工作流；并切换至官方的Swift Direct Export，优化交互性能。
极致内环效率：探索类似Flutter的热重载机制，为Compose for iOS引入静态诊断和Layout Inspector，完善UI开发工具链。
反哺社区与生态：持续关注Kotlin/Native上游迭代，推动优化经验回馈社区。

对于社区实践，我们建议：

我们的优化基于Kotlin 2.2.0，并将持续跟进官方进展，推动KMP生态的成熟。