前者通常保留两端原生 UI，把领域逻辑、数据访问和网络层放进 commonMain；后者把大部分界面和交互交给 JavaScript/TypeScript，再通过原生模块接入设备能力。选择 KMP，往往是在保留网站边界的前提下压缩重复业务代码。老实说，

共享到哪一层

痛点：业务代码在两端各写一遍导致维护成本飙升、bug 同步困难。

KMP 项目里Android 和 iOS 可以继续各自维护页面入口、导航、程序组件和网站交互。共享模块不需要知道当前页面是 Compose、XML 还是 SwiftUI，它只提供 UseCaseRepository序列化模型和状态。

这和许多移动端项目原来的分层比较接近。Android 已经有 datadomainfeature 模块时迁移的主要通常是把纯 Kotlin 的部分移到 commonMain而不是把整个 UI 重写一遍。说起来，

示例这方面。登录状态共享

痛点：登录接口在两端实现不一致，导致调试时间翻倍。

// shared/src/commonMain/kotlin/session/SessionRepository.kt
class SessionRepository(
private val api: AccountApi,private val tokenStore: TokenStore。) {
suspend fun signIn: Session {
val session = api.signIn)
tokenStore.save
return session
}
}

AccountApiTokenStore 的接口也放在 commonMain。Android 可用 Ktor + SharedPreferences 或 DataStore 实现，iOS 用 Ktor Darwin 引擎和 Keychain 实现。业务调用方拿到的都是同一个 Session不用维护两份接口字段和错误映射。

KMP 项目结构示例

// shared/build.gradle.kts
kotlin {
androidTarget
iosArm64
iosSimulatorArm64
sourceSets {
commonMain.dependencies {
implementation
implementation
}
}
}

痛点：Kotlin 代码直接引用 Android Context/ViewModel/Compose API 时会报错，需要抽象成网站实现。

UI 仍在网站侧

痛点：If you try to share UI across platforms without a proper abstraction layer,you’ll face performance regressions and platform‑specific bugs.

React Native 的优势是界面也能共享。页面以 JS/TS 组件为主要，Android 和 iOS 有一套统一的渲染与交互代码。当表单、列表、业务页面较多且两端视觉一致时这能明显降低重复工作。

KMP 与 UI 的取舍

KMP 接受两份 UI 的成本，把共享范围收在逻辑和数据层。设计稿在两端差异大、产品依赖程序交互或已有成熟原生代码时保留原生 UI 可以省去“一层适配”。这并不代表着 KMP 没有 UI 方案——Compose Multiplatform 已经可以覆盖部分多端界面只是是否共享 UI 是单独的决策。其实，

代码所有权 & 团队协作痛点

• Pain point: React Native 要求团队同时熟悉 JavaScript/TypeScript 与原生模块的开发。 否则需求会卡在“谁来实现桥接”。
• Pain point: KMP 更适合让网站工程师继续拥有自己的 UI 与程序集成。Kotlin 开发者负责共享层，iOS 开发者仍用 Swift/SwiftUI 编写界面。按理说，
• Pain point: 接口改动集中在共享模型与 API 契约上。Review 时更容易判断影响范围。

KMP 推荐目录结构

shared/
└─ src/
├─ commonMain/ → model、network、repository、usecase
├─ androidMain/ → Android 存储、网络引擎实现
└─ iosMain/ → Keychain、Darwin 网络引擎实现
androidApp/
└─ Compose / ViewModel / Android 程序能力
iosApp/
└─ SwiftUI / iOS 程序能力

Pain point: 不要让主要模块依赖页面层。例如订单提交后需要弹 Toast，commonMain 或领域错误；Android ViewModel 与 iOS 页面各自决定提示文案与展示方式，从而避免为共享一个提示框而把网站 UI API 拉进主要模块。

迁移成本 & 边界清理痛点

KMP 的门槛不在于把 Kotlin 文件搬到 commonMain 、传递 Context 或依赖 AndroidX 生命周期组件的代码必须抽象到网站实现中，否则编译会报错提醒哪些依赖未拆分。

Pain point: iOS 侧一样需要付出工程成本——将 Kotlin/Native 产物接入 XCode。暴露协程 / Flow 给 Swift 调用，并确保网络错误与线程切换在真实设备上表现一致。

Pain point: React Native 也有自己的成本：升级 RN 版本时要处理原生依赖兼容性；调试 JS 与原生之间的问题常常让定位 bug 成本翻倍。两套方案都不是“写一次后完全免维护”，差别只在复杂度集中在哪一层。

Larger‑scale迁移建议

• If your product already has distinct Android/iOS UIs and differences are significant。start by extracting pure business logic into .commonMain. This yields immediate maintenance gains without rewriting all screens.
• If your goal is a highly unified cross‑platform UI and you have a stable JS/TS + native bridge team,RN 能更快看到收益。其实，
• If you need a middle ground—retain native UI but share domain logic—KMP 是更低风险的选项。

最终 & 行动呼吁痛点聚焦

Pain point: 团队常因缺乏明确的技术选型标准而陷入“每次需求都要评估到底是改 JS 还是改原生”的循环。怎么说呢，如果现在还没有统一的评估模型。不妨先对以下维度打分：

• L​ogic 重复度？
• L​evel of UI 差异？
• T​eam skill set？
• M​aintenance cost？说起来，
• E​cosystem maturity？