Выбор технологии для мобильного приложения часто воспринимается как техническое решение. Однако на самом деле это бизнес-решение, которое определяет стоимость разработки продукта на многие годы вперед. Алексей Артамонов, директор Nord Clan, рассказывает, какие вопросы следует задать перед началом проектирования и как избежать переделок, которые обойдутся дороже первоначальной разработки.
Технология – это результат, а не отправная точка
Заказчики часто приходят с уже определенным решением по технологии – будь то Flutter, KMP или нативная разработка. Обычно за этим выбором стоит вопрос стоимости разработки или сроков запуска. Это вполне логично: первая версия приложения должна быть готова быстро и не превышать бюджет.
Проблемы возникают позже. Стоимость разработки первой версии – это лишь малая часть расходов на протяжении жизненного цикла приложения. Спустя год начинают возникать новые требования, интеграции и изменения в бизнес-логике. В этот момент становится очевидно, что архитектура, выбранная для экономии на старте, замедляет развитие продукта или требует переработки.
Поэтому выбор технологии стоит рассматривать как выбор модели развития продукта на несколько лет вперед. Вопросы, которые помогут сделать осознанный выбор, касаются не технологий, а самого продукта: насколько различаются сценарии для iOS и Android, как часто будет меняться бизнес-логика, какие возможности устройств планируется использовать и кто будет поддерживать приложение через три года. Ответы на эти вопросы помогут исключить некоторые технологии еще до начала проектирования.
Где проходит настоящая граница между
Flutter и KMP зачастую сравниваются как конкурирующие технологии. На практике они решают разные задачи, и выбор между ними зависит от того, где находится основная сложность продукта и что для бизнеса важнее: скорость и единый интерфейс или нативный пользовательский опыт.
Flutter обеспечивает единый пользовательский интерфейс для iOS и Android, а также единую кодовую базу для большинства сценариев. Когда для бизнеса важны синхронные релизы на обеих платформах, единая команда разработки и предсказуемая скорость развития, Flutter часто оказывается предпочтительным выбором. Он также эффективно работает не только в быстрых MVP, но и в зрелых продуктах – при условии, что архитектура изначально учитывает будущие интеграции и платформенные особенности. Важно отметить, что Flutter выигрывает там, где консистентность UI важнее нативного опыта и команда готова стандартизироваться на Dart. Kotlin Multiplatform функционирует иначе: бизнес-логика пишется один раз и переиспользуется на iOS и Android, в то время как интерфейсы остаются нативными для каждой платформы.
Kotlin Multiplatform хорошо справляется с ситуациями, где продукт содержит значительный объем общей логики – расчеты, интеграции с корпоративными системами, работа с данными. При этом команда сохраняет нативный пользовательский опыт и возможности платформы без ограничений. KMP выигрывает, когда нативный UX не является предметом обсуждения, а объем общей логики увеличивается.
Также стоит упомянуть Compose Multiplatform: KMP уже не сводится к формуле «общая логика + нативный UI». CMP для iOS стабилен с 2025 года, и при желании можно делиться и UI-слоем тоже. Это не отменяет логику выбора – нативный UX все еще является аргументом в пользу классического KMP-метода, – но важно понимать, что граница между «делимся только логикой» и «делимся всем» стала более подвижной.
Например, для центра банкротств мы выбрали Flutter: основная задача заключалась в быстром тестировании гипотезы на рынке, требовался единый интерфейс и быстрые итерации. В проекте мобильного приложения для HR-маркетплейса ситуация была иной: продукт с самого начала подразумевал множество бизнес-сценариев и интеграций. В этом случае KMP с общей бизнес-логикой и нативными интерфейсами оказался более логичным выбором.
Где экономия на старте оборачивается расходами
Частая ошибка – выбирать технологию исключительно на основе принципа минимальных затрат. Сначала это кажется разумным: кроссплатформенная разработка действительно позволяет сократить затраты и быстрее вывести продукт на рынок.
Сложности начинаются, когда архитектура не проверена на предмет будущих интеграций, особенностей платформ и увеличения нагрузки. Через год появляются сложные интеграции, новые требования к производительности, различия в сценариях использования на iOS и Android. Архитектура начинает усложняться, а первоначальная экономия постепенно уходит в прошлое.
На практике это выглядит так: компания сэкономила несколько месяцев разработки на запуске, но через полтора-два года вынуждена инвестировать в серьезную переработку архитектуры. Добавление новых функций требует все больше времени, а изменения нужно вносить сразу в несколько частей системы.
Ориентировочно можно удерживать в голове такие цифры: KMP на старте обычно требует больше ресурсов – около трех разработчиков против 2,5 у Flutter, – но выигрывает в долгосрочной перспективе за счет отсутствия «великой миграции» через полтора-два года. Именно на этой дистанции становится заметна разница между «сэкономили на запуске» и «сэкономили на жизненном цикле». Чтобы этого избежать, стоимость разработки приложения стоит оценивать не на этапе запуска, а на горизонте трех-пяти лет.
Два вопроса и один контекст, которые помогают принять решение
В 2026 году нельзя игнорировать еще одну переменную: рост экосистемы HarmonyOS. Для Flutter официальной поддержки этой платформы нет – это создает риск для продуктов, ориентирующихся на китайский рынок или корпоративные устройства под управлением HarmonyOS. KMP в этом контексте выглядит более устойчивым: общая логика переходит, а интерфейс пишется нативно для нужной платформы. Если у продукта есть или может появиться «китайское» или «около-китайское» измерение, этот фактор следует учитывать на этапе выбора технологий, а не позже.
Большинство сравнений Flutter и KMP начинаются с технических характеристик. Выбор технологии на основе таких сравнений неэффективен – они не отвечают на главный вопрос бизнеса: как выбранное решение повлияет на стоимость развития продукта через несколько лет. Два вопроса помогут найти ответ.
Первый: насколько бизнес-логика на iOS и Android совпадет через два-три года? Чем больше общей логики в продукте, тем заметнее эффект от ее переиспользования – и тем сильнее аргумент в пользу KMP.
Второй вопрос: насколько критично для продукта сохранить нативный пользовательский опыт и доступ ко всем возможностям платформы?
Если продукт активно использует особенности платформы или требования к интерфейсу различаются между iOS и Android, преимущество оказывается на стороне KMP. Если же приоритетом является консистентность UI и единый интерфейс, а нативный UX не является критическим требованием, стоит обратить внимание на Flutter. Правильнее будет сформулировать так: Flutter выигрывает не за счет «быстрого развития обеих платформ» – общая логика в KMP также ускоряет развитие – а благодаря тому, что весь UI-слой пишется один раз и выглядит идентично на всех платформах.
Вопрос не в том, какая технология лучше сама по себе – Flutter или KMP. Правильный выбор определяется тем, каким продукт должен стать через несколько лет: как будет расти его бизнес-логика, насколько важны особенности платформ и как часто потребуется развивать приложение. Если оценить эти факторы до начала разработки, технология станет не способом сэкономить на запуске, а инструментом, позволяющим развивать продукт без дорогостоящей переработки архитектуры через год или два.
Виджет на iOS: почему чужой успех – плохой ориентир для продукта
