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.

Bridging the Gap: A Code Review Perspective

Let’s be honest – navigating technical discussions in a professional setting, especially when dealing with complex concepts like Kotlin Multiplatform, can feel incredibly daunting. Beyond understanding the code itself, you need to understand how others are communicating about it. Consider this scenario: Sarah, a senior developer on the team, is reviewing a pull request submitted by David, a newer engineer who’s diving into Compose Multiplatform. David’s PR introduces a new screen component using Jetpack Compose and leverages Swift interop for accessing native iOS functionality.

Sarah reads through David’s commit message – “Implemented Login Screen with Swift Integration” – and immediately sees the potential for ambiguity. While concise, it doesn’t convey the nuances of the work. She might respond with something like: “David, thanks for this! To help me fully understand the scope, could you elaborate on the ‘Swift integration’? Specifically, can you detail how the expect declarations are being used to manage the data flow between Kotlin and Swift? Also, I’d appreciate a bit more context around the source set configuration – is it a completely new one or an extension of our existing KMP setup?” This isn’t about pointing out errors; it’s about clarifying expectations and ensuring everyone’s on the same page regarding the architecture. The use of terms like “expect declarations” and “source set configuration” are critical for discussing this particular aspect of KMP, highlighting the importance of precise terminology when talking about cross-platform development. It’s also a good reminder to document decisions clearly – something that can prevent future misunderstandings and streamline collaboration.

Furthermore, understanding the difference between “expect” and “actual” declarations is key here. “Expect” declarations define what Kotlin anticipates receiving from Swift, while “actual” declarations specify what’s actually being sent back. This distinction becomes even more crucial when dealing with interop scenarios where data types might differ slightly between platforms. Misunderstanding this could lead to unexpected runtime issues or introduce subtle bugs that are difficult to track down.

Finally, the conversation often extends beyond individual PR reviews. Slack channels dedicated to KMP development frequently involve discussions about best practices and architectural choices – terms like “source set” becoming commonplace when discussing code organization and dependency management. It’s a continuous learning process, not just of Kotlin itself but also of the language used to discuss it within the broader engineering community.

// Example: Expect declaration in Kotlin
expect class MySwiftObject {
    var name: String
}

// Corresponding Swift implementation (simplified)
class MySwiftObject {
    var name: String = ""
}