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: shared модуль и платформенные реализации

Архитектура KMM состоит из трёх модулей: shared (общий код на Kotlin), iosApp (нативное iOS-приложение на Swift) и androidApp (нативное Android-приложение на Kotlin). Shared модуль компилируется в JAR для Android и в универсальный фреймворк (Apple Framework) для iOS.

Shared модуль: что выносится в общий код

В shared модуль попадают все слои, не зависящие от платформы: сетевой слой на Ktor Client, модели данных с сериализацией через kotlinx.serialization, репозитории для управления данными, валидация форм и бизнес-правила (например, расчёт стоимости доставки или проверка прав доступа).

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

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

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

iOS-модуль — это Xcode-проект на Swift или Objective-C. Shared модуль подключается через 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. В остальном коде shared модуля эта функция вызывается без учёта платформы.

Пример сетевого запроса с использованием 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 (для shared модуля), а также Swift и Jetpack Compose (для UI). Найти универсального специалиста сложно, поэтому обычно формируется команда из Android и iOS разработчиков, которые совместно ведут shared модуль.

Вторая сложность — инструментарий. KMM требует настройки Gradle, CocoaPods или Swift Package Manager, а также интеграции с Xcode. На ранних этапах проекта часты проблемы с конфигурацией сборки, особенно при работе с C-библиотеками.

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