Kotlin Multiplatform Vocabulary: KMP, Compose, and Swift Interop

Kotlin Multiplatform: Why Vocabulary Matters

Kotlin Multiplatform (KMP) is maturing rapidly as a way to share business logic across Android, iOS, and desktop platforms. If you follow KMP development, attend JetBrains talks, or read the official documentation, you will encounter a specific set of terms that describe its unique architecture. Understanding these in English helps you participate in the international KMP community and communicate effectively with teammates on cross-platform projects.

Core KMP Architecture Terms

Source Sets

A source set is a collection of Kotlin source files and their associated resources that target a specific platform or group of platforms. Source sets are organised in a hierarchy.

• commonMain — the source set containing code shared across all platforms. This is where you write platform-agnostic business logic. “All data models and repository interfaces live in commonMain.”
• androidMain — the source set containing Android-specific implementations.
• iosMain — the source set containing iOS-specific implementations.
• nativeMain — covers all Kotlin/Native targets, which includes iOS, macOS, Linux, and Windows.

Expect/Actual Declarations

The expect/actual mechanism is one of KMP’s most distinctive features. It allows you to declare a function or class in commonMain (using the expect keyword) and provide a platform-specific implementation in each target source set (using the actual keyword).

“The expect declaration in commonMain defines the API contract; each platform provides its actual implementation.”

This is how KMP handles platform differences — things like date/time, file system access, or cryptography — without polluting shared code with if (platform == iOS) checks.

Kotlin/Native and Kotlin/JS

Kotlin/Native is the compiler target that produces native binaries for platforms without a JVM — principally iOS, macOS, and embedded systems. Kotlin/JS compiles Kotlin to JavaScript, enabling code sharing with web targets.

Compose Multiplatform

Compose Multiplatform is JetBrains’ extension of Jetpack Compose that allows you to write shared UI code in addition to shared business logic. It targets Android, iOS, desktop (JVM), and web.

• @Composable function — a function annotated to participate in the Compose UI framework, regardless of target platform.
• commonUI source set — a pattern (not a built-in name) for organising shared Compose UI code that runs on multiple targets.
• Material 3 for Compose Multiplatform — the shared implementation of Google’s Material Design component library that works across platforms.

Gradle KMP DSL

KMP projects are configured using the Kotlin Gradle DSL. Familiarity with these terms is essential for reading and writing build.gradle.kts files.

kotlin { } block — the top-level DSL block in a KMP Gradle script where you declare targets and source sets.

Target — a specific platform you want to compile for, such as androidTarget(), iosArm64(), or jvm().

sourceSets { } block — where you define dependencies for each source set. “Add the Ktor client-core dependency to commonMain and the engine dependency to each platform’s source set.”

Swift Interop Vocabulary

When KMP is used in an iOS app, Kotlin code is exposed to Swift through an Objective-C framework (which Swift can consume directly due to Obj-C interoperability).

Framework header — the generated .h file that describes which Kotlin classes and functions are accessible from Swift.

@ObjCName — a Kotlin annotation that controls how a Kotlin declaration appears in the generated Objective-C API, allowing you to give it a more Swift-idiomatic name.

suspend function from Swift — KMP exposes Kotlin coroutine suspend functions to Swift as callback-based or async functions, depending on the Kotlin version and configuration. “Calling a suspend function from Swift requires using the generated async wrapper or the kotlinx-coroutines-core Swift extensions.”

CocoaPods integration — a method of distributing the KMP iOS framework via CocoaPods, the standard iOS dependency manager. “We publish the shared framework as a CocoaPods spec so the iOS team can consume it without building from source.”

Five Example Sentences

1. “All network models are declared in commonMain so that both the Android and iOS targets share the same data layer without duplication.”
2. “The expect class in common code declares a PlatformDateFormatter; each target provides its actual implementation using the platform’s native date APIs.”
3. “After migrating to Compose Multiplatform, we reduced our UI codebase by roughly 60% by sharing screen-level composables between Android and desktop.”
4. “The Gradle KMP DSL target declarations define which platforms are compiled during CI, so we only build iOS binaries when running on a macOS runner.”
5. “The iOS team consumes the KMP framework via CocoaPods, which means they can update the shared logic version with a single pod update command.”

Summary

KMP vocabulary is dense but logical. The key mental model is: declare once in commonMain, implement per-platform using expect/actual. Once you have that model, the rest of the vocabulary — source sets, targets, Compose Multiplatform UI sharing, Swift interop — falls into place naturally.