Kotlin Multiplatform vs Flutter: чем отличаются и что выбрать

Что такое Kotlin Multiplatform

Kotlin Multiplatform (сокращённо KMP) — это технология от компании JetBrains, которая позволяет разрабатывать приложения для разных платформ с использованием языка программирования Kotlin.

Если говорить простыми словами, KMP даёт возможность писать код один раз, а использовать его на iOS, Android, веб‑приложениях и даже десктопных программах. Звучит как магия? На самом деле это просто умный подход к организации кода.

Важно понимать: KMP — не готовый фреймворк “из коробки”, который сразу рисует интерфейс на всех платформах. Это скорее инструмент, который позволяет переиспользовать бизнес‑логику между платформами. То есть всю логику работы приложения: запросы к серверу, обработку данных, работу с базой данных. Всё это можно написать один раз на Kotlin, а потом использовать и на iOS, и на Android.

Kotlin Multiplatform не является “заменой” нативной разработки, это её расширение. Вы не отказываетесь от Swift или Kotlin для Android, а просто выносите общую логику в отдельный слой, который работает на обеих платформах.

Как работают с KMP

Теперь, когда понятно, что такое KMP в общих чертах, можно поговорить о том, как на нём разрабатывают приложения. И тут есть два принципиально разных подхода: Shared UI и Native UI. Выбор подхода кардинально влияет на процесс разработки, скорость и результат.

Shared UI (как Flutter)

Подход Shared UI подразумевает, что интерфейс приложения становится общим для всех платформ. То есть вы пишете код интерфейса один раз, и он работает и на iOS, и на Android. По сути, это похоже на то, как разрабатывают приложения на Flutter: один код интерфейса на все платформы.

Для реализации Shared UI в экосистеме KMP используется фреймворк Compose Multiplatform. Это расширение Jetpack Compose (инструмента для создания интерфейсов на Android), которое работает не только на Android, но и на iOS, Desktop и Web.

С технической точки зрения Compose Multiplatform использует графический движок Skia для рендеринга интерфейса, а это точно такой же движок, как и во Flutter. То есть подход очень похож: один код интерфейса, единый движок отрисовки на всех платформах.

Звучит заманчиво, правда? Но у этого подхода есть свои подводные камни, о которых поговорим чуть позже.

Native UI

А вот здесь начинается совсем другая история. При подходе Native UI интерфейс для каждой платформы разрабатывается отдельно, на нативных инструментах:

Для iOS используется SwiftUI (с интеграцией UIKit, если не хватает SwiftUI) в Xcode. Для Android используется Jetpack Compose (с редкой интеграцией XML по необходимости) в Android Studio. То есть разработчик создаёт два полностью независимых интерфейса. iOS‑приложение выглядит и ведёт себя как полноценное iOS‑приложение, потому что оно таковым и является. То же самое — с Android.

А что же тогда общего? Общей остаётся бизнес‑логика, которая выносится в отдельный shared‑модуль, написанный на Kotlin. Этот модуль содержит всю логику работы приложения: работу с API, обработку данных, валидацию, работу с базой данных и так далее.

Для Android этот shared‑модуль подключается как обычная Kotlin‑библиотека — никаких проблем, всё на одном языке. А вот для iOS происходит небольшая магия: shared‑модуль транспилируется (переписывается) в Objective‑C фреймворк, который затем импортируется в Swift‑проект. Разработчику не нужно писать Objective‑C код самому, Kotlin‑код автоматически преобразуется в совместимую библиотеку.

Важно отметить: shared‑слой (общая логика) присутствует в обоих подходах — в Shared UI и в Native UI. Разница только в том, где проходит граница между общим и платформенным кодом. В Shared UI общим становится почти всё, включая интерфейс. В Native UI общей остаётся только бизнес‑логика, а интерфейс полностью нативный.

Плюсы KMP

Теперь, когда разобрались с подходами к разработке, можно честно поговорить о плюсах Kotlin Multiplatform. Важно понимать, что плюсы будут отличаться в зависимости от выбранного подхода: Shared UI или Native UI.

1. Нативная разработка и единая бизнес-логика (Native UI)

Это, пожалуй, главное преимущество подхода Native UI в KMP: вы получаете все преимущества нативной разработки — полный доступ к API платформы, нативные компоненты интерфейса, максимальную производительность, но при этом не дублируете бизнес‑логику. Вся логика работы приложения написана один раз на Kotlin и используется на обеих платформах.

Это особенно ценно для сложных приложений, где важна производительность и нативное “ощущение” интерфейса. Пользователи iOS получают приложение, которое выглядит и работает как настоящее iOS‑приложение. Пользователи Android получают такое же нативное Android‑приложение. Никаких компромиссов с интерфейсом.

2. Максимальный контроль над приложением (Native UI)

Когда интерфейс разрабатывается нативными инструментами, у программиста есть доступ абсолютно ко всем возможностям платформы. Нужна какая‑то специфическая анимация iOS? Пожалуйста, используйте SwiftUI. Нужен Material Design 3 со всеми новыми компонентами на Android? Jetpack Compose к вашим услугам.

Вы не зависите от того, успела ли команда Flutter (или JetBrains для Compose Multiplatform) добавить поддержку новой фичи платформы. Вышла новая версия iOS с новыми API? Вы можете использовать их сразу, не дожидаясь обновления кроссплатформенного фреймворка.

3. Высокая скорость разработки (Shared UI)

А вот здесь плюсы подхода Shared UI выходят на первый план. Когда интерфейс пишется один раз через Compose Multiplatform, скорость разработки значительно возрастает. Вы создаете экран один раз и он сразу работает и на iOS, и на Android.

Огромный плюс если надо быстро. Если надо было еще “вчера”.

4. Единая кодовая база для бизнес-логики

Этот плюс справедлив для обоих подходов. Вся логика приложения: работа с API, обработка данных, валидация форм, работа с локальной базой данных, все это написано один раз. Это означает:

• Меньше кода для поддержки;
• Баги исправляются один раз, а не дважды;
• Новые фичи в бизнес-логике добавляются один раз;
• Проще тестировать.

5. Kotlin как основной язык

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

Минусы KMP

А теперь о минусах. И снова, и они тоже отличаются в зависимости от подхода.

1. Проблемы с рендерингом и нативным "ощущением" (Shared UI)

Это главная боль подхода Shared UI через Compose Multiplatform. Хотя технически интерфейс работает на обеих платформах, он может выглядеть “не так” на iOS. Причина проста: iOS и Android имеют совершенно разные дизайн‑гайдлайны и паттерны взаимодействия.

Элементы интерфейса, которые привычны для Android‑пользователей, могут выглядеть чужеродно на iOS — и наоборот. Да, можно адаптировать интерфейс под каждую платформу с помощью условий в коде, но тогда пропадает смысл “одного интерфейса на все платформы”: код разрастается и усложняется.

Кроме того, не всегда получается добиться идеальной отрисовки элементов. Skia рисует элементы сам, а не использует нативные компоненты платформы. Это может приводить к небольшим визуальным расхождениям — особенно заметным на iOS, где пользователи привыкли к определённому “ощущению” интерфейса.

2. Сложная настройка окружения

Это проблема вообще любой кроссплатформенной разработки, и KMP не исключение. Чтобы начать разрабатывать на KMP, нужно:

• Купить ПК с MacOS;
• Установить Android Studio;
• Установить Xcode;
• Установить CocoaPods;
• Настроить эмуляторы iPhone и Android.

Для опытных разработчиков это не проблема, но новичку может быть непросто. Особенно если сравнивать с той же нативной разработкой, где для iOS достаточно только Xcode, а для Android только Android Studio.

3. Высокий порог входа (Native UI)

Если Вы выбираете подход Native UI, то Вам придется знать как минимум: Swift и SwiftUI, Kotlin и Jetpack Compose. Это означает, что в команде должны быть разработчики с опытом на обеих платформах. Или один разработчик должен владеть всем стеком, а это встречается редко.

4. Экосистема еще развивается

Kotlin Multiplatform активно развивается и это относительно молодая технология. Это означает: документация иногда отстает от реальности, сообщество меньше, чем у Flutter. 

Что такое Flutter

Flutter — это UI-фреймворк от компании Google для создания кроссплатформенных приложений. С его помощью можно разрабатывать приложения для iOS, Android, Web, Desktop (Windows, macOS, Linux) и даже встраиваемых систем, используя один язык программирования Dart.

Если говорить простыми словами: Flutter позволяет написать приложение один раз и запустить его на всех платформах. Причем "один раз" здесь означает именно весь код: интерфейс и бизнес-логику. Тут нет дополнительных опций как в KMP, это более простой как палка инструмент (и это не плохо).

Главное отличие Flutter от многих других кроссплатформенных решений (типа React Native, Cordova) — это собственный движок рендеринга. Flutter не использует заранее заготовленные нативные компоненты платформы (как это делает React Native), а рисует интерфейс сам, используя графическую библиотеку Skia. Это дает Flutter полный контроль над каждым пикселем на экране и гарантирует, что приложение будет выглядеть одинаково на всех платформах. 

Как работают с Flutter

Разработка на Flutter принципиально отличается от подхода Native UI в KMP и очень похожа на подход Shared UI через Compose Multiplatform (с тем же KMP).

Весь код приложения: интерфейс, бизнес-логика, все это пишется на языке Dart. Один язык, одна кодовая база, один проект. 

Как это выглядит на практике

Вы создаете виджеты (widgets): это строительные блоки интерфейса во Flutter. Виджеты описывают, как должен выглядеть элемент интерфейса. Например, кнопка, текстовое поле, список. Из виджетов собирается весь интерфейс приложения.

Flutter предоставляет два набора виджетов: Material Design — виджеты в стиле Android и Cupertino — виджеты в стиле iOS. Это позволяет адаптировать интерфейс под платформу: на Android использовать Material-виджеты, на iOS — Cupertino. Но это слишком заморочено, в сравнении с KMP (Native UI) выглядит костыльно, поэтому так делают редко. Обычно сразу программируют единый стиль на всех платформах.

Вся бизнес-логика тоже пишется на Dart. Работа с API, базой данных, валидация, навигация — все это на одном языке (и в одном месте). Не нужно переключаться между Swift и Kotlin, как в случае с KMP Native UI.

Если нужен доступ к нативным API платформы (например, к специфическим функциям iOS или Android), Flutter предоставляет механизм Platform Channels. Через него можно вызвать нативный код на Swift/Kotlin из Dart. Это требует дополнительной работы, но дает доступ к многим возможностям платформы (ограничения есть, но каждый кейс надо рассматривать отдельно, в общих чертах проблем нет).

Плюсы Flutter

1. Высокая скорость разработки

Это главное преимущество Flutter, на которое пытаются указать все кому не лень. Один язык, одна кодовая база, один проект для всех платформ.

Для MVP, стартапов, проектов с ограниченным бюджетом Flutter это хорошее решение. Скорость разработки здесь выше, чем у нативной разработки, чем у KMP с Native UI. Но KMP с Shared UI показывает такую же скорость.

2. Огромная экосистема и сообщество

Flutter существует с 2017 года и за это время собрал огромное сообщество. На pub.dev (репозиторий пакетов для Flutter) десятки тысяч готовых решений: библиотеки для работы с API, базами данных, аналитикой, платежами, картами. Тут есть что угодно.

3. Один язык для всего 

Dart — современный язык, не сложный, особенно если есть опыт с JavaScript, Java или Kotlin. Программисту не нужно знать Swift и Kotlin одновременно, как в случае с KMP Native UI.

4. Идентичный интерфейс на всех платформах

Flutter рисует интерфейс сам через Skia, поэтому приложение выглядит абсолютно одинаково на iOS и Android. Это одновременно плюс и минус (об этом ниже), но для многих проектов это именно плюс.

Минусы Flutter

1. Не нативное "ощущение" интерфейса

Это главная претензия к Flutter, особенно со стороны iOS-пользователей. Поскольку Flutter рисует интерфейс сам через Skia, а не использует системные компоненты, приложение может ощущаться "не совсем нативным". Такая же проблема будет и у KMP с его Shared UI подходом.

Анимации, скроллинг, поведение элементов, все это эмулируется Flutter. На Android это менее заметно, а вот на iOS пользователи привыкли к очень конкретному "ощущению" интерфейса. И Flutter-приложения часто это ощущение не передают.

Автор статьи, как пользователь iPhone, ненавидит из-за этого все кроссплатформенные приложения.

2. Размер приложения

Flutter-приложения весят больше нативных. Потому что в сборку включается весь движок Skia и runtime Dart. Минимальный размер простейшего Flutter-приложения около 4-5 МБ. Для нативного или KMP Native UI приложения это может быть меньше мегабайта.

Да, для современных смартфонов с сотнями гигабайт памяти это не проблема. Но для некоторых рынков (например, развивающиеся страны с медленным интернетом) размер приложения имеет значение.

3. Проблемы с доступом к новым API платформ

Когда Apple выпускает новую версию iOS с новыми API, Flutter не может использовать их сразу. Нужно ждать, пока команда Flutter (или сообщество) добавит поддержку через пакеты или Platform Channels. Это означает, что Flutter всегда немного отстает от нативной разработки.

4. Проблемы с accessibility

Accessibility (доступность) - это когда приложение подстраивает размер шрифта под пользователя, помогает с голосовым вводом и так далее.

Поскольку Flutter не использует нативные компоненты, а рисует элементы сам, иногда возникают сложности с поддержкой специальных возможностей. VoiceOver на iOS, TalkBack на Android — эти системы рассчитаны на нативные компоненты.

Flutter эмулирует поддержку accessibility, но это не всегда работает идеально (еще не видели идеального примера на момент 2025 года). Для приложений, где accessibility критично, это может быть проблемой.

5. Dart как язык

Это одновременно плюс и минус. Dart — хороший язык, но… блин, много кому он нужен то? Dart используется только во Flutter, учить его только для Flutter? А если Google опять похоронит свой “любимый” проект, как они это делали десятки раз? Это как Битрикс, учишь кучу материалов по нему, но в другим местах просто не применимо.

Тот же Kotlin используется не только в KMP, но и в нативной Android-разработке, бэкенде (Ktor, Spring), и даже веб-разработке (но это для совсем “особых” программистов).

6. Производительность в сложных сценариях

Для большинства приложений производительность Flutter более чем достаточна. Но в сложных сценариях: тяжелые анимации, обработка больших объемов данных, работа с камерой в реальном времени — нативные приложения работают быстрее.

Flutter добавляет слой абстракции между кодом и платформой. Этот слой имеет свою цену в производительности.

Итог

Теперь, когда разобрали оба инструмента, можно подвести честный итог.

Flutter и KMP Shared UI — это почти одно и то же

По сути, между Flutter и подходом Shared UI в Kotlin Multiplatform разницы почти нет. Оба используют Skia для рендеринга, оба дают высокую скорость разработки, оба страдают от одних и тех же проблем:

• Не совсем нативное "ощущение" интерфейса, особенно на iOS;
• Увеличенный размер приложения;
• Задержки с доступом к новым API платформ;
• Проблемы с accessibility.

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

KMP Native UI — дорого, но нет ограничений

А вот подход Native UI в Kotlin Multiplatform это совсем другая история. Здесь нет компромиссов с интерфейсом, нет проблем с "нативным ощущением", нет задержек с новыми API. Вы получаете полноценные нативные приложения на Swift и Kotlin, просто с общей бизнес-логикой. Но за это приходится платить временем на разработку.

P.S: Хотя это все равно дешевле чем чистый натив.