Flutter или Kotlin Multiplatform: как выбрать стек и не платить дважды

Flutter подходит большинству бизнес-приложений с одинаковым интерфейсом на iOS и Android: MVP собирается быстрее, поддержка обходится дешевле, а один разработчик закрывает обе платформы. Kotlin Multiplatform выигрывает, когда логика сложная — расчёты, синхронизация с 1С, работа с оборудованием, — а интерфейс на каждой платформе должен вести себя как нативный. Выбор стека определяет не мода, а то, что дороже переписывать: экран или логику.

Что на самом деле разделяют эти две технологии

Flutter и Kotlin Multiplatform (KMP) решают разные задачи, хотя обе позволяют не писать приложение дважды. Flutter — это движок, который сам рисует интерфейс поверх Android и iOS: кнопки, анимации, переходы нарисованы одним кодом на Dart и выглядят одинаково на обеих платформах. Экран заказа в приложении для доставки будет пиксель в пиксель одинаковым что на iPhone, что на бюджетном Android.

Kotlin Multiplatform устроен наоборот: общий код отвечает только за то, что не видно пользователю — запросы к серверу, кеш, бизнес-правила, работу с 1С через API. Экран заказа на iOS собирается на SwiftUI, на Android — на Jetpack Compose, каждый нативными средствами платформы. Общая логика экономит время, а интерфейс остаётся «родным» для каждой ОС — со своими жестами, анимациями системных элементов и поведением клавиатуры.

Разница видна и в том, как приложение реагирует на обновления самой операционной системы. Когда Apple или Google меняют системный стиль переключателей, шрифтов или жестов, KMP-приложение получает это бесплатно вместе с обновлением нативных библиотек. Flutter-приложение получит новый вид элемента только тогда, когда команда Flutter обновит собственный набор виджетов и разработчик подтянет эту версию в проект — обычно с задержкой в один-два релизных цикла.

Есть и вопрос найма. Под Flutter ищут одного разработчика, который закрывает обе платформы — таких специалистов на рынке Москвы достаточно, и стоимость их часа сопоставима с обычным mobile-разработчиком. Под Kotlin Multiplatform нужна связка: Kotlin-разработчик для общей логики и Android-экрана плюс отдельный iOS-разработчик на Swift — то есть с самого начала два человека и два процесса код-ревью вместо одного.

Сроки, команда и деньги: сравнение по цифрам

Разница ощущается уже на старте проекта — в размере команды и в том, что попадает в первую сборку.

После запуска разница в стоимости поддержки сохраняется: баг в общей логике Flutter чинится один раз и уходит сразу на обе платформы, а в KMP-проекте баг в интерфейсе правится там, где он живёт — на Android или на iOS, зато не задевает вторую платформу вообще и не требует общего релиза.

Разработка мобильного приложения у нас начинается от 500 000 рублей — и на Flutter, и на Kotlin Multiplatform в эту вилку укладываются разные объёмы работ. Для Flutter это чаще полноценное приложение с готовыми экранами на обеих платформах сразу. Для KMP та же сумма закрывает общую логику плюс интерфейс одной платформы — вторую платформу собирают следующим этапом, когда первая уже приносит заявки и понятно, какие экраны реально нужны пользователю.

Что почувствует пользователь: производительность и первое впечатление

Для типового бизнес-каталога на 200-300 позиций разница в скорости прокрутки между Flutter и нативным списком на глаз не заметна — движок Flutter (Impeller) справляется со списками и анимациями карточек без подтормаживаний. Разница становится ощутимой в узких местах: тяжёлые карты с геометками курьеров, видеопоток с камеры, сложные жесты как в редакторах — там нативный код Kotlin Multiplatform ближе к системным API и меньше просаживает батарею и память.

Холодный старт приложения тоже отличается: Flutter поднимает свой движок отрисовки при запуске, что добавляет доли секунды к первому экрану на слабых Android-устройствах. Для приложения заказа такси или доставки это неощутимо, для кассового приложения на складе, где сотрудник открывает его по сто раз за смену, разница накапливается за день.

Когда бизнесу хватит Flutter

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

Отдельный плюс для бизнеса, у которого приложение — надстройка над 1С: Flutter-приложение забирает данные через тот же API, что и интеграция мобильного приложения с 1С, и не требует дублирования логики на две нативные команды. Если задача — B2B-каталог или личный кабинет партнёра с заказами из 1С, похожее решение описано на странице про B2B-приложение с 1С.

Когда даже Flutter избыточен

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

Когда стоит присмотреться к Kotlin Multiplatform

KMP оправдан, когда у бизнеса уже есть нативное приложение на одной платформе и жалко его переписывать. Например, iOS-приложение сервиса доставки или карты лояльности работает годами, накопило рейтинг в App Store и привычки пользователей, а Android-версию нужно добавить без риска для существующей логики оплат. Общий модуль на Kotlin переносит расчёты и работу с API, а экраны на Android пишутся нативно поверх него, не трогая то, что уже работает на iOS.

Второй случай — оборудование. Сканер штрихкодов, POS-терминал, NFC-считыватель на складе или кассе часто требуют SDK, который официально поддерживает только нативную разработку под конкретную ОС. Городить это через мост Flutter можно, но каждое обновление SDK производителя рискует сломать мост, а не саму интеграцию — и чинить приходится на стороне обёртки, а не оборудования, что превращается в повторяющуюся статью расходов на поддержку.

Ошибка, которая обходится дороже самого приложения

Розничная сеть в Москве заказала Flutter-приложение для оптовых заказчиков: каталог, корзина, история отгрузок из 1С. Разработка шла быстро, первая версия вышла за месяц с небольшим, отдел продаж начал принимать заказы прямо с телефона у клиента. Но через полгода отдел логистики попросил добавить сканирование штрихкодов на складе через промышленный терминал с собственным SDK — и выяснилось, что производитель терминала поддерживает только нативный Android.

Команда написала platform channel — мост между Dart и нативным Kotlin-кодом терминала. Мост работал, пока производитель не выпустил обновление прошивки: интерфейс SDK изменился, мост перестал собираться, а исправление легло не на бюджет интеграции оборудования, а на бюджет самого приложения — заново тестировать пришлось весь мост целиком, а не только новую функцию.

Ставка здесь не в деньгах на переписывание одного модуля — она в остановленном складе на время, пока сканер не заработает, и в объяснении заказчику, почему обновление прошивки стороннего устройства вообще ломает мобильное приложение. Дешевле было на этапе выбора стека задать один вопрос: планируется ли специфичное оборудование хотя бы на горизонте года. Ответ «да» — повод сразу обсуждать нативный модуль или Kotlin Multiplatform для этой части, а не тянуть мост до первого сбоя прошивки.

Как определить стек до старта разработки

Три вопроса на первой встрече с разработчиком снимают большую часть риска выбора.

• ✓Сколько экранов повторяются один в один на iOS и Android — если почти все, Flutter быстрее окупается
• ✓Есть ли уже нативное приложение на одной платформе, которое жалко переписывать — тогда смотреть в сторону Kotlin Multiplatform
• ✓Планируется ли специфичное оборудование или SDK с ограниченной кроссплатформенной поддержкой — фиксировать это в техзадании до начала работы, а не после первого релиза

Что взять с собой на первую встречу

Список экранов будущего приложения, ссылки на существующие нативные версии, если они есть, и модель оборудования, если склад или касса уже работают с конкретным терминалом или сканером. С этим набором разговор о стеке занимает один созвон, а не три итерации переписки.

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

❓ Частые вопросы

Flutter или Kotlin Multiplatform — что дешевле для бизнеса?

На старте Flutter обычно дешевле: один разработчик закрывает обе платформы, а MVP собирается быстрее. Kotlin Multiplatform требует минимум двух специалистов — под Android и под iOS, потому что интерфейс каждой платформы пишется отдельно поверх общей логики.

Подойдёт ли Flutter для приложения, которое работает с 1С?

Да. Flutter-приложение обращается к 1С через тот же API, что и нативные решения, — забирает остатки, заказы, статусы отгрузок. Дублировать логику под каждую платформу не нужно, весь обмен с 1С описан один раз в общем коде.

Можно ли начать на Flutter, а потом перейти на Kotlin Multiplatform?

Технически да, но это фактически новая разработка интерфейса под обе платформы: общий UI-код Flutter не переносится в нативный Kotlin или SwiftUI. Дешевле сразу оценить, понадобится ли специфичное оборудование, и выбрать стек с учётом этого.

Сколько стоит мобильное приложение с интеграцией 1С для среднего бизнеса?

Разработка начинается от 500 000 рублей — сумма зависит от числа экранов, глубины интеграции с 1С и того, нужна ли работа с оборудованием на складе или в точке продаж. Точный расчёт делаем после разбора задач бизнеса.

Что делать, если на складе уже стоит терминал сбора данных со своим SDK?

Сообщить об этом на этапе выбора стека, а не после релиза. Для оборудования с ограниченной кроссплатформенной поддержкой разумнее нативный модуль или Kotlin Multiplatform — это исключает риск поломки моста после обновления прошивки терминала.