Яндекс.Метрика
Услуги Портфолио Контакты БлогНовости +7 (800) 511‑32‑27 Обсудить проект
Мобильная разработка

Kotlin Multiplatform vs Flutter: что лучше выбрать для проекта

Обновлено 5 сентября 2026·18 мин чтения
Виктор Романов
Автор материалаВиктор РомановВедущий Android-разработчик, YuSMP Group
Профиль автора
Kotlin Multiplatform vs Flutter: что лучше выбрать для проекта
TL;DR — KMP и Flutter оба production-ready в 2026. KMP разделяет только бизнес-логику, оставляя UI нативным; Flutter делит и логику, и UI через Impeller. Выбирайте KMP, если у вас зрелые нативные команды и нужна постепенная миграция. Выбирайте Flutter, если стартуете с нуля и нужен единый pixel-perfect UI на всех платформах одновременно. Compose Multiplatform — компромисс для тех, кто хочет разделить UI на Kotlin без Dart.

Что такое Kotlin Multiplatform

Kotlin Multiplatform (KMP) — технология JetBrains для разделения кода между платформами. Ключевая идея: общий код пишется на Kotlin и компилируется нативно для каждой цели — в JVM-байткод для Android, в нативный бинарник через Kotlin/Native для iOS, в JS или WebAssembly для браузера.

Что именно шарится через KMP: бизнес-логика, сетевой слой (Ktor), хранилище данных (SQLDelight), ViewModel, маппинг, валидация. Что остаётся нативным по умолчанию: весь UI — на iOS используется SwiftUI или UIKit, на Android — Jetpack Compose.

Ключевые вехи зрелости:

  • Ноябрь 2023 — KMP получил статус Stable
  • Май 2025 — Compose Multiplatform для iOS стал production-ready
  • 2026 — по данным JetBrains Developer Survey, KMP используют более 20 000 компаний

Что такое Flutter

Flutter — фреймворк Google на языке Dart для создания кроссплатформенных приложений с единым UI. Особенность архитектуры: Flutter не использует нативные компоненты платформы для рендеринга. Вместо этого он рисует каждый пиксель собственным движком Impeller (замена Skia с Flutter 3.10), который работает поверх Metal на iOS и Vulkan/OpenGL на Android.

Это даёт pixel-perfect консистентность между платформами и позволяет создавать одинаковый UI на iOS, Android, Web, macOS, Windows и Linux из одной кодовой базы. Обратная сторона — нативный look&feel платформы нужно имитировать вручную, и Flutter не «автоматически» следует гайдлайнам Apple Human Interface Guidelines.

Hot reload — флагманская фича: изменения в Dart-коде отображаются в эмуляторе за сотые доли секунды без перезапуска приложения и потери состояния. Это существенно ускоряет цикл разработки и итерации по UI.

Таблица сравнения по 12 параметрам

"expect/actual" декларации, Kotlin/Native interop со Swift/ObjC
Параметр Kotlin Multiplatform Flutter
Язык Kotlin Dart
UI Нативный (SwiftUI/Compose) или Compose Multiplatform Собственный движок Impeller, единый на всех платформах
Производительность Нативная (компилируется в машинный код каждой платформы) Близкая к нативной (60/120 fps, Impeller AOT)
Размер приложения +0,1–0,5 МБ (только Kotlin stdlib) +5–10 МБ (встроенный движок Impeller)
Доступ к нативным API Platform channels (MethodChannel), FFI для нативного кода
Миграция существующего приложения Инкрементальная — начни с одного модуля Как правило, переписывается с нуля или Add-to-App
Hot reload Нет (только стандартная пересборка Gradle/Xcode) Есть, мгновенный (фирменная фича)
Look & feel платформы Нативный по умолчанию (SwiftUI/Compose) Нужно настраивать вручную через Cupertino/Material виджеты
Кривая обучения Низкая для Android-команды, высокая для iOS-разработчиков без Kotlin Умеренная: Dart прост, но экосистема отличается
Платформы Android, iOS, macOS, Linux, Windows, Web (WASM) Android, iOS, Web, macOS, Windows, Linux
Экосистема библиотек Быстро растёт; Ktor, SQLDelight, Koin, Decompose Зрелая; pub.dev — более 35 000 пакетов
Поддержка JetBrains + Google (Jetpack Compose) Google

Архитектура и технический подход

KMP использует концепцию expect/actual: в общем модуле объявляется «ожидаемая» функция или класс (expect fun getPlatform(): String), а в платформенных модулях прописывается «фактическая» реализация (actual fun getPlatform() = "Android"). Это позволяет иметь общий интерфейс с нативной реализацией под каждую платформу — без оберток и рефлексии.

Типичная структура KMP-проекта:

  • shared/commonMain — бизнес-логика, UseCases, Repository, DTO
  • shared/androidMain — платформенные реализации для Android
  • shared/iosMain — платформенные реализации для iOS (Swift interop)
  • androidApp — Jetpack Compose UI
  • iosApp — SwiftUI

Flutter — единый проект на Dart. Весь код (логика и UI) находится в одном дереве файлов. Архитектурно это чище для небольших команд: нет необходимости тянуть Gradle multiproject configuration. При росте проекта — рекомендуется разбивать на Dart packages.

С точки зрения архитектуры приложения: оба фреймворка нейтральны — поддерживаются MVVM, MVI, Clean Architecture, BLoC и другие паттерны.

Разработка мобильных приложений на заказ
Узнайте цену

Производительность и размер приложения

Производительность UI. Flutter достигает стабильных 60/120 fps за счёт собственного Impeller-движка, рисующего каждый кадр напрямую через Metal/Vulkan. KMP с нативным UI также выдаёт нативную производительность — ограничений, связанных с фреймворком, нет: это тот же Jetpack Compose или SwiftUI, которые были бы в чистом нативном приложении.

Холодный старт (cold start). Нативный UI в KMP стартует так же быстро, как чистое нативное приложение. Flutter имеет небольшую задержку первого кадра (~50–100 мс) из-за инициализации движка — на современных устройствах это незаметно, но на бюджетных Android-смартфонах с 2 ГБ RAM заметно при первом запуске.

Размер APK/IPA. Это реальный differentiator:

ТехнологияOverhead к APKПричина
KMP (только shared логика)+0,1–0,5 МБТолько Kotlin stdlib, без UI
Flutter (минимальное приложение)+5–10 МБДвижок Impeller (~4 МБ) + Dart runtime
Flutter (реальное приложение)+8–15 МБДвижок + пакеты + ресурсы

Для рынков с дорогим мобильным трафиком (Индия, ЮВА, Африка) или с лимитом на размер OTA-обновления разница в 10 МБ влияет на конверсию установок. В России и СНГ для большинства продуктов это несущественно.

Доступ к нативным API (Bluetooth, NFC, камера, звонки). KMP выигрывает: написанный Kotlin-код напрямую вызывает Android API, а через Kotlin/Native — Swift/ObjC-фреймворки iOS без прослойки. Flutter использует platform channels — передачу данных через JSON-сериализацию в нативный код и обратно. Это добавляет латентность и сложность для «тяжёлых» нативных фич (аудиопотоки, Bluetooth Low Energy, ARKit).

Кто использует в продакшене

KMP (20 000+ компаний по данным JetBrains, 2025):

  • Netflix — общая UI-логика и аналитические модули для Android и iOS
  • McDonald's — мобильное приложение заказов, общий бизнес-слой
  • Duolingo — грамматический движок и алгоритмы повторения
  • Cash App (Block) — финансовый кор и валидация транзакций
  • Forbes — контентная платформа, сетевой слой
  • Philips — IoT-приложения для медицинских устройств

Flutter (от Google, продакшн-примеры):

  • Google Pay — кошелёк на Flutter на Android и iOS
  • BMW — автомобильное приложение BMW Connected
  • eBay Motors — листинг и торговля авто
  • Alibaba (Xianyu) — маркетплейс подержанных товаров, 50+ млн MAU
  • Tencent — ряд внутренних B2B-инструментов
  • Nubank — бразильский необанк, Flutter с 2017 года

Когда выбирать KMP

KMP — оптимальный выбор в следующих сценариях:

У вас уже есть нативные команды

Если в компании работают отдельные iOS- и Android-разработчики, KMP позволяет им продолжить работать на привычных инструментах (Swift/Kotlin, Xcode/Android Studio) и при этом разделить бизнес-логику. Переход не требует переобучения на новый язык и фреймворк.

Нужна инкрементальная миграция

KMP позволяет внедрять разделение кода постепенно — начать с одного модуля (сетевой слой или аналитика), оценить результат и расширять. Flutter в существующие нативные приложения встраивается через Add-to-App, но это сложнее и менее органично.

Критичны нативные возможности платформы

Если приложение активно работает с Bluetooth LE, NFC, ARKit/ARCore, обработкой звонков, HealthKit — KMP с нативным UI даёт прямой доступ без platform channels. Это критично для медицинских, IoT и телеком-приложений.

Важен нативный look&feel

Финансовые, государственные и корпоративные приложения, где пользователи ждут привычных iOS- или Android-паттернов. С KMP iOS-пользователи видят нативный SwiftUI, Android-пользователи — Jetpack Compose. Flutter требует ручной кастомизации Cupertino-виджетов, чтобы добиться того же.

Команда сильна в Kotlin

Если Android-разработчики уже пишут на Kotlin, порог входа в KMP минимален. iOS-разработчики осваивают только общий модуль и могут продолжать работать со SwiftUI.

Когда выбирать Flutter

Старт с нуля, небольшая команда

Один разработчик или небольшая команда, которая хочет покрыть Android + iOS + Web одновременно. Flutter с единой кодовой базой и hot reload позволяет итерировать быстрее, чем поддерживать несколько нативных проектов.

Нужен pixel-perfect кастомный дизайн

Если дизайнер нарисовал уникальный UI, который должен выглядеть одинаково на всех платформах — Flutter это делает из коробки. Нативный UI всегда имеет платформенные нюансы (шрифты, отступы, анимации), KMP их не устраняет.

Прототип или MVP за 2–3 месяца

Hot reload, богатая библиотека виджетов и большое сообщество сокращают time-to-market. На Flutter легко собрать MVP-версию для App Store и Google Play без параллельной разработки.

Приложение для B2B или внутренние инструменты

Корпоративные дашборды, POS-системы, складские приложения — где look&feel менее критичен, а важны скорость и охват платформ. Flutter здесь выигрывает.

Единый UI для Web и мобайла

Flutter Web позволяет деплоить то же приложение в браузер. Подходит для внутренних инструментов (не публичных сайтов — там ограничения по SEO). KMP Web-поддержку развивает через WASM, но экосистема менее зрела.

Гибридный подход: KMP + Compose Multiplatform

С мая 2025 года Compose Multiplatform для iOS стабилен. Это создаёт третий вариант, который часто упускают при сравнении:

  • KMP + Native UI — максимальный нативный look&feel, отдельные UI-команды
  • KMP + Compose Multiplatform — единый UI на Kotlin без Dart, один язык на всё
  • Flutter — единый UI на Dart, самая большая экосистема готовых виджетов

KMP + Compose Multiplatform особенно привлекателен для команд, которые глубоко знают Jetpack Compose и хотят перенести этот опыт на iOS без изучения Dart. Compose UI рендерится через Skiko (Skia bindings for Kotlin) — производительность сопоставима с Flutter, но экосистема Compose MP пока меньше.

Что выбрать внутри KMP:

КритерийKMP + Native UIKMP + Compose MP
Нативный look&feelПолныйНужна ручная настройка
Единый языкНет (Kotlin + Swift)Да (только Kotlin)
Зрелость iOS-UISwiftUI — зрелыйCompose MP — стабилен с 2025
Размер командыДве UI-командыОдна UI-команда
Кросс-платформенная разработка под ключ
Узнать подробнее

Стратегия найма: рынок разработчиков

Это один из наиболее практических аргументов, который часто игнорируется при технологическом выборе.

Flutter-разработчики: рынок сформирован с 2018–2019 года. Найти опытного Flutter-разработчика проще, чем KMP-специалиста. Средняя вилка в России — 180 000–350 000 руб./мес. для mid/senior. Dart — специфический язык, который Flutter-разработчики учили именно ради Flutter.

KMP-разработчики: как таковой нишевой специализации нет. Любой Kotlin-разработчик с Android-опытом может за 2–4 недели освоить KMP на рабочем уровне — expect/actual, Ktor, coroutines в общем коде. Это означает, что пул кандидатов гораздо шире (все Android-разработчики). iOS-часть по-прежнему требует Swift-разработчика, но его задача сводится к нативному UI и интеграции с shared-модулем.

Практический вывод: если у вас сильная Android-команда и один iOS-разработчик, KMP позволит Android-разработчикам покрыть общую логику без найма специализированных Flutter-разработчиков. Если команда формируется с нуля — Flutter-разработчиков на рынке больше, и онбординг быстрее.

Антипаттерны при выборе технологии

Ошибки, которые мы видим в проектах чаще всего:

«Взяли Flutter, а приложение интенсивно использует Bluetooth LE»
Platform channels не дают прямого доступа к BLE-стеку на уровне нативных SDK. Проект превращается в гибрид с нативными плагинами на Android и iOS — и теряется главное преимущество Flutter (единый код).

«Взяли KMP, iOS-команды нет и не планируется»
Если все разработчики — Android, а iOS-приложение откладывается на неопределённый срок, KMP даёт overhead без пользы. Flutter в этом сценарии логичнее.

«Выбрали Flutter, потому что Google его поддерживает»
Google закрыл несколько проектов с аналогичным уровнем поддержки (Stadia, Daydream, Duplex). Flutter имеет большое сообщество и 7+ лет истории, что снижает этот риск — но не устраняет его полностью. KMP поддерживается JetBrains (независимая компания) и используется внутри Google (Kotlin — официальный язык Android).

«Взяли KMP, не учли, что iOS-разработчики не знают Kotlin»
iOS-команда смотрит в shared-модуль на Kotlin и тратит месяцы на изучение незнакомого языка. В итоге iOS-разработчики не трогают общий код, и его поддерживают только Android-разработчики. Решение — заложить в план 2–4 недели на онбординг iOS-специалистов и чётко разграничить ответственность: iOS-команда отвечает за нативный UI, Android-команда — за shared-модуль.

«Выбрали Flutter Web для публичного сайта»
Flutter Web использует CanvasKit — весь UI рисуется на canvas. Поисковые боты видят пустую страницу; SSR отсутствует. Flutter Web подходит только для авторизованных SPA-инструментов, не для публичных сайтов, где важны SEO и первая загрузка.

Чек-лист для принятия решения

Ответьте на 7 вопросов — преобладающие «да» в каждой колонке укажут на выбор:

Вопрос→ KMP→ Flutter
Уже есть нативные iOS и Android команды?ДаНет
Нужна инкрементальная миграция существующего приложения?ДаНет
Приложение активно использует BT, NFC, ARKit, HealthKit?ДаНет
Нативный look&feel критичен (финтех, госсервис)?ДаНет
Команда формируется с нуля, важна скорость найма?НетДа
Нужен единый pixel-perfect дизайн на всех платформах?НетДа
Размер APK менее важен, чем скорость разработки?Да

Если ответы делятся 50/50 — рассмотрите KMP + Compose Multiplatform как компромисс: единый язык Kotlin, общий UI на Compose, нативная производительность.

Тренды 2026: куда движется кросс-платформа

KMP набирает долю среди enterprise. По данным JetBrains Developer Ecosystem Survey 2025, доля команд, использующих KMP в продакшене, выросла с 7% (2023) до 23% (2025). Основной драйвер — стабилизация Compose Multiplatform и поддержка Google (Android Studio имеет встроенный KMP Wizard с 2024).

Flutter развивает WASM и Impeller. Dart 3.x с поддержкой WASM открывает Flutter Web для сценариев с лучшей производительностью. Impeller заменил Skia на всех платформах и устранил janky frames — главную историческую претензию к Flutter.

AI-интеграция в мобайл. Оба фреймворка развивают on-device ML: KMP через Kotlin/Native с ONNX Runtime, Flutter — через tflite_flutter. По уровню поддержки Apple Core ML и Google ML Kit разрыва нет — оба подключаются через нативные биндинги.

Kotlin Multiplatform для серверного кода. Тренд 2025–2026: компании используют KMP не только для мобайла, но и для разделения кода между сервером (Ktor/Kotlin) и клиентом (Android/iOS). Это позволяет, например, шарить модели валидации и DTO между backend и frontend без дублирования.

Частые вопросы

В чём главное отличие KMP от Flutter?
KMP разделяет только бизнес-логику (сетевой слой, кэш, валидация), а UI остаётся нативным — SwiftUI на iOS и Jetpack Compose на Android. Flutter делит и логику, и UI: единый Dart-код рендерится собственным движком Impeller на всех платформах.

Можно ли внедрить KMP в уже существующее нативное приложение?
Да, именно в этом главное преимущество KMP. Технология поддерживает инкрементальное внедрение: начните с одного модуля (например, слоя API или аналитики) и постепенно расширяйте долю общего кода, не переписывая всё приложение.

Насколько зрел KMP в 2026 году?
KMP получил статус Stable в ноябре 2023 года. Compose Multiplatform для iOS стал production-ready в мае 2025 года. По данным JetBrains, более 20 000 компаний используют KMP в продакшене.

Подходит ли Flutter для веб-приложений?
Flutter Web подходит для авторизованных SPA-инструментов и внутренних дашбордов. Для публичных сайтов — нет: рендеринг через CanvasKit не индексируется поисковиками. Если нужны SEO и быстрая первая загрузка — используйте традиционный веб-фронтенд.

Насколько большим будет итоговый APK с Flutter?
Flutter добавляет около 5–10 МБ из-за встроенного движка Impeller. KMP добавляет только Kotlin stdlib — около 0,1–0,5 МБ. Для рынков с дорогим трафиком это важный фактор; для большинства российских продуктов — несущественный.

Нужно ли учить новый язык при переходе на KMP?
Android-разработчики — нет: Kotlin уже знакомый язык. iOS-разработчикам придётся освоить Kotlin для работы с shared-модулем, но нативный UI они пишут на привычном Swift. Это требует 2–4 недели онбординга, а не полного переобучения.

Обсудим ваш проект?

Соберём команду под вашу задачу и оценим проект за 2 дня — бесплатно.

Обсудить проект