В каких mobile-проектах Kotlin Multiplatform является сильным выбором, а где лучше выбрать native или другую cross-platform альтернативу?

Когда KMP — сильный выбор

Kotlin Multiplatform хорошо подходит для проектов, где основная бизнес-логика платформонезависима, а команда уже работает на Kotlin (Android). Типичные сценарии:

• Kotlin-first Android-команда расширяется на iOS: разработчики знают язык, можно переиспользовать domain/data-слой без переписывания.
• Финтех, e-commerce, B2B-приложения: сложная бизнес-логика (расчёты, валидация, маппинг данных) выносится в commonMain, UI остаётся нативным.
• Приложения с богатым offline-режимом: SQLDelight + KMP позволяют использовать одну схему БД и SQL-запросы на Android и iOS одновременно.
• Постепенная миграция: KMP интегрируется в существующий нативный проект через CocoaPods/SPM (iOS) или AAR (Android) — нет необходимости переписывать всё сразу.

Когда лучше выбрать нативный подход

• Сложный UI с анимациями и жестами: SwiftUI и Jetpack Compose дают доступ к системным API без обёрток. Compose Multiplatform покрывает часть сценариев, но отстаёт в зрелости.
• Высокопроизводительная графика/AR/camera: Metal (iOS) и Vulkan/OpenGL (Android) не имеют единого KMP-абстракционного слоя — platform-specific код неизбежен.
• Команда без Kotlin-экспертизы: если iOS-разработчики пишут только на Swift, KMP создаст барьер знаний и замедлит команду.
• Маленький MVP за 4–8 недель: нативные инструменты быстрее для прототипирования, если команда однородна по платформе.

Когда стоит рассмотреть Flutter или React Native

• Flutter: если UI должен быть идентичен на обеих платформах (брендовые дизайн-системы без платформенных виджетов), команда знает Dart. Flutter рисует UI сам через Skia/Impeller — нет зависимости от нативных компонентов.
• React Native: если фронтенд-команда (TypeScript/React) расширяется в мобайл. Экосистема npm доступна, но bridge-архитектура создаёт риски производительности для сложных анимаций.

Практическая матрица выбора

// Псевдокод критериев
fun choosePlatform(
    teamKnowledge: Set<String>,
    uiComplexity: Level,
    sharedLogicRatio: Float, // 0.0..1.0
    timeToMarket: Weeks
): Recommendation {
    return when {
        "kotlin" in teamKnowledge && sharedLogicRatio > 0.4 -> KMP
        uiComplexity == Level.HIGH && "swift" in teamKnowledge -> Native
        "dart" in teamKnowledge && sharedLogicRatio > 0.7 -> Flutter
        "typescript" in teamKnowledge -> ReactNative
        else -> Native // default: нанять нативных разработчиков
    }
}

Риски найма и долгосрочной поддержки

KMP-разработчики на рынке редки — большинство это Android-разработчики с экспертизой KMP. iOS-специалисты часто воспринимают KMP как угрозу своему стеку, что создаёт культурное сопротивление в команде. Учитывайте это при планировании найма.

Подводные камни

• Compose Multiplatform ≠ Kotlin Multiplatform: KMP отвечает за shared-логику, CMP — за shared-UI. Путаница приводит к завышенным ожиданиям по переиспользованию UI-кода.
• iOS-симулятор vs реальное устройство: код, написанный для iosX64 (симулятор), может вести себя иначе на iosArm64 (устройство) из-за ABI-различий.
• Kotlin/Native GC vs ARC: до Kotlin 1.9.20 объекты в Kotlin/Native использовали другую модель памяти. Убедитесь, что команда понимает текущую GC-модель (experimental в 1.9, stable в 2.0).
• Gradle-сложность: мультиплатформенные build-скрипты с несколькими target-ами сложнее отлаживать. Время сборки растёт нелинейно с добавлением targets.
• Библиотечная экосистема: многие популярные Android-библиотеки (Room, Retrofit, Dagger) не имеют KMP-версий. Альтернативы (SQLDelight, Ktor, Koin) зрелые, но требуют обучения.
• Отладка на iOS: нет нормальной интеграции Kotlin-отладчика с Xcode. Отлаживать Kotlin/Native код в production-сценариях существенно сложнее, чем Android.

• Сравнивать Kotlin Multiplatform с альтернативами по одному признаку
• Путать личную привычку с инженерным критерием выбора
• Не учитывать migration cost и vendor/ecosystem lock-in

• Сравнивает Kotlin Multiplatform по нескольким инженерным осям
• Не путает популярность с пригодностью
• Понимает migration cost и долгосрочную поддержку