Kotlin Multiplatform Boundary Design

Designing the boundary between shared and platform code is the central craft of KMP: keep commonMain reading like product code, and push Context/UIViewController/actual mechanics behind small named boundaries before they grow domain logic. This skill covers boundary shape — expect/actual vs a common interface with platform bindings vs separate platform screens — and the granularity rules that keep all three from collapsing into a god object.

Use it when common code must reach a platform API (clipboard, share, haptics, biometrics, files, sensors, native SDKs, Compose interop) and there's no existing recipe. If you're picking a mechanism that has a recipe (Ktor, Coil 3, Navigation Compose), use the recipe instead.

Related skills:

• android-skills:kmp-ktor — Ktor client for network APIs (one concrete platform boundary done right).
• android-skills:compose — references/multiplatform.md covers Compose Multiplatform mechanics (resources, source-set wiring, migration table).
• android-skills:kotlin-coroutines — scope ownership rules that apply to platform-bound work.

Core Principle

Keep commonMain semantic and stable. Push platform mechanics behind small, named boundaries. Actuals translate — they don't decide.

Three rules govern every boundary decision in this skill: