Skip to content

// Share business logic, networking, and storage across iOS + Android with KMM. Native UI on each side.

Kotlin Multiplatform Mobile (KMM)

skill --stat
  • last update

    May 23, 2026

  • license

    MITv1.0.0

  • format

    SKILL.md

quickstart.sh
3 steps
  1. Install

    // Downloads SKILL.md into ~/.claude/skills/kotlin-multiplatform-mobile/

    $ curl -fsSL --create-dirs -o ~/.claude/skills/kotlin-multiplatform-mobile/SKILL.md https://claudeskil.com/skills/kotlin-multiplatform-mobile/SKILL.md
  2. Invoke

    // Inside Claude Code, type the skill name as a slash command

    > /kotlin-multiplatform-mobile help me ship this
  3. Or copy this from the README

    // extracted kotlin block

    $ // shared/build.gradle.kts
    kotlin {
        androidTarget()
        listOf(iosArm64(), iosSimulatorArm64()).forEach {
            it.binaries.framework { baseName = "Shared" }
        }
kotlin-multiplatform-mobile/
references
SKILL.md
readonly
name:
Kotlin Multiplatform Mobile (KMM)
slug:
kotlin-multiplatform-mobile
version:
v1.0.0
license:
MIT
author:
@chiragthummar16
categories:
tags:
#kmm#kotlin#multiplatform#ktor#sqldelight
description:

Share business logic, networking, and storage across iOS + Android with KMM. Native UI on each side.

README.md

kotlin-multiplatform-mobile/README.md
6 sections

Kotlin Multiplatform Mobile (KMM)

Share business logic, networking, and persistence between iOS and Android from a single Kotlin codebase, while keeping native UI on each platform (SwiftUI/UIKit on iOS, Jetpack Compose/Views on Android). This skill scaffolds a shared Kotlin module, wires up expect/actual declarations for platform-specific APIs, and sets up Ktor for HTTP and SQLDelight for typed local storage — including the Xcode framework integration so your iOS app can call shared code as a normal Swift module.

When to use it

  • You have (or want) separate native apps for iOS and Android but keep rewriting the same models, API clients, validation, and caching twice.
  • You want a shared domain/data layer but refuse to compromise on platform-native UI.
  • You're adding KMM to an existing app incrementally — sharing one feature (say, the networking layer) rather than rewriting everything.
  • You need a typed SQLite layer and a multiplatform HTTP client that work identically on both targets.

How it works

The skill generates a Gradle module applying the org.jetbrains.kotlin.multiplatform plugin with androidTarget() and the iOS targets (iosArm64, iosSimulatorArm64, iosX64). Source sets follow the standard commonMain, androidMain, iosMain layout. Platform differences are bridged with expect/actual — e.g. an expect class Platform resolved per target. Networking uses Ktor's HttpClient with the OkHttp engine on Android and the Darwin engine on iOS, plus ContentNegotiation and kotlinx.serialization. Persistence uses SQLDelight: .sq files generate type-safe queries, with AndroidSqliteDriver and NativeSqliteDriver supplied through an expect fun driver factory. For iOS consumption it configures an XCFramework (or CocoaPods via the cocoapods block) so Xcode imports the compiled shared framework.

Usage

bash
curl -fsSL --create-dirs -o ~/.claude/skills/kotlin-multiplatform-mobile/SKILL.md https://claudeskil.com/skills/kotlin-multiplatform-mobile/SKILL.md
kotlin
// shared/build.gradle.kts
kotlin {
    androidTarget()
    listOf(iosArm64(), iosSimulatorArm64()).forEach {
        it.binaries.framework { baseName = "Shared" }
    }
    sourceSets {
        commonMain.dependencies {
            implementation("io.ktor:ktor-client-core:2.3.12")
            implementation("io.ktor:ktor-client-content-negotiation:2.3.12")
            implementation("app.cash.sqldelight:runtime:2.0.2")
        }
    }
}
kotlin
// commonMain — expect/actual driver
expect class DriverFactory { fun create(): SqlDriver }
swift
// iOS — call shared code from Swift
import Shared
let repo = UserRepository(driverFactory: DriverFactory())

Tips & gotchas

  • iOS exposes Kotlin via Objective-C interop, so suspend functions become completion handlers — wrap them with async/await in Swift or use a library like KMP-NativeCoroutines for clean Flow/coroutine bridging.
  • Run ./gradlew :shared:embedAndSignAppleFrameworkForXcode (or use the CocoaPods integration) as an Xcode build phase; stale frameworks are a common "symbol not found" cause.
  • Keep platform dependencies out of commonMain — anything Android- or Darwin-specific belongs behind expect/actual or in the platform source set.
  • Apple Silicon simulators need iosSimulatorArm64; omitting it breaks simulator builds on M-series Macs.

FAQ

Does this share the UI too? No — UI stays native (SwiftUI/Compose). KMM shares logic, networking, and storage only.

Can I add it to an existing project? Yes. Drop in the shared module, depend on it from the Android app, and integrate the framework into Xcode incrementally.

Why SQLDelight over Room? Room isn't multiplatform; SQLDelight generates typed queries from .sq files and ships drivers for both Android and native iOS.

$ cat reviews/

Reviews

// No reviews yet. Be the first.
Loading review form…

$ ls related/

explore all →