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

Выбор между Kotlin Multiplatform и Flutter определяет архитектуру мобильного продукта на годы вперёд: от него зависят бюджет разработки, скорость найма команды и то, насколько глубоко приложение сможет работать с камерой, Bluetooth или платёжными SDK. В этом материале — предметное сравнение по 12 параметрам, кейсы Netflix, McDonald's и Google Pay, а также чек-лист, с которым мы разбираем эту задачу на старте проекта кроссплатформенной разработки в YuSMP Group.

Сравнить Flutter, React Native, KMP и натив под свой проект с учётом RuStore и российских SDK можно бесплатно: выбор мобильного стека.

Ошибка на этом этапе стоит дорого: переезд с одного фреймворка на другой на середине разработки почти всегда означает переписывание слоя логики или UI с нуля. Поэтому ниже — не общие рассуждения, а конкретные критерии: какие компании используют каждую технологию в проде, сколько весит итоговое приложение и в каких сценариях выбор становится очевидным.

Что такое 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 компаний

Плюсы KMP: нативная производительность и look&feel, минимальный overhead к размеру приложения, инкрементальное внедрение без переписывания UI, прямой доступ к платформенным API без прослойки. Минусы KMP: нужны две UI-команды (или Compose Multiplatform как компромисс), нет hot reload в привычном Flutter-понимании, iOS-разработчикам придётся освоить Kotlin для общего модуля.

Что такое 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.

Плюсы Flutter: единая кодовая база для Android, iOS, Web и десктопа, hot reload, зрелая экосистема pub.dev (35 000+ пакетов), pixel-perfect UI без платформенных различий. Минусы Flutter: нативный look&feel нужно имитировать вручную, overhead к размеру приложения из-за встроенного движка, platform channels добавляют задержку для «тяжёлых» нативных интеграций.

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

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

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 и другие паттерны.

Тестирование и CI/CD

В KMP общий модуль тестируется стандартным kotlin.test, а платформенные части — нативными инструментами: XCTest на iOS, JUnit/Espresso на Android. Это удобно для команд, у которых уже настроен CI под нативную сборку, но требует поддерживать два пайплайна параллельно. Flutter тестируется единым набором — flutter test для unit- и widget-тестов, integration_test для end-to-end сценариев — и один и тот же CI-джоб прогоняет тесты для всех платформ сразу, что упрощает конфигурацию для небольших команд без выделенного DevOps-инженера.

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

Производительность 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:

Для рынков с дорогим мобильным трафиком (Индия, ЮВА, Африка) или с лимитом на размер 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:

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

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

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-разработчиков на рынке больше, и онбординг быстрее.

Сколько стоит разработка на KMP и Flutter

Точная смета всегда зависит от объёма функций, но по нашей практике в YuSMP Group разница в подходах даёт узнаваемую разницу в бюджете и сроках на старте проекта.

Итог: для короткого MVP Flutter почти всегда обходится дешевле в моменте. Для продукта с горизонтом 3+ года и уже существующими нативными командами совокупная стоимость владения (TCO) на KMP часто оказывается ниже — за счёт меньшего объёма кода, который приходится переписывать при обновлениях iOS и Android SDK.

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

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

«Взяли 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 и первая загрузка.

Практический кейс: как мы выбираем технологию для клиента

На этапе технического аудита проекта мы разбираем задачу клиента по тем же критериям, что описаны выше в чек-листе. Три реальных по структуре сценария показывают, как это работает на практике.

Сценарий 1: банковское приложение с двумя нативными командами

У клиента уже есть отдельные iOS- и Android-команды, приложение прошло сертификацию безопасности, и любые изменения UI требуют согласования с комплаенс-отделом. Здесь KMP — очевидный выбор: общий модуль забирает на себя сетевой слой и валидацию транзакций, а обе команды продолжают работать в привычных SwiftUI и Jetpack Compose, не трогая уже одобренный интерфейс.

Сценарий 2: MVP маркетплейса за 10 недель

Стартап без действующей мобильной команды, срок — 10 недель до демо инвесторам, три платформы (Android, iOS, опционально Web-версия для внутреннего каталога). Здесь выигрывает Flutter: одна кодовая база, hot reload ускоряет итерации по UI, а pub.dev закрывает 80% типовых задач (карты, платежи, пуши) готовыми пакетами без написания нативного кода.

Сценарий 3: IoT-приложение для медицинского устройства

Приложение работает с Bluetooth Low Energy на постоянной основе, синхронизируется с HealthKit на iOS и требует стабильного фонового соединения на Android. Platform channels Flutter добавляют задержку и сложность именно в этой части, поэтому мы рекомендуем KMP с нативным UI — прямой доступ к BLE-стеку и HealthKit/Health Connect без прослойки сериализации.

Общий принцип: чем ближе задача к «нужен один и тот же экран на двух платформах быстро» — тем увереннее чаша весов склоняется к Flutter. Чем больше в проекте нативных интеграций, существующего кода и требований к look&feel — тем увереннее к KMP.

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

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

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

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

Кроссплатформенная разработка перестала быть компромиссным решением «для тех, кто экономит» — сейчас на неё приходится заметная и растущая часть новых мобильных проектов на рынке, включая продукты с высокими требованиями к производительности и безопасности. В России Flutter особенно популярен у digital-агентств и стартапов за счёт скорости запуска MVP, а KMP набирает обороты в enterprise-сегменте, где уже есть нативные Android-команды и легче обосновать постепенное внедрение, а не полную смену стека.

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 недели онбординга, а не полного переобучения.

Что дешевле — KMP или Flutter?
Для короткого MVP Flutter обычно дешевле: одна команда закрывает Android и iOS сразу. Для продукта с горизонтом 3+ года совокупная стоимость владения на KMP часто ниже — общий модуль сокращает объём кода, который приходится переписывать при обновлениях iOS и Android SDK.

Можно ли использовать KMP и Flutter в одном приложении?
Технически да, но на практике это редкий и рискованный сценарий: два runtime увеличивают размер приложения и усложняют отладку. Чаще встречается постепенная миграция — например, замена Flutter-модуля на KMP при переезде с гибридного решения на более нативное, но не одновременная работа обоих фреймворков в одном экране.