2025 Kotlin Multiplatform 感受浅谈，跨端应用是否可以考虑 KMM

背景

这几天整了个小 IOS 需求，大致体验了下双端开发，目前已经接近完工，涉及主要是 SQLite、IO 以及最常见的 UI，未涉及网络。理论上网络诉求远大于本地端，体验应当不太差（仅理论）。

之前的同事（两年前）开发过一款 KMM 的网易云，但后续我并未尝试，因为懒得踩坑，现在 BETA 。从新手的角度看，还算顺畅。

感觉直到 KMM ，才意义上的符合了当初的一个 Activity，因为一旦越界，就不是一个单端开发能搞定的了，一切行为围绕 ComposeView，以及 Gradle 与 Kotlin 官方文档。

一些流程

在构想一个功能的时候，脑子里第一件事还是停留在“是否支持 KMM”，毕竟想要通用，等于大换血。GPT 能给不少助力，至少能得到一个“看上去可行与否”的答案。

随之便是尝试找对应的 lib，因为 KMM 核心在于 Kotlin 与 Compose 的通用，版本太新了会崩溃，太旧了也会崩溃，不支持的便用不了，此刻崩溃对于版本号⚠️突然不再显得刺眼。

找得到 lib 还好，找不到的呢？KMM 迭代了这么久，自然是有组合拳，定义一个 expect 预期 ：

expect fun loadDatabaseBuilder(): IDatabaseBuilder

两端再分别来个 actual 实现：

actual fun loadDatabaseBuilder(): IDatabaseBuilder = DatabaseBuilder()

这个组合拳支持的部分，按属性、方法，类排，进程到了 object 这里会给个提示 are Beta：

'expect'/'actual' classes (including interfaces, objects, annotations, enums, and 'actual' typealiases) are in Beta. You can use -Xexpect-actual-classes flag to suppress this warning. Also see: https:// youtrack. jetbrains. com/ issue/ KT-61573

我不知道 Bate 和正式的区别有多久，毕竟 Google 还有很多东西 3 年前是 alpha 现在还是，并非停止维护也是一直在更新，就是这个正式太难了。

总的来说，两端依旧在用 Kotlin。脱离了 UI 的部分，Kotlin 才开始不再像 Kotlin，在涉及到 IOS 的原生部分（文件、plist、日志）时，NSxxxxxxx 之类的特定代码，会变得常见。是单端需要花时间去查找的部分，例：

@OptIn(ExperimentalForeignApi::class)
private fun documentDirectory(): String {
    val documentDirectory = NSFileManager.defaultManager.URLForDirectory(
        directory = NSDocumentDirectory,
        inDomain = NSUserDomainMask,
        appropriateForURL = null,
        create = false,
        error = null,
    )
    return requireNotNull(documentDirectory?.path)
}

U1S1，这时就有了点 AIDL 的味道，做过系统开发的都应知道，GPT 说 Flutter 也是一样，不过上面都是小问题，习惯了就好。

大问题在哪儿呢，就是这个 KMM 用的人确实不多。

1、最常见的 toast 场景 ，Github 上被 GPT 推荐的库 Star 不过百，而且相当的新。当然也可能是 toast 在 IOS 那边太丑了，大家选择各自实现。

2、文章基本停留在 2022，和 2024 年底。

这个时段很有意思，2022 那批文基本上包含了一个 Shared，以至于现在问 GPT 回答总是带 Shared 的错误答案。

而 2024 年底，是 K2 和 Share UI Beta 开始从而将我拉进坑的时间，这个项目初始化是无 shared 目录的。

这样理解一切就合理了，毕竟时间超短，加上全球经济形势，恐难以出现现象级的社区支持，何况大国之争下，鸿蒙成了强推，好不好用另说，得先遥遥领先。

其他，貌似技术上没什么好说的。基本上逻辑都写在 commonMain ，像开发 Compose Android 一样去写就好了，只是需要注意很多常见的 java 包都不再支持，需要换成 kotlinx，简单如 datetime 也不能用 currentTimeMillis 了事。

BB 完了

如果是新项目，如果是 Android 背景的独立开发者，如果是一个不需要什么黑科技的普通 APP（不需要什么底层支持），只需两端 UI 同步，目前的 androidMain、commonMain、iosMain 已经很顾名思义，可以尝试，所见即所得。

和 Flutter 似乎没有比的必要，思路流程差不多，何况是同一个爹。至于 Flutter ，目前群基本安静了，正如目前的中小企业现状。。。不是，难道 KMM 的核心不应该是“不用新学”？

同时吐槽下 IDE 性能，M4 32G 的配置，开发起来还是有点卡卡的，能瘦瘦身吗？还要吐槽下 Apple， 不当 Apple Dev 不知，开发 IOS APP 都得先花 688 交会费才能玩，不然 ipa 打包资格都没有，dev 7 天就得重签，企业也才 1 年，也难怪欧盟一直搁这制裁。

以上。