KMP Boundaries
Communityrcosteira79
Use when designing Kotlin Multiplatform boundaries — choosing between expect/actual, common interfaces with platform bindings, or separate platform screens. Covers platform services (clipboard, share, haptics, permissions, files, settings, sensors, biometrics), native SDKs, source-set hierarchies (commonMain, skikoMain, appleMain, androidMain), Compose Multiplatform interop, and capability granularity. Use whenever common code needs to reach a platform API and you're picking the boundary shape.
Overview
- Repository
- rcosteira79/android-skills
- Publisher
- rcosteira79
- Stars
- 174
- Forks
- 21
- Bundled files
- 1
- License
- MIT
- Updated
- Nov 10, 2026
Installation
tmp=$(mktemp -d)
git clone --depth 1 https://github.com/rcosteira79/android-skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/plugins/android-skills/skills/kmp-boundaries" ~/.claude/skills/kmp-boundaries
rm -rf "$tmp"tmp=$(mktemp -d)
git clone --depth 1 https://github.com/rcosteira79/android-skills.git "$tmp"
mkdir -p ~/.codex/skills
cp -R "$tmp/plugins/android-skills/skills/kmp-boundaries" ~/.codex/skills/kmp-boundaries
rm -rf "$tmp"Install the KMP Boundaries agent skill from https://github.com/rcosteira79/android-skills/tree/main/plugins/android-skills/skills/kmp-boundaries into this project's skills folder.Instructions
Kotlin Multiplatform Boundary Design
Core rules for any KMP boundary:
- Keep
commonMainsemantic — describe what the product needs, not Android/iOS mechanics:currentRegion(), nevercurrentRegionFromAndroidLocale(context). - Split by capability —
Clipboard,ShareSheet,Haptics,Biometricsas separate interfaces, not onePlatformgod object. - Keep actuals thin — they translate, they don't decide; a business
if/wheninside an actual belongs in common, tested with a fake. - Prefer a common
interface+ per-platform binding overexpect classwhenever you need fakes / DI / lifecycle / runtime selection. - Introduce an intermediate source set (
skikoMain,appleMain) only when two platforms genuinely share an actual.
Two boundaries get the most detail below: the Activity-owned platform-UI boundary, and the AGP-9 KMP-library constraints.
Related: android-skills:kmp-ktor (network boundary), compose/references/multiplatform.md (Compose-MP mechanics), android-skills:kotlin-coroutines (scope ownership). For the iOS↔Swift bridge — Kotlin→Swift naming, type widths (Int is 32-bit), @Throws, SKIE suspend→async / Flow→AsyncSequence, sealed-class exhaustiveness, SwiftUI embedding — load references/ios-interop.md when authoring the iOS-side actual.
Platform-UI bindings are Activity-owned, not Context-owned
The single most common Android boundary mistake: passing applicationContext / LocalContext.current into a binding that actually needs an Activity, then papering over the lifecycle gap with Intent.FLAG_ACTIVITY_NEW_TASK. That flag is a smell — it hides that this is a foreground-UI operation. Hold an Activity instead.
// commonMain — semantic interface; DOCUMENT what `suspend` means
interface ShareSheet {
/** Launches the system share sheet. Returns when the sheet is PRESENTED — not when the user
* completes or cancels. (Otherwise callers write incorrect retry/confirmation logic.) */
suspend fun shareText(text: String)
}
// androidMain — thin: build the intent and launch it. Activity-owned.
class AndroidShareSheet(private val activity: Activity) : ShareSheet {
override suspend fun shareText(text: String) {
activity.startActivity(Intent.createChooser(
Intent(Intent.ACTION_SEND).setType("text/plain").putExtra(Intent.EXTRA_TEXT, text), null,
))
}
}You don't app-wide-inject an Activity (it's framework-created and lifecycle-bound) — construct the binding in an activity scope in the Android app module (Hilt @InstallIn(ActivityComponent::class), where Activity is a default binding; Koin scoped). commonMain only ever sees the interface; the Activity never leaves the app module. If a longer-lived (app-scoped) object needs it, hold it behind a lifecycle-aware provider (set in onResume, cleared in onPause) so a destroyed Activity can't leak.
AGP-9 KMP-library constraints (structural — they shape what can live in shared code)
AGP 9 replaces com.android.library with com.android.kotlin.multiplatform.library for the Android side of a KMP module, and rejects com.android.application + kotlin.multiplatform outright. The new plugin enforces a single-variant architecture:
BuildConfigis unavailable — compile-time constants come from BuildKonfig or an injectedAppConfigurationinterface. Don't designcommonMainAPIs that assumeBuildConfig.Xexists.- No build variants — variant-specific deps/resources/signing live in the app module; a debug/release decision surfaces as a runtime config value injected into common code, not a build-variant split inside the KMP module.
- No NDK / JNI — extract native (C/C++) into a separate
com.android.librarymodule, wrapped behind a common interface the KMP module consumes. - Compose-MP resources need explicit enable — add
androidResources { enable = true }insidekotlin { android { … } }, orRes.string.*/Res.drawable.*crash at runtime on Android (the build still succeeds — easy to miss). - Consumer ProGuard rules need migration —
consumerProguardFiles("rules.pro")from the oldandroid {}block is silently dropped; useconsumerProguardFiles.add(file("rules.pro"))in the new DSL. - The KMP module can't also be
com.android.application— the Android entry point (MainActivity, Application class, launcher manifest,applicationId/targetSdk/versionCode/versionName) moves to a separateandroidAppmodule that depends on the shared library.MainActivity, app-level Hilt setup, and nav-host wiring all move out of the sharedandroidMain. - Tests are opt-in and renamed — enable them with
withHostTest { }/withDeviceTest { }insidekotlin { android { … } };androidUnitTestbecomesandroidHostTestandandroidInstrumentedTestbecomesandroidDeviceTest(the source directories move too). - No
debugImplementation— there is one variant. Composeui-toolinggoes on"androidRuntimeClasspath"(…); choosing a variant of a multi-variant dependency goes inlocalDependencySelection { }. - kapt is incompatible with AGP 9's built-in Kotlin — migrate annotation processors to KSP (2.3.6+), or fall back to
com.android.legacy-kaptfor processors with no KSP equivalent.
| Concern | Pre-AGP-9 (monolithic) | AGP 9 KMP library |
|---|---|---|
MainActivity, Application class, launcher manifest |
androidMain of shared module |
Separate androidApp module |
applicationId, versionCode, targetSdk |
Shared module's android {} |
androidApp only |
| Compile-time constants (env, flags) | BuildConfig field |
BuildKonfig in common, or runtime DI |
| NDK / JNI native code | androidMain (any module) |
Separate com.android.library, behind a common interface |
For migrating an existing project, see JetBrains' kotlin-tooling-agp9-migration skill for the full mechanics.
Bundled files
FAQ
What does KMP Boundaries do?
Use when designing Kotlin Multiplatform boundaries — choosing between expect/actual, common interfaces with platform bindings, or separate platform screens. Covers platform services (clipboard, share, haptics, permissions, files, settings, sensors, biometrics), native SDKs, source-set hierarchies (commonMain, skikoMain, appleMain, androidMain), Compose Multiplatform interop, and capability granularity. Use whenever common code needs to reach a platform API and you're picking the boundary shape.
Who made KMP Boundaries?
rcosteira79 (a community member) publishes it in the rcosteira79/android-skills repository on GitHub.
Is KMP Boundaries free?
Yes. KMP Boundaries is open source, published by rcosteira79 under the MIT license.
What comes with KMP Boundaries?
Its instructions and 1 file the agent reads only when a task needs them, such as references, examples or scripts.
Which agents can use KMP Boundaries?
Any coding agent that reads SKILL.md files, including Claude Code, Codex, Cursor, GitHub Copilot and Gemini CLI. The agent loads the skill when a task matches its description.
What are agent skills?
An agent skill is a folder with a SKILL.md file: instructions that teach a coding agent how to do one kind of task, and optionally files it can read while it works. The agent keeps only the skill's name and description in mind and reads the rest when a task calls for it.
How are agent skills different from MCP servers?
An MCP server gives an agent new tools to call, code that runs somewhere and returns results. A skill gives it knowledge: how to approach a task with the tools it already has. Many agents use both.
How can my agent test my Android app?
Robomori lets coding agents create, start and control Android emulators and devices from one command, so they can install your app, take screenshots and check dark mode, font sizes and languages.