- Хотим запуститься сразу на iOS и Android. Берем Flutter - так же дешевле?
- Возможно. А что внутри: офлайн, BLE, камера, фоновые задачи, кастомные платежи?
- Да, и еще нужен очень нативный UX, потому что приложение - часть основного сервиса.
- Тогда считать надо не старт, а потери на горизонте 12-24 месяцев.
Я много раз проходил эту развилку с клиентами. Ошибка обычно одна: стек выбирают по первому счету, а бизнес потом платит за релизы, обходные решения и баги, которые на старте никто не заложил.
Где Flutter реально экономит
Если сценарии на двух платформах почти одинаковые, Flutter в 2026 все еще сильный вариант. Каталог, запись, доставка, личный кабинет, программа лояльности, внутренний сервис для сотрудников - здесь одна codebase на Flutter и Dart часто дает экономию по сроку 20-35%. Вместо 14-16 недель можно выйти в релиз за 10-12 недель.
У нас в прошлом году был проект для сети клиник: запись, история визитов, уведомления, чат, онлайн-оплата. Собрали на Flutter 3.29, Laravel 11, PostgreSQL 16, Firebase Crashlytics. Первый релиз вышел за 11 недель, и по деньгам клиент сэкономил около 1,1 млн ₽ по сравнению с двумя нативными командами.
Экономия появляется там, где приложение по сути делает одно и то же на iPhone и Android-смартфоне. UI общий, бизнес-логика общая, QA проще, релизный цикл короче. Для MVP это часто лучший вход.
Где эта экономия заканчивается
Проблема начинается, когда бизнес слышит «один код» и переносит это на весь продукт. На практике камера, карты, NFC, BLE, фоновые синхронизации, Live Activities, виджеты, нестандартные платежи быстро тянут за собой платформенный слой. В этот момент вы уже платите и за общий код, и за отдельную работу под iOS и Android.
| Что смотрим | Flutter | Натив |
|---|---|---|
| Типовой UI | быстрее на старте | дольше на старте |
| Бизнес-логика | общий код | часть логики дублируется |
| Сложные функции устройства | растет платформенный код | поведение ровнее |
| Жизнь продукта через год | зависит от plugin и SDK | чаще предсказуемее |
CTO логистической платформы как-то очень точно сказал: «Мы сэкономили на первом релизе, а потом полгода покупали себе предсказуемость».
Я бы не стал брать Flutter первым выбором, если приложение само зарабатывает деньги и мобильный опыт влияет на выручку. Цена мелких сбоев там слишком высокая.
Когда натив окупается раньше
Звучит странно, но на горизонте 9-18 месяцев натив часто выходит дешевле. Особенно если приложение - основной продукт, а не дополнительный экран к сайту или CRM.
У нас был логистический сервис с офлайном, картами, трекингом, фоновой синхронизацией и нестандартными push-сценариями. Клиент хотел уложиться в 3,5 млн ₽ и шел в Flutter. После проектирования стало ясно, что половина рисков сидит в системных функциях. Пошли в Swift 6 + SwiftUI и Kotlin 2 + Jetpack Compose. Старт стал дороже примерно на 28%, но за следующие 10 месяцев команда выпускала релизы быстрее и не теряла недели на обход ограничений фреймворка.
Flutter для MVP почти всегда стоит смотреть первым?
Да, если вы действительно проверяете спрос, конверсию, возврат пользователей. Если это уже фундамент продукта на годы, я бы сначала посчитал полную стоимость владения, а не только старт.
Для MVP есть короткий фильтр
Я обычно смотрю на две цифры: запуск и развитие. Без этого разговор о том, что дешевле, почти бесполезен.
Перед стартом хватает четырех вопросов:
- что именно проверяет MVP, кроме самого факта «можно зайти и нажать кнопку»
- какие функции обязательны уже в релизе 1.0
- что почти наверняка появится через 12 месяцев
- есть ли уже сейчас офлайн, Bluetooth, тяжелый клиентский код, сложная авторизация, работа в фоне
Если на последнем пункте много ответов «да», дешевый старт легко превращается в дорогую миграцию. Я видел это десятки раз.
Кейс, где мы сами ошиблись
Был проект для полевых сотрудников: фотоотчеты, геотрекинг, офлайн, фоновая синхронизация, работа с Bluetooth-датчиками. На старте Flutter выглядел логично - один код, смета ниже, релиз быстрее на 6-8 недель. Так и пошли.
Через несколько месяцев стало ясно, что интерфейсы здесь вообще не главная проблема. Основное время уходило на platform channels, разное поведение iOS и Android в фоне и долгую диагностику через Crashlytics и Sentry. В итоге часть модулей переписали нативно, релизы замедлились, а стартовая экономия исчезла.
Мы ошиблись в оценке продукта. Смотрели на него как на обычное приложение, а это уже был мобильный инструмент с тяжелой системной логикой.
Просите у подрядчика не цену первого релиза, а две сметы: запуск и TCO на 12-24 месяца. Если вторую смету не могут собрать даже грубо, стек вам продают вслепую - а платить за это будете вы.
