Kotlin Multiplatform или Flutter — что реально работает для кросс-платформы

[cohenst1]

Задача: приложение для iOS и Android, команда из двух разработчиков (один Android/Kotlin, один веб). Рассматриваем KMP и Flutter. KMP привлекает тем, что Android-разработчик уже знает Kotlin, Flutter — тем, что один кодовый UI на обе платформы. Но реально — у кого есть опыт в продакшене? Какие подводные камни?

[depechie]

KMP и Flutter решают принципиально разные задачи, и тут важно понять что именно вы хотите шарить. KMP отлично шарит бизнес-логику: сеть, БД, доменный слой — пишешь один раз на Kotlin, используешь на Android нативно и на iOS через фреймворк. UI при этом остаётся нативным на каждой платформе. Flutter шарит всё включая UI, но рисует свой рендер поверх платформы через Skia/Impeller.

[k8s2000]

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

[cordoba]

Flutter выбрал бы если UI-парити между платформами критичен и важна скорость выпуска. Мы запустили приложение за 4 месяца силами двух разработчиков, один из которых знал только React. Порог входа реально низкий. Минусы: размер приложения больше (минимум ~10 МБ), иногда встречаются проблемы с нативными плагинами, и на iOS периодически замечаешь что что-то выглядит чуть не так. Но для 90% бизнес-задач этого не замечает никто кроме дизайнера.

[Austkin]

Важный практический момент по KMP: Compose Multiplatform (это UI-часть от JetBrains) уже в стабильном релизе для iOS, так что теперь можно шарить и UI через Compose если хочется. Получается конкурент Flutter внутри Kotlin-экосистемы. Я пробовал в пет-проекте — работает, хотя iOS-часть ещё чуть менее зрелая чем Android.

[tolkien]

Для вашей конкретной ситуации — два разработчика, один Kotlin-девелопер — я бы взял KMP с Compose Multiplatform. Android-разработчик сразу в своей стихии, веб-разработчик освоит Compose относительно быстро (декларативный UI, похоже на React концептуально). Flutter тоже вариант, но тогда оба будут учить Dart с нуля, а это время.

[Shonroman]

Один аспект, который при выборе все пропускают: кто бы что ни выбрал, iOS-сторона потребует человека, который не боится Xcode. Подписи, provisioning profiles, ревью в App Store, крэши, которые видны только в TestFlight — это одинаковая боль и в KMP, и во Flutter, фреймворк от неё не спасает. Я бы на месте автора потратил неделю и собрал один и тот же экран с сетевым запросом на обоих стеках силами своей же пары разработчиков. После такого спайка решение обычно принимается само, и стоит это дешевле, чем три месяца на неверной лошади.

[FpgaDev]

@Austkin, по Compose Multiplatform на iOS уточню из своего опыта: стабильный релиз — да, и скролл уже почти неотличим от нативного, но текстовый ввод пока слабое место. Автокоррекция, выделение текста, поведение клавиатуры в длинных формах — местами заметно, что это не UITextField. Если приложение у автора с большим количеством форм, я бы именно эту часть прогнал в прототипе первой. Для контентных экранов претензий нет вообще.

[cohenst1]

@cordoba, про размер в 10 МБ — в 2026 это уже несерьёзный минус, никто не заметит. А вот твой пункт про нативные плагины я бы усилил: это главный риск Flutter для маленькой команды. Когда нужный плагин забрасывают, ты внезапно пишешь platform channels сам — и сразу на Swift и на Kotlin, то есть кросс-платформа на этом участке схлопывается в двойную нативную разработку. Перед стартом стоит пройтись по списку нужных интеграций (платежи, пуши, камера, биометрия) и проверить, что у каждой есть живой maintained-плагин.