Kotlin Multiplatform iOS+Android跨端策略分享及实践问题咨询

问题1：工程师群体当前是如何在iOS与Android双端场景下使用Kotlin Multiplatform的？ #

当前行业内工程师使用KMP适配iOS、Android双端的典型模式如下：

• 分层复用核心逻辑：优先将双端无差异的代码下沉到commonMain源码集，包括网络请求封装、数据序列化、核心业务规则计算、存储层逻辑、状态管理逻辑等；涉及平台差异的能力通过KMP的expect/actual语法实现，比如系统API调用、硬件能力调用、第三方SDK适配等，iOS端在iosMain下提供actual实现，Android端在androidMain下提供对应实现。
• UI层差异化处理：绝大多数团队的C端核心业务页面仍保留原生实现，Android端使用Jetpack Compose或XML布局，iOS端使用SwiftUI或UIKit；仅少部分团队会用Compose Multiplatform实现非核心路径的跨端UI，比如内部工具页面、营销活动页、ToB类低频交互页面。
• 统一依赖与测试管理：通过Gradle统一管理KMP模块的所有依赖，双端无需单独处理通用逻辑的依赖项；通用逻辑仅需在commonTest下编写一套单元测试即可覆盖双端场景，大幅降低测试重复工作量。

问题2：iOS项目中新增KMP编译构建阶段的主流集成方案 #

针对iOS端KMP模块的集成方案，行业内主流选择是根据团队规模和模块迭代节奏二选一，没有绝对的最优解：

• 预编译产物接入是中大型团队的首选方案：将KMP模块预先编译为XCFramework产物，iOS主工程直接依赖二进制产物。优势在于iOS开发不需要配置Kotlin、Gradle环境，不会增加iOS本地构建时长，KMP模块的版本管控清晰，出问题可快速回滚对应版本，适合KMP模块由独立团队维护、迭代频率较低的场景。
• 同仓实时编译适合小型团队或高频迭代场景：将KMP源码和iOS主工程代码放在同一个代码仓库中，iOS构建阶段直接触发KMP的编译任务生成Framework后接入主工程。优势在于KMP逻辑修改后可直接在iOS端调试，不需要额外走产物发布流程，适合双端业务同步迭代、KMP模块改动频繁的小型团队，缺点是会增加iOS本地构建时长，且要求所有iOS开发配置KMP相关环境，KMP构建配置变动可能影响主工程稳定性。

部分团队会采用折中方案：开发阶段使用同仓实时编译提升调试效率，正式发版时切换为预编译产物接入，兼顾开发体验和发布稳定性。

内容的提问来源于stack exchange，提问作者Tim Nuwin