Learn Kotlin - Kotlin Multiplatform & Cross-platform

#Introduction

Kotlin doesn't only run on the JVM and Android. Episode 12 opens up Kotlin Multiplatform (KMP): the ability to write business logic once and use it on Android, iOS, desktop, JavaScript, and Native. This is JetBrains' strategic direction and one of the fastest-growing topics.

The key to KMP is dividing code into platform-common code that is shared and platform-specific code written per target. expect and actual declarations bridge the two with compile-time guarantees.

After this episode, you'll understand when KMP is the right fit and how to structure your first shared module.

#Kotlin Multiplatform Architecture

#One Codebase, Many Targets

KMP lets you write a shared module once and compile it to several targets: JVM, Android, iOS (Native), JavaScript (Wasm), and desktop. Platform-common code contains business logic, data models, and data connections; platform-specific code contains APIs that depend on the operating system.

This hierarchy is configured in the Gradle file. An example of target configuration:

build.gradle.kts target KMP

kotlin {
    jvm()
    androidTarget()
    iosX64()
    iosArm64()
    iosSimulatorArm64()
    js(IR) {
        browser()
        nodejs()
    }
    sourceSets {
        commonMain.dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.9.0")
        }
    }
}

jvm() for desktop/server, androidTarget() for Android, the three ios* variants for Apple devices and simulators, and js(IR) for the web. Shared dependencies are declared in commonMain.

#Compilation to Native Binary

Code for iOS and Native is compiled into native binaries (not JVM bytecode) using the Kotlin/Native compiler. This means iOS apps run Kotlin code compiled directly to machine code, with full native performance.

#Shared Module and Source Sets

#Source Set Hierarchy

The main KMP source sets are commonMain for shared code and commonTest for shared tests. Each target has its own source set, such as androidMain and iosMain, for platform-specific code. The KMP compiler creates intermediate source sets (like nativeMain) automatically based on the declared targets.

#Sharing Code Effectively

The logic that benefits most from sharing:

• Data models: the same data classes are used across all platforms.
• Repository and networking: Ktor client, which supports multiplatform.
• State management: coroutines and Flow run on every target.
• Validation and serialization: kotlinx.serialization generates JSON codecs.

UI code usually stays platform-specific — Compose Multiplatform for desktop and Android, SwiftUI for iOS. Sharing logic and separating UI is the most common KMP pattern in production.

#Expect and Actual

#Declaring a Platform API

The expect keyword declares an API that every platform must provide. The actual keyword provides its platform-specific implementation. A classic example: getting the current date:

expect declaration

expect fun tanggalSekarang(): String

The declaration expect fun tanggalSekarang() states a contract: every platform must provide this function. The compiler guarantees every expect declaration has a matching actual on every target — if one is missing, the build fails.

#actual Implementations per Platform

Each target provides its own implementation:

actual untuk JVM dan JS

actual fun tanggalSekarang(): String = java.time.LocalDate.now().toString()

Other targets contain their own actual versions in their source sets. The expect-actual pattern is the bridge that keeps types safe across platforms — no fragile runtime reflection, only implementations verified at compile time.

#Real-world KMP Use Cases

#Mobile, Desktop, and Web

Common KMP usage patterns:

• Mobile: a shared module for Android and iOS with the same logic and networking, each with its own native UI.
• Desktop: JVM desktop apps or Compose Desktop for Linux, macOS, and Windows.
• Web: Kotlin/JS and Kotlin/Wasm for browser frontends from the same code.
• Backend: the shared module also serves a Ktor server on the JVM.

Teams using KMP report major savings because business rules are written once and tested once for all platforms.

#When Not to Use KMP

KMP adds complexity to builds and tooling. For quick prototypes or purely single-platform apps, a plain Kotlin JVM or Android project is simpler. Consider KMP when you genuinely target several platforms with significant business logic.

#Closing

Episode 12 opened up Kotlin Multiplatform: the shared module architecture for JVM, Android, JS, and Native, the source set hierarchy for sharing code, expect and actual declarations guaranteed by the compiler, and use cases for mobile, desktop, and web.

The key takeaways:

• KMP compiles shared code to JVM, Android, JS, Wasm, and Native.
• Targets are declared in the kotlin block of build.gradle.kts.
• commonMain for shared code; per-target source sets for specific code.
• expect declares an API; actual provides the per-platform implementation.
• Share logic, models, and networking; keep UI platform-specific.
• Evaluate the need for multi-platform before adding KMP complexity.

In episode 13 we'll discuss testing and quality — unit testing with Kotlin Test, JUnit, and Kotest, mocking with MockK or Mockito, Behavior-Driven Testing patterns, and continuous testing and automation that keep code quality high.