Kotlin Multiplatform Mobile — що це таке, ключові поняття та архітектура KMM

Що таке Kotlin Multiplatform Mobile?

Kotlin Multiplatform Mobile (KMM) — це технологія, яка дозволяє писати спільну бізнес-логіку мобільного додатку на Kotlin та використовувати її на iOS і Android без дублювання коду. На відміну від Ionic або Cordova, KMM не рендерить інтерфейс у WebView — UI залишається повністю нативним і пишеться на SwiftUI (iOS) та Jetpack Compose (Android).

KMM був анонсований JetBrains у 2019 році як частина стратегії Kotlin Multiplatform. Ключова відмінність від інших крос-платформених рішень — фреймворк не намагається уніфікувати UI, а фокусується на поширенні саме того коду, який дійсно однаковий для обох платформ: мережеві запити, моделі даних, валідація форм, бізнес-правила та робота з базами даних.

За даними JetBrains Developer Survey (2025), KMM використовують 14% мобільних розробників, і цей показник зростає на 5% щорічно. Технологію обирають компанії з високими вимогами до продуктивності та нативного користувацького досвіду, для яких гібридні рішення неприйнятні.

Архітектура KMM: спільний модуль та платформені реалізації

Архітектура KMM складається з трьох модулів: shared (спільний код на Kotlin), iosApp (нативний iOS-додаток на Swift) та androidApp (нативний Android-додаток на Kotlin). Спільний модуль компілюється в JAR для Android і в універсальний фреймворк (Apple Framework) для iOS.

Спільний модуль: що виноситься в спільний код

У спільний модуль потрапляють всі шари, що не залежать від платформи: мережевий шар на Ktor Client, моделі даних із серіалізацією через kotlinx.serialization, репозиторії для керування даними, валідація форм та бізнес-правила (наприклад, розрахунок вартості доставки або перевірка прав доступу).

Спільний модуль використовує Gradle Multiplatform Plugin та містить три набори вихідних кодів: commonMain (спільний код), androidMain (специфічні для Android реалізації) та iosMain (специфічні для iOS реалізації). Компілятор Kotlin/Native перетворює спільний код на нативну бібліотеку для iOS, яка підключається до Swift-проєкту через XCFramework.

Платформені модулі

Android-модуль — це стандартний Android-додаток на Kotlin з Jetpack Compose або ViewBinding. Спільний модуль підключається як звичайна Gradle-залежність, і всі класи з commonMain доступні напряму.

iOS-модуль — це Xcode-проєкт на Swift або Objective-C. Спільний модуль підключається через CocoaPods, Swift Package Manager або XCFramework. Kotlin/Native генерує Objective-C заголовки для експорту Kotlin-типів, роблячи їх доступними з Swift.

Механізм expect/actual в KMM

expect/actual — це механізм Kotlin Multiplatform, який дозволяє оголосити API в спільному коді (expect declaration) та надати його реалізацію окремо для кожної платформи (actual declaration). Компілятор слідкує, щоб actual існував для кожної цільової платформи.

Типові сценарії використання expect/actual: отримання поточного часу з урахуванням часового поясу, робота з SharedPreferences (Android) / UserDefaults (iOS), криптографічні функції та генерація UUID. На кожній платформі використовується власний системний API.

Без expect/actual було б неможливо мати єдиний код бізнес-логіки, оскільки API для роботи з файловою системою, мережею та сховищем відрізняються між iOS та Android на рівні системних викликів. Механізм гарантує, що розробник не забуде реалізувати платформену частину.

Для платформених викликів, таких як робота з камерою або біометрією, KMM пропонує механізм expect/actual у поєднанні з плагінами, аналогічними Cordova, але на Kotlin/Native. JetBrains також випустила бібліотеку kotlinx-datetime, яка абстрагує роботу з датами та часом.

Приклади коду на KMM

Розглянемо базову структуру KMM-проєкту з оголошенням expect-функції для генерації UUID та її реалізацією під iOS та Android.

// commonMain — загальне оголошення
expect fun generateUUID(): String

// androidMain — реалізація для Android
actual fun generateUUID(): String {
    return java.util.UUID.randomUUID().toString()
}

// iosMain — реалізація для iOS
actual fun generateUUID(): String {
    return platform.Foundation.NSUUID().UUIDString
}

У спільному коді оголошується expect fun generateUUID(). Для Android використовується java.util.UUID, для iOS — NSUUID з Foundation framework. У решті коду спільного модуля ця функція викликається без урахування платформи.

Приклад мережевого запиту з використанням Ktor Client у спільному коді:

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())
    }
}

Цей код працює на обох платформах без змін. Ktor Client використовує OkHttp під Android та NSURLSession під iOS автоматично, без додаткової конфігурації. Серіалізація JSON через kotlinx.serialization також крос-платформена.

Порівняння KMM з Flutter та React Native

KMM займає унікальну позицію серед крос-платформених технологій, оскільки не намагається замінити нативний UI на відміну від Flutter та React Native. KMM — це рішення для поширення логіки, а не для уніфікації інтерфейсу.

Основна перевага KMM — повний контроль над UI. Якщо додаток повинен виглядати та поводитись як нативний на кожній платформі (наприклад, використовувати iOS TabBar та Android BottomNavigation з платформеними анімаціями), KMM — єдине крос-платформене рішення, що забезпечує це без обхідних шляхів.

Недолік — команда повинна володіти Kotlin, Swift, Jetpack Compose та SwiftUI одночасно, що ускладнює найм. Flutter та React Native вимагають знання однієї мови та одного фреймворку.

Переваги та складнощі впровадження KMM

Kotlin Multiplatform Mobile — потужна технологія, але її впровадження потребує зваженого підходу. Розглянемо ключові переваги та типові складнощі, з якими стикаються команди.

Переваги KMM

Перша і головна перевага — скорочення дублювання коду. За даними JetBrains Case Studies (2024), команди, які впровадили KMM, скорочують обсяг дубльованого коду на 60–80% для мережевого шару та на 40–50% для бізнес-логіки в цілому. Це безпосередньо впливає на швидкість розробки та кількість багів.

Друга перевага — продуктивність на рівні нативних додатків. На відміну від гібридних фреймворків, KMM не додає шарів абстракції між UI та системою. Код бізнес-логіки виконується так само швидко, як якщо б він був написаний на Swift або Kotlin для кожної платформи окремо.

Складнощі впровадження

Основна складність — кваліфікація команди. Розробники повинні знати Kotlin (для спільного модуля), а також Swift та Jetpack Compose (для UI). Знайти універсального спеціаліста складно, тому зазвичай формується команда з Android та iOS розробників, які спільно ведуть спільний модуль.

Друга складність — інструментарій. KMM потребує налаштування Gradle, CocoaPods або Swift Package Manager, а також інтеграції з Xcode. На ранніх етапах проєкту часті проблеми з конфігурацією збірки, особливо при роботі з C-бібліотеками.

Третя складність — налагодження. Коли баг виникає на стику Kotlin/Native та Swift, визначити його причину складніше, ніж у монолітному додатку. JetBrains постійно покращує інструменти налагодження, але на практиці командам доводиться витрачати до 20% часу на інфраструктурні завдання.