KMP с Compose Multiplatform или Flutter — что выбрать под новый продукт в 2026?

[icu2]

Ещё момент по сопровождению: KMP без CMP (только общая бизнес-логика + нативный UI) — это реально рабочая схема и её используют большие компании. Shared ViewModel, репозитории, сетевой слой на Ktor, сериализация — это работает стабильно уже несколько лет. А UI пишешь нативно: SwiftUI на iOS, Compose на Android. Получается больше кода, но меньше сюрпризов. CMP берут если команда маленькая и на iOS-дизайнера нет бюджета.

[agama1]

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

[burneddeadlock]

@lunarod, про expect/actual для системных вещей — справедливо, но за последний год стало ощутимо легче: пермишены закрывает moko-permissions, выбор фото и камеру — peekaboo, и список таких библиотек растёт быстро. Своими руками у нас остались только нотификации с deep link и биометрия. Так что объём нативного Swift-кода в типовом приложении уже не «половина платформенного слоя», а пара тонких прослоек.

[nixos_andy]

@regexninja, по Shorebird одно предостережение: пуш мимо ревью легален, пока патчишь только Dart-код и не меняешь поведение приложения заметным образом — формально это та же оговорка про интерпретируемый код в правилах Apple. Видел команду, которой прилетел реджект пост-фактум за то, что через патч раскатили фичу, отклонённую на ревью. Для хотфиксов — отличный инструмент, для обхода ревью — мина.