«Нам нужно приложение под iOS и Android» — и почти сразу следом вопрос про Flutter. Логика понятная: одна команда вместо двух, один код вместо двух, экономия вдвое. На практике экономия выходит не вдвое, а на 35–45%, и есть класс задач, где кросс-платформа обойдётся дороже нативной разработки. Разберём по деньгам, срокам, производительности и рискам.
Коротко: как выбрать за минуту
Берите Flutter, если приложение — это интерфейс поверх вашего сервиса: каталог, заказы, личный кабинет, запись, доставка, внутренний инструмент для сотрудников. Это 80% задач бизнеса.
Берите нативную разработку, если приложение упирается в возможности устройства: сложная работа с камерой и компьютерным зрением, обработка видео в реальном времени, серьёзная 3D-графика, глубокая интеграция с системными сервисами, фоновая работа с жёсткими требованиями к энергопотреблению, приложения для носимых устройств.
Деньги
Нативная разработка означает две кодовые базы: Swift для iOS, Kotlin для Android. Это две команды, два цикла разработки, два ревью, два набора багов. Flutter даёт один код и одну команду, но добавляет накладные расходы: часть системных возможностей приходится подключать через платформенные модули, которые пишутся всё равно нативно.
Реальные пропорции на проекте среднего размера (каталог, авторизация, оплата, push, карта, личный кабинет):
| Статья | Нативная (iOS + Android) | Flutter |
|---|---|---|
| Дизайн | 250–400 тыс. ₽ | 250–400 тыс. ₽ |
| Разработка | 2,2–3,5 млн ₽ | 1,3–2 млн ₽ |
| Тестирование | 350–600 тыс. ₽ | 250–450 тыс. ₽ |
| Итого | 2,8–4,5 млн ₽ | 1,8–2,8 млн ₽ |
Разница — те самые 35–45%, а не 50%: дизайн, аналитика, серверная часть и тестирование на реальных устройствах не удешевляются от смены технологии.
Ещё важнее экономика поддержки. Правка в нативном проекте делается дважды и дважды тестируется. За три года эксплуатации разрыв в стоимости владения обычно превышает разницу в стоимости разработки.
Сроки
Одна команда вместо двух — это не только дешевле, но и быстрее на 4–6 недель для среднего проекта, потому что исчезает синхронизация между платформами. Классическая боль нативной разработки: iOS-версия готова, Android отстаёт на три недели, релиз ждёт обе. На Flutter обе платформы едут одним поездом.
Для проверки гипотезы это решающий аргумент. Если задача — быстро выйти на рынок и посмотреть, пользуются ли приложением вообще, кросс-платформа почти безальтернативна. Мы делаем такие запуски в формате MVP за 14 дней: работающая сборка в руках у первых пользователей вместо презентации.
Производительность: где миф, а где правда
Миф: «Flutter тормозит». Обычные интерфейсы — списки, формы, карточки, анимации переходов — работают неотличимо от нативных. Пользователь не определит технологию, глядя на экран заказа.
Правда: разница появляется на тяжёлых сценариях. Постоянная перерисовка сложной графики, обработка видеопотока, десятки тысяч элементов в одном списке с кастомной отрисовкой, серьёзные вычисления на устройстве — здесь нативный код даёт запас, которого у кросс-платформы нет.
Вторая правда: размер сборки у Flutter больше на 8–15 МБ. Для большинства приложений это не имеет значения, но если ваша аудитория — регионы со слабым интернетом и бюджетными устройствами, это аргумент.
Что часто решает спор
Кто будет поддерживать. Найти одного Flutter-разработчика проще и дешевле, чем удерживать двух нативщиков. Если планируете вести разработку своей командой — это весомый довод.
Есть ли уже нативное приложение. Переписывать работающее приложение ради экономии на поддержке имеет смысл далеко не всегда: миграция стоит как новая разработка. Считайте на горизонте трёх лет.
Требования площадок. Обе платформы принимают Flutter-приложения без ограничений — это давно не проблема. А вот специфические возможности вроде виджетов на экране блокировки или расширений для системных приложений пишутся нативно в любом случае.
Планы на носимые устройства. Часы и телевизоры — территория нативной разработки. Если это в планах на год вперёд, закладывайте гибридную схему.
Гибридный вариант, о котором забывают
Выбор не бинарный. Рабочая схема для приложений с одним тяжёлым сценарием: основное приложение на Flutter, а «горячий» модуль — нативный. Так делают приложения с распознаванием документов, где вся оболочка кросс-платформенная, а работа с камерой написана под каждую платформу.
Ещё один вариант для сервисов с простым сценарием — вообще не делать приложение. Telegram Mini App закрывает запись, заказ и личный кабинет без установки, магазинов приложений и модерации, и стоит в разы дешевле. Прежде чем считать смету на мобильное приложение, честно ответьте: пользователь правда установит его и вернётся, или ему нужен доступ в два клика?
Как мы принимаем решение с клиентом
Три вопроса на первом созвоне:
- Какие функции приложения работают с устройством, а не с сервером? Если список пустой — вопрос закрыт, Flutter.
- Какой горизонт планирования? Год — берите то, что быстрее и дешевле запустить. Пять лет с постоянным развитием — считайте стоимость владения.
- Кто будет вести разработку через год? Своя команда, подрядчик, никто. От ответа зависит требование к массовости стека.
Если после этих вопросов остаётся неопределённость, мы предлагаем прототип на Flutter: две-три недели, работающая сборка, реальные замеры производительности на ваших сценариях. Это дешевле, чем спорить о технологиях на бумаге.
Частые вопросы
Что дешевле: Flutter или нативная разработка?
Flutter обходится на 35–45% дешевле при сопоставимой функциональности: одна кодовая база вместо двух. Приложение среднего размера на Flutter стоит 1,8–2,8 млн рублей против 2,8–4,5 млн за нативную пару iOS + Android. Разница в стоимости поддержки за три года обычно ещё больше.
Правда ли, что Flutter работает медленнее нативных приложений?
В обычных интерфейсах — списки, формы, карточки, переходы — разницы не видно. Отставание проявляется на тяжёлой графике, обработке видео в реальном времени и вычислениях на устройстве. Для типового бизнес-приложения производительность Flutter избыточна.
Когда нужна именно нативная разработка?
Когда приложение упирается в возможности устройства: компьютерное зрение, обработка видеопотока, 3D-графика, фоновая работа с жёсткими требованиями к батарее, приложения для часов и телевизоров, глубокая интеграция с системными сервисами. В остальных случаях кросс-платформа закрывает задачу.
Сколько времени занимает разработка мобильного приложения?
Приложение среднего размера на Flutter — 3–4 месяца от старта до публикации, нативная пара — 4,5–6 месяцев за счёт синхронизации двух платформ. Простое приложение-витрину с личным кабинетом можно вывести за 6–8 недель, а первую рабочую сборку для проверки гипотезы — за две.
Можно ли перевести существующее нативное приложение на Flutter?
Технически да, но по трудоёмкости это близко к новой разработке: переносится дизайн и бизнес-логика, код — нет. Такой переход оправдан, если вы содержите две нативные команды и планируете активно развивать продукт ещё несколько лет. Ради разовой экономии переписывать работающее приложение не стоит.
Итог
Для бизнес-приложений Flutter — разумный выбор по умолчанию: дешевле на 35–45%, быстрее на месяц, поддерживается одной командой. Нативная разработка остаётся ответом там, где приложение живёт возможностями устройства, а не экранами.
Расскажите, что должно уметь ваше приложение, — вернёмся со сметой по обоим вариантам и честно скажем, где разница в цене того не стоит. Собрать ТЗ с AI или посмотреть, как мы делаем мобильные приложения.
