Kotlin Multiplatform Mobile — What It Is, Key Concepts, and KMM Architecture

What Is Kotlin Multiplatform Mobile?

Kotlin Multiplatform Mobile (KMM) is a technology that allows you to write shared business logic for a mobile application in Kotlin and use it on iOS and Android without code duplication. Unlike Ionic or Cordova, KMM does not render the interface in a WebView — the UI remains completely native and is written in SwiftUI (iOS) and Jetpack Compose (Android).

KMM was announced by JetBrains in 2019 as part of the Kotlin Multiplatform strategy. The key difference from other cross-platform solutions is that the framework does not attempt to unify the UI but focuses on sharing precisely the code that is truly identical for both platforms: network requests, data models, form validation, business rules, and database operations.

According to the JetBrains Developer Survey (2025), KMM is used by 14% of mobile developers, and this figure is growing by 5% annually. The technology is chosen by companies with high demands for performance and native user experience, where hybrid solutions are unacceptable.

KMM Architecture: Shared Module and Platform Implementations

The KMM architecture consists of three modules: shared (common Kotlin code), iosApp (native iOS application in Swift), and androidApp (native Android application in Kotlin). The shared module is compiled into a JAR for Android and a universal framework (Apple Framework) for iOS.

Shared Module: What Goes Into Common Code

The shared module contains all platform-independent layers: the network layer using Ktor Client, data models with serialization via kotlinx.serialization, repositories for data management, form validation, and business rules (for example, calculating delivery cost or checking access permissions).

The shared module uses the Gradle Multiplatform Plugin and contains three source sets: commonMain (shared code), androidMain (Android-specific implementations), and iosMain (iOS-specific implementations). The Kotlin/Native compiler transforms the shared code into a native library for iOS, which is linked to the Swift project via XCFramework.

Platform Modules

Android module — a standard Android application in Kotlin with Jetpack Compose or ViewBinding. The shared module is connected as a regular Gradle dependency, and all classes from commonMain are directly accessible.

The iOS module is an Xcode project in Swift or Objective-C. The shared module is connected via CocoaPods, Swift Package Manager, or XCFramework. Kotlin/Native generates Objective-C headers for exporting Kotlin types, making them accessible from Swift.

The expect/actual Mechanism in KMM

expect/actual is a Kotlin Multiplatform mechanism that allows you to declare an API in shared code (expect declaration) and provide its implementation separately for each platform (actual declaration). The compiler ensures that an actual declaration exists for every target platform.

Typical use cases for expect/actual include: getting the current time with time zone support, working with SharedPreferences (Android) / UserDefaults (iOS), cryptographic functions, and UUID generation. Each platform uses its own system API.

Without expect/actual, it would be impossible to have unified business logic code, since the APIs for working with the file system, network, and storage differ between iOS and Android at the system call level. The mechanism guarantees that the developer will not forget to implement the platform-specific part.

For platform calls such as working with the camera or biometrics, KMM offers the expect/actual mechanism combined with plugins similar to Cordova, but on Kotlin/Native. JetBrains has also released the kotlinx-datetime library, which abstracts date and time handling.

KMM Code Examples

Let’s look at the basic structure of a KMM project with an expect function declaration for UUID generation and its implementation for iOS and Android.

// commonMain — common declaration
expect fun generateUUID(): String

// androidMain — Android implementation
actual fun generateUUID(): String {
    return java.util.UUID.randomUUID().toString()
}

// iosMain — iOS implementation
actual fun generateUUID(): String {
    return platform.Foundation.NSUUID().UUIDString
}

In shared code, the expect fun generateUUID() is declared. Android uses java.util.UUID, while iOS uses NSUUID from the Foundation framework. In the rest of the shared module code, this function is called without regard to the platform.

An example of a network request using Ktor Client in shared code:

import io.ktor.client.*
import io.ktor.client.request.*
import io.ktor.client.statement.*
import kotlinx.serialization.*
import kotlinx.serialization.json.*

@Serializable
data class User(
    val id: Int,
    val name: String
)

class UserRepository {
    private val client = HttpClient()

    suspend fun getUser(id: Int): User {
        val response: HttpStatement =
            client.get("https://api.example.com/users/$id")
        return Json.decodeFromString(response.bodyAsText())
    }
}

This code works on both platforms without changes. Ktor Client uses OkHttp on Android and NSURLSession on iOS automatically, without additional configuration. JSON serialization via kotlinx.serialization is also cross-platform.

Comparing KMM with Flutter and React Native

KMM occupies a unique position among cross-platform technologies, as it does not attempt to replace the native UI unlike Flutter and React Native. KMM is a solution for sharing logic, not for unifying the interface.

The main advantage of KMM is full control over the UI. If an application needs to look and behave natively on each platform (for example, using iOS TabBar and Android BottomNavigation with platform animations), KMM is the only cross-platform solution that provides this without workarounds.

The disadvantage is that the team must know Kotlin, Swift, Jetpack Compose, and SwiftUI simultaneously, which complicates hiring. Flutter and React Native require knowledge of one language and one framework.

Advantages and Challenges of Adopting KMM

Kotlin Multiplatform Mobile is a powerful technology, but its adoption requires a balanced approach. Let’s examine the key advantages and typical challenges that teams face.

Advantages of KMM

The first and foremost advantage is reducing code duplication. According to JetBrains Case Studies (2024), teams that adopted KMM reduce duplicated code by 60–80% for the network layer and by 40–50% for business logic overall. This directly impacts development speed and the number of bugs.

The second advantage is performance at the level of native applications. Unlike hybrid frameworks, KMM does not add abstraction layers between the UI and the system. Business logic code runs as fast as if it were written in Swift or Kotlin for each platform separately.

Challenges of Adoption

The main challenge is team qualification. Developers need to know Kotlin (for the shared module) as well as Swift and Jetpack Compose (for the UI). Finding a universal specialist is difficult, so teams usually consist of Android and iOS developers who jointly maintain the shared module.

The second challenge is tooling. KMM requires configuring Gradle, CocoaPods, or Swift Package Manager, as well as integrating with Xcode. In the early stages of a project, build configuration issues are common, especially when working with C libraries.

The third challenge is debugging. When a bug occurs at the intersection of Kotlin/Native and Swift, determining its cause is more difficult than in a monolithic application. JetBrains is continuously improving debugging tools, but in practice, teams spend up to 20% of their time on infrastructure tasks.