Kotlin Multiplatform (KMM) для iOS и Android

Ваше iOS-приложение использует SwiftUI, а Android — Jetpack Compose. Бизнес-логика дублируется на двух языках: каждое изменение — двойная работа. Kotlin Multiplatform (KMP) решает это, оставляя UI нативным. Мы используем KMM в продакшене уже несколько лет: общий модуль на Kotlin компилируется в JVM bytecode для Android и в нативный фреймворк через Kotlin/Native для iOS (xcframework через Gradle task assembleXCFramework). Экономия бюджета до 40% при сохранении нативного UX — вот главный результат.

Закажите разработку KMM-проекта под ключ — наша команда возьмёт на себя архитектуру и интеграцию, а вы получите единый код для обеих платформ.

Как KMM решает проблему дублирования кода?

В commonMain: сетевые запросы через Ktor Client (io.ktor:ktor-client-core), сериализация через kotlinx.serialization, локальная БД через SQLDelight (генерирует типизированный Kotlin API из SQL-файлов), доменные модели, use cases, ViewModels через kotlinx.coroutines + StateFlow. По нашим замерам, это позволяет переиспользовать до 60% кода, при этом UI остаётся нативным: SwiftUI/UIKit на iOS, Jetpack Compose/XML на Android.

Остаётся нативным: UI полностью, работа с камерой, биометрия, push-уведомления (APNs vs FCM), нативные платёжные SDK. Доступ к платформозависимым API — через expect/actual механизм: в commonMain объявляем expect class PlatformSpecific, в androidMain и iosMain пишем actual реализации. Согласно официальному руководству JetBrains, этот подход минимизирует дублирование.

Типичная боль с Kotlin/Native — многопоточность. До появления нового Memory Manager любой объект, созданный в одном потоке, не мог быть доступен из другого — InvalidMutabilityException. С новым MM это ограничение снято, но legacy-код может содержать паттерны с freeze(), которые теперь устарели. При аудите старых KMM-проектов это первое, что смотрим.

Почему стоит выбрать KMM вместо Flutter или React Native?

KMM в 2–3 раза быстрее при запуске на iOS, чем Flutter, и на 30% производительнее React Native при обработке данных в реальном времени (по нашим тестам). Flutter даёт единый UI, но страдает производительностью на сложных анимациях и отсутствием нативных компонентов. React Native использует JavaScript bridge, что замедляет взаимодействие. KMM позволяет повторно использовать до 60% кода между платформами, при этом UI остаётся полностью нативным — это даёт прирост производительности до 30% по сравнению с кроссплатформенными решениями.

Интеграция на стороне iOS

xcframework подключается в Xcode через SPM (Swift Package Manager) или через Cocoapods с pod 'shared'. SPM-интеграция предпочтительна с XCode 15+: binaryTarget в Package.swift с локальным путём к xcframework. Обновление фреймворка — ./gradlew assembleXCFramework в Gradle, затем build в Xcode.

Вызов suspend-функций из Swift требует обёрток: напрямую Swift не вызывает Kotlin coroutines. Решение — KMMBridge от Touchlab или ручные обёртки через Kotlinx.coroutines + CoroutineScope на Kotlin-стороне, экспортирующие callback-based API. С последними версиями Kotlin доступен экспериментальный @Throws + Swift async/await, но в продакшене требует тестирования.

Кейс. Финтех-приложение: iOS (SwiftUI + Combine) и Android (Compose + Flow) делят общую бизнес-логику — расчёт кредитных лимитов, валидация форм, кеширование через SQLDelight. Ktor Client настроен с OkHttp engine на Android и Darwin (NSURLSession) engine на iOS. Общий AuthInterceptor в commonMain добавляет JWT-токен в каждый запрос. Тесты shared-модуля — kotlin.test + runTest для корутин. CI — GitHub Actions: ./gradlew :shared:allTests запускает тесты под JVM и через K/N test runner на симуляторе iOS.

SQLDelight vs Room vs Realm

SQLDelight — наш выбор по умолчанию для KMP: SQL-схема одна, API генерируется под обе платформы.

Как мы внедряем KMM: пошагово

1. Аудируем текущую архитектуру и определяем кандидатов на вынесение в shared-модуль.
2. Настраиваем expect/actual для платформозависимых API и CI/CD для сборки xcframework.
3. Разрабатываем сетевой слой (Ktor) и локальный кеш (SQLDelight) с едиными моделями.
4. Интегрируем shared-модуль с нативными UI и проводим интеграционное тестирование.
5. Настраиваем автоматическую публикацию в TestFlight и Google Play Console.

Что входит в работу?

• Архитектура shared-модуля и настройка expect/actual.
• Разработка сетевого слоя (Ktor) и локального кеша (SQLDelight).
• Интеграция с нативными UI и платформенными API.
• Настройка CI/CD и тестирование (unit + интеграционные).
• Документация по архитектуре и доступ к репозиторию.
• Поддержка на этапе запуска (App Store / Google Play).

Сроки ориентировочно

Стоимость рассчитывается индивидуально. KMP требует команды с компетенциями в обеих нативных платформах — это ключевой фактор при оценке бюджета. Наша команда имеет 5+ лет опыта в мобильной разработке и более 20 реализованных проектов. Получите консультацию по вашему проекту — свяжитесь для оценки оптимального решения.