Коротко. Flutter и — не две реализации одной идеи. Flutter — одна ставка: один движок рендеринга, один UI, все платформы. KMP — другая ставка: общая логика и нативный UI каждой платформы — если только вы не добавите сверху Compose Multiplatform, и тогда это становится ставкой «в форме Flutter», но с более молодой экосистемой. Какая из них правильная, куда сильнее зависит от навыков вашей команды и амбиций продукта по части UI, чем от любых бенчмарков. Мы разрабатываем на Flutter — и ниже конкретно скажем, когда сами отправили бы вас в сторону KMP.

Если нужен только ответ — переходите сразу к фреймворку принятия решения.

Сравниваете Flutter с React Native? Это отдельный пост. С полностью нативной разработкой на Swift/Kotlin? Тоже отдельный пост.

Наша позиция — сразу и открыто

Мы — Flutter-first агентство; работы публичны. Мы оценивали KMP для клиентов — основатель, который пишет этот текст, годами выпускал продакшн-код на Kotlin и следит за развитием KMP и SwiftUI, — но мы не выпускали продакшн-приложение на KMP, и было бы нечестно делать вид, что это не так. Поэтому этот пост аккуратен в двух вещах: там, где мы сравниваем developer experience, мы говорим о том, что показали наши оценочные проекты, а не намекаем на продакшн-пробег; а там, где KMP действительно лучший ответ, мы говорим это прямо — потому что сравнение, написанное так, чтобы всегда заканчиваться выводом «наймите нас», для вас бесполезно.

Что реально изменилось к 2026 году

KMP давно перестал быть экспериментальным вариантом, и сравнение, которое обращается с ним как с экспериментом, устарело.

  • Сам KMP стабилен и одобрен с обеих сторон. JetBrains объявила Kotlin Multiplatform стабильным в конце 2023 года, а Google на I/O 2024 официально рекомендовала его для общей бизнес-логики на Android. Netflix, McDonald's и Cash App используют общий KMP-код в продакшне в серьёзном масштабе.
  • Compose Multiplatform достиг стабильности на iOS в 2025 году. Слой общего UI от JetBrains теперь стабилен на Android, iOS и desktop; web-таргет всё ещё в бете. Это важно, потому что меняет само значение слова «KMP»: не только общая логика под нативными UI, но и общий UI тоже.
  • Активный фронтир сейчас — сторона Swift. Прямой экспорт Kotlin в Swift — без прослойки из Objective-C bridging headers — вышел в экспериментальном статусе и стоит в планах JetBrains на стабилизацию. Пока он не стабилен повсюду, на границе Kotlin и iOS остаётся трение, которое замечают нативные Swift-разработчики: экспортированные API ощущаются переведёнными, а не спроектированными.
  • Flutter тем временем не стоял на месте. Рендеринг на — устоявшийся дефолт, а десятилетие экосистемы фреймворка — pub.dev, тулинг, пул найма — это ровно то, с чем приходится конкурировать более молодому стеку.

Сравнение, которое большинство постов проводит неправильно

«Flutter vs KMP» — на самом деле два разных сравнения, и когда их сваливают в одну кучу, команды и приходят к неверным выводам.

Сравнение A: Flutter против KMP с нативными UI. Бизнес-логика — сеть, хранение данных, доменные правила, вью-модели — выносится в общий Kotlin-код, а интерфейс строится дважды: SwiftUI на iOS, Jetpack Compose на Android. Типичная доля общего кода — 40–70% кодовой базы. Взамен каждое приложение неотличимо от полностью нативного, потому что UI и есть полностью нативный.

Сравнение B: Flutter против Compose Multiplatform. Общим становится и UI. CMP на iOS рисует собственные пиксели через рендеринг семейства Skia — ровно та архитектурная ставка, которую Flutter сделал в 2017-м. В этот момент вы выбираете между двумя реализациями одной и той же идеи, где преимущества Flutter — зрелость, глубина экосистемы и широта платформ, а преимущество CMP в том, что язык и половина тулчейна — те самые, в которых уже живёт ваша Android-команда.

Постоянно спрашивайте себя, в каком из двух сравнений вы на самом деле находитесь. Ответ определяет почти всё, что ниже.

Шесть осей сравнения, которые реально имеют значение

1. Стратегия UI — настоящая развилка

  • KMP с нативными UI даёт то, чего Flutter архитектурно дать не может: каждый экран собран из собственных компонентов платформы, с платформенно-точным поведением в каждой детали физики скролла, контекстного меню и атрибутов accessibility. Если «неотличимо от нативного» — жёсткое требование, а в enterprise-продажах в банкинге или медицине оно иногда прописано в контракте, — это честный способ его выполнить, сохранив общую логику под интерфейсом.
  • Flutter даёт противоположную гарантию: одни и те же пиксели везде, дизайн-система, которой вы владеете целиком, и одна реализация каждого экрана. Для насыщенного брендом и анимацией кастомного UI — конца спектра, где живёт Arcana, — построить один раз лучше, чем строить дважды, и по стоимости, и по консистентности.
  • CMP на этой оси стоит рядом с Flutter, а не с нативной разработкой.

Честный вердикт: с этой оси и нужно начинать решение. Всё остальное — уточнения.

2. Состав команды — где на самом деле принимается большинство решений

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

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

Честный вердикт: есть Android/Kotlin-команда → KMP заслуживает роли вашей гипотезы по умолчанию. Мобильной команды ещё нет → с Flutter организация получится меньше.

3. Экосистема и шов на стороне iOS

У экосистемы Flutter десятилетие глубины: пакеты на pub.dev для большинства значимых SDK, зрелый тулинг, огромный корпус продакшн-историй (мы написали свою долю). Библиотечная экосистема KMP реальна и растёт — kotlinx, Ktor, SQLDelight, Koin надёжны, — но тоньше в длинном хвосте, а шов на стороне iOS — то место, где это чувствуется в оценочных проектах: пока прямой экспорт в Swift не стабилен повсюду, общие API, потребляемые из Swift, могут ощущаться как переведённый Kotlin, а не как нативный Swift, — и у ваших iOS-инженеров будет об этом своё мнение.

Честный вердикт: сегодня — однозначно Flutter, с честной сноской: это самый быстро движущийся фронт KMP.

4. Постепенное внедрение — тихая суперсила KMP

Flutter нельзя осмысленно внедрять в существующее нативное приложение по 10% за раз; add-to-app существует и работает (мы строим на нём миграции), но это путь к замене UI, а не к вечному сосуществованию. KMP спроектирован для обратного: выделите один модуль — сеть, синхронизацию, правила ценообразования, — сделайте его общим, выпустите, повторите. Без переписывания, без большого решения, обратимо на каждом шаге.

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

5. Производительность

Скучный ответ, которого мы честно придерживаемся: для подавляющего большинства приложений все три конфигурации достаточно быстры, и производительность решают архитектура и дисциплина ребилдов, а не фреймворк. Impeller у Flutter и нативные UI у KMP рендерят на скорости платформы; канвас-рендеринг CMP на iOS — тот же подход, который Flutter годами закалял, только в исполнении команды, которая находится ближе к началу той же дороги. Если ваш продукт живёт на границе возможностей рендеринга — графики в реальном времени, тяжёлая анимация, — зрелость Flutter там доказана; именно таким было решение по ExtraETF.

6. Долгосрочные риски

Риск Flutter — концентрация: он процветает, пока этого хочет Google, что смягчают открытый код и огромная установленная база. Риск KMP меньше и другой формы: Kotlin — официальный язык Android, весь бизнес JetBrains — инструменты для разработчиков, и Google со своей стороны поддерживает историю с общим кодом. Но конкретно CMP молод, и ставить общий UI на него — значит ставить на его дорожную карту. Ни один из рисков не оправдывает страха; оба оправдывают написание бизнес-логики за чистыми границами модулей — это и есть настоящая страховка, и она не зависит от фреймворка: тот же аргумент — в FAQ нашей основной страницы услуг.

Выбирайте Kotlin Multiplatform, если…

  • У вас есть существующее здоровое нативное приложение — особенно Android-first с Kotlin-командой — и боль в том, что логика пишется дважды, а не в UI.
  • Платформенно-точный нативный UI — жёсткое требование, и вы можете укомплектовать команду под SwiftUI + Compose.
  • Вы хотите постепенного, обратимого внедрения внутри приложений, которые уже выпускаете.
  • Ваша организация уже думает на Kotlin: серверный Kotlin, senior-инженеры на Android, тулинг JetBrains повсюду.

Выбирайте Flutter, если…

  • Вы строите новый продукт и хотите, чтобы одна команда выпускала в оба стора, — экономика, на которой работает всё наше портфолио.
  • Вы владеете своей дизайн-системой и хотите попиксельно одинаковый вид везде, включая web и desktop там, где они оправданны.
  • Вам нужны более глубокая экосистема и больший пул найма под сам фреймворк уже сегодня, а не после следующей вехи чьей-то дорожной карты.
  • Альтернатива, которую вы на самом деле рассматриваете, — CMP; в этом случае вы так или иначе выбираете архитектуру Flutter, и зрелость на стороне оригинала.

Короткий фреймворк принятия решения

Существующее нативное приложение, Kotlin-навыки в команде, UI остаётся нативным: KMP — и вам не нужно агентство вроде нашего, чтобы это услышать. Новый продукт, одна команда, кастомная дизайн-система, оба стора на один бюджет: Flutter. Тянет к Compose Multiplatform на новом продукте: поймите, что вы делаете ставку Flutter более молодым стеком, и принимайте решение по зрелости экосистемы, а не по симпатии к языку. Если всё ещё сомневаетесь, решающий фактор — команда, которую вы реально будете содержать через два года.

Часто задаваемые вопросы

Да, без оговорок — для общей бизнес-логики: KMP стабилен с конца 2023 года, Google рекомендует его для общей логики на Android, а компании вроде Netflix, McDonald's и Cash App используют его в продакшне в масштабе. Общий UI — половина с нюансами: Compose Multiplatform стабилен на Android, iOS и desktop с 2025 года, но его iOS-экосистема молода на фоне флаттеровской, а web-таргет всё ещё в бете. «Готов к продакшну» и «закалён в боях» — разные утверждения, и право на второе для общего UI на iOS ещё только зарабатывается.
Нет — в классической форме он отвечает на другой вопрос. KMP делает общей бизнес-логику, а каждая платформа сохраняет нативный UI, так что вы по-прежнему строите два интерфейса и держите два набора UI-навыков; Flutter делает общим всё, включая пиксели, поэтому одна команда выпускает в оба стора. Конфигурации сходятся, только если вы берёте Compose Multiplatform для общего UI — и в этот момент вы выбрали архитектурную ставку Flutter (канвас-рендеринг, одно дерево виджетов), реализованную более молодым стеком. Разные ставки подходят разным командам; ни одна не заменяет другую.
Да — через Compose Multiplatform, который стабилен на Android, iOS и desktop; web всё ещё в бете. На iOS он рисует собственные пиксели через рендеринг семейства Skia, а не использует UI-компоненты Apple — та же архитектура, что у Flutter, поэтому команде, выбирающей CMP для нового приложения, стоит сравнивать его с Flutter напрямую. Размен такой: знакомый Kotlin и переиспользование навыков Jetpack Compose с Android — против десятилетия экосистемы, тулинга и продакшн-закалки Flutter ровно на этом подходе к рендерингу.
Почти наверняка KMP — и Flutter-агентство, утверждающее обратное, продаёт, а не советует. Ваш Kotlin-код, навыки команды и существующая архитектура переносятся напрямую: выделяйте общие модули постепенно, добавьте iOS-приложение, переиспользующее логику, и держите каждый шаг обратимым. Flutter означал бы переписывание работающего кода и переобучение работающей команды — цена, которая окупается, только если вам к тому же нужно то, что уникально предлагает Flutter: например, одна собственная дизайн-система на всех платформах или полный уход от платформенных команд.
Для большинства новых продуктов в 2026 году Flutter остаётся более безопасной версией той же ставки. Оба рисуют собственный UI на каждой платформе; Flutter обкатывает эту архитектуру в продакшне с 2018 года — с экосистемой пакетов, devtools и пулом найма в качестве доказательств, — а CMP достиг стабильности на iOS в 2025-м и эту глубину ещё набирает. Аргумент за CMP против Flutter — организационный, и он реален: сильная Kotlin-команда, ежедневно пишущая Jetpack Compose, сохраняет свой язык, IDE и мышечную память. Взвешивайте непрерывность команды против зрелости экосистемы — вот в чём настоящее решение.
В продакшне — нет, и мы говорим это прямо, а не блефуем: наши выпущенные работы — Flutter, плюс нативная и бэкенд-инженерия вокруг него. Мы серьёзно оценивали KMP — в том числе для клиентов, чья ситуация указывала в его сторону, — и когда оценка говорит, что ваш ответ — KMP, мы сообщаем это и помогаем определить, что выносить в общий код первым, потому что честное «нет» строит больше доверия, чем натянутое «да». Если хотите, чтобы это сравнение прогнали по вашему конкретному продукту и команде, — именно для такого разговора и существует наш discovery-звонок.

Выбираете между Flutter и KMP для реального продукта? Забронируйте 30-минутный звонок — мы дадим честную рекомендацию, включая вариант «используйте KMP, и мы вам для этого не нужны».