Процесс разработки Flutter-приложения: как мы доводим идею до App Store

TL;DR. Процесс разработки Flutter-приложения состоит из семи фаз: дискавери и определение объёма, UX/UI-дизайн, архитектура и фундамент, итеративная разработка, QA и тестирование, релиз и поддержка после запуска. Связывает их то, что это циклы обратной связи, а не водопад: дизайн стартует раньше, чем закончится дискавери, QA идёт параллельно сборке, а не после неё, и каждые две недели вы получаете не статус-отчёт, а сборку, которую можно поставить себе на телефон. Единственное правило, которое мы не гнём: инварианты идут раньше кода фич. Модель состояния, тема, таксономия ошибок, CI-пайплайн и стратегия тестирования решаются на первой неделе, потому что каждый экран, написанный потом, либо им следует, либо с ними воюет. Типичная сборка — 2–3 месяца для MVP и 3–5 месяцев для полноценного продукта, а релиз — это середина процесса, а не его конец.

Этапы разработки Flutter-приложения одним взглядом

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

Это диапазоны, и они перекрываются — календарь короче, чем сумма строк. Куда на реальном проекте уходят недели, разбираем в парном материале: сколько времени занимает разработка Flutter-приложения. Сколько стоит каждая фаза — в стоимости разработки Flutter-приложения в 2026.

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

1. Дискавери и определение объёма

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

Из неё выходят три вещи:

• Упорядоченный бэклог. Не «управление пользователями», а «вход через Apple, вход по почте, сброс пароля, удаление аккаунта». Размытые пункты — это место, где умирают оценки.
• Список отсечения. Фичи, которых нет в первой версии, записанные и согласованные. Самый ценный артефакт всего процесса и тот, которому клиенты сопротивляются сильнее всего.
• Оценка с фиксированным объёмом и сроками, выведенная из бэклога, а не из ощущения «ну, приложение как приложение».

Именно здесь на самом деле определяются бюджет и сроки — поэтому скомканное дискавери самый дорогой способ сэкономить неделю. Когда вы описываете «простой трекер тренировок», а мы возвращаем бэклог на 40 экранов, этот разрыв — не накрутка: онбординг, авторизация, настройки, удаление аккаунта, платежи, пуши и офлайн всегда были в том приложении, которое вы описали. Как объём складывается в цифру — в разборе стоимости.

Где ломается: дискавери с тем, кто не может принимать решения. Если каждый ответ уходит на согласование в комитет, дискавери растягивается с недели до четырёх, а оценка строится на песке.

2. UX/UI-дизайн

UX/UI-дизайн — это фаза, на которой определяется визуальный язык приложения и язык взаимодействия. Начинается он с системы, а не с экранов.

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

Такой порядок — не про эстетику, а про скорость сборки. Flutter отрисовывает каждый пиксель из кода на Dart, и зрелая дизайн-система ложится на ThemeData почти один в один: подключается один раз, а каждый следующий экран собирается из уже существующих компонентов. Без неё получается то, что мы описываем в материале почему ИИ-агенты буксуют на Flutter: сорок экранов, каждый из которых работает, но которые не складываются в одно приложение, цвета захардкожены в каждом месте вызова, а ребрендинг стоит диффа на несколько сотен файлов.

Мы сразу проектируем и под те ограничения, которые позже ломают Flutter-вёрстку, — длинные строки во второй локали, масштаб текста 200%, маленькие экраны на 320pt. Поймать это в Figma стоит минут; поймать на QA стоит редизайна. На выходе фазы — дизайн-система и кликабельный прототип, ещё до первой строки кода фич.

Где ломается: дизайн по кругу согласований. Три раунда «а покажите ещё вариант» на главном экране сдвигают все последующие фазы, потому что разработчики не могут строить по движущейся цели.

3. Архитектура и фундамент

Архитектура — это фаза, на которой принимаются решения, от которых зависит каждый последующий экран, — до того, как появился хоть один экран. На практике это значит, что одну-две недели мы строим приложение, которое ничего не делает.

Эти две недели определяют следующие полгода. Что решается:

• Управление состоянием. Один выбор, применённый везде. Sealed-классы состояний, чтобы недопустимые комбинации — загрузка и ошибка одновременно — были непредставимы, а не просто маловероятны.
• Структура папок и границы модулей. Где живёт фича и что ей можно импортировать.
• Таксономия ошибок. Именованные режимы отказа — сеть, протухшая авторизация, валидация, отклонённый платёж, конфликт — вместо одного «Что-то пошло не так», после которого любой баг невоспроизводим.
• CI/CD. Зелёный пайплайн с первого дня: flutter analyze с линтами, поднятыми до ошибок, flutter test, артефакт сборки на каждый коммит, Fastlane, подключённый к TestFlight и внутреннему треку Google Play.
• Стратегия тестирования. Какие слои покрываются widget-тестами, какие экраны — golden-тестами, какой бюджет на кадр.

Мы называем это инвариантами, и они идут первыми, потому что дёшево их потом не встроишь. «Следуй существующему паттерну» — дешёвая инструкция и для человека, и для агента, но только когда есть на что показать. В репозитории без инвариантов каждый изобретает свои, и получается та самая археология, за аудит которой нам платят два года спустя. Фаза заканчивается работающим скелетом, зелёным пайплайном и короткими записями решений по тем вопросам, которые следующий инженер иначе будет обсуждать заново.

4. Итеративная разработка

Итеративная разработка — это фаза, на которой фичи собираются и выкатываются небольшими демонстрируемыми инкрементами, а не выдаются одним куском в конце. Рабочий процесс разработки на Flutter здесь строится на вертикальных срезах фич: одна фича, сделанная насквозь — UI, состояние, интеграция с API, обработка ошибок, тесты, — вместо «сначала все экраны», а потом «вся проводка». Срез, который можно открыть на телефоне, говорит вам правду. Папка несвязанных экранов — нет.

Ритм — демонстрируемый инкремент каждые одну-две недели, на вашем устройстве через TestFlight или внутренний трек Google Play. Не скриншот и не запись экрана, а приложение у вас в руках, которое можно дать коллеге.

Ревью — про решения, а не про строки. Это та же модель состояния, что и в остальном приложении? Стилизовано из темы? Это значение выводится один раз или уже в третий? Эта строка переживёт русский язык? Агенты пишут заметную долю кода, а наши инженеры владеют этими решениями — так мы и строим: построчное ревью сгенерированного кода не масштабируется, ревью на уровне решений — да.

Параллельно продолжают идти дизайн и QA, а вместе с ними и бэкенд — поэтому систему вроде слоя реалтайм-котировок в ExtraETF можно строить и нагружать, пока Flutter-клиент ещё собирает экраны на моках.

Где ломается: молчаливые спринты. Если проходят две недели, а вы не открыли сборку, цикл разорван — и о недопонимании вы узнаете на месяц позже.

5. QA и тестирование

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

Что гоняется в CI на каждый коммит:

• Widget-тесты на поведение: кнопка блокируется на время отправки, ошибка гаснет при повторном вводе, список подгружается на нужном оффсете.
• Golden-тесты на внешний вид — самый выгодный тип тестов во Flutter, потому что golden превращает вопрос «а не сломал ли редизайн пустое состояние на 320pt в тёмной теме при масштабе текста 200%?» в проверку, которая проходит за секунды, вместо вопроса, который никто не задаёт.
• Интеграционные тесты на сценарии, которые при поломке стоят денег: регистрация, оформление заказа, оплата.
• Регрессионный тест на каждый исправленный баг, чтобы он не вернулся.

То, что не может машина, делает человек на живом железе: приложение при масштабе текста 200%, в тёмной теме, на обоих языках, на маленьком старом Android-телефоне, с придушенной сетью, а потом с обрывом посреди запроса. Десять минут такого находят целый класс дефектов, о которых ни одна статическая проверка никогда не сообщит.

И мы держим бюджет кадра — 16,6 мс при 60 fps, проверяется на profile-сборках. Список, который начинает дёргаться после того, как кто-то добавил тень и Opacity внутрь билдера элемента, — это регрессия, которую не ловит ни один юнит-тест и которую чувствует каждый пользователь.

6. Релиз

Релиз — это фаза, на которой приложение проходит подачу в сторы, ревью и раскатку. Это 1–2 недели работы, которые большинство планов делает вид, что занимают вечер.

Материалы и метаданные для сторов — скриншоты во всех требуемых размерах, описания, ключевые слова, privacy nutrition labels, декларации по безопасности данных. Удаление аккаунта обязано быть внутри приложения; оба стора это требуют.

Реальность ревью. Ревью Apple обычно занимает 24–48 часов, но «обычно» не значит «гарантированно», и категории отказов предсказуемы: нет удаления аккаунта, стена авторизации без демо-доступа, неполная декларация приватности, платежи в обход внутренних покупок. Для тех, кто выпускает много брендированных приложений, правило 4.2.6 — отдельная дисциплина, и что реально проходит ревью мы разбирали на масштабе флота. Ревью Google обычно быстрее, но новый аккаунт разработчика может провисеть в расширенной проверке несколько дней.

Поэтапная раскатка. Мы выкатываем на 10% в Google Play и смотрим на crash-free rate, прежде чем расширять; phased release в App Store делает то же самое. Плохая сборка, пойманная на 10%, — это испорченный вечер. Она же на 100% — испорченная неделя.

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

7. После запуска и поддержка

Поддержка после запуска — это фаза, на которой приложение встречается с реальными пользователями и продолжает меняться. Запуск — её начало, а не конец проекта.

Реальное использование мгновенно вскрывает то, что не поймает ни один тест: оболочку Android от вендора, которая ломает пуши, обновление ОС, которое выпиливает API, падение на устройстве, которого у вас не было. Поэтому процесс продолжается:

• Мониторинг — отчёты о падениях, трассировки производительности и аналитика по значимым сценариям: ежечасно первые 48 часов и еженедельно дальше.
• Итерации — тот самый бэклог, который вы отсекли на дискавери, переприоритизированный под то, что люди делают на самом деле.
• Поддержка — ежегодные релизы ОС, обновления SDK, изменения правил сторов, ротация сертификатов и ключей API. Flutter и его плагины двигаются; приложение, которое не трогали год, не стабильное, а протухшее.

Закладывайте бюджет на продукт, а не на проект. Приложение, которое выпустили и бросили, медленно едет обратно к переписыванию с нуля.

Как мы держим это в графике

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

Жёсткий объём, записанный на бумаге. Список отсечения с дискавери — это контракт со сроками; новые идеи уходят в список v2, и мы говорим об этом вслух. Ломается, когда список никто не защищает: каждая «мелкая добавка» действительно мелкая, а двадцатая — это месяц.

Решающий заказчик и внятный ритм. Один человек, который может согласовать экран в тот же день, когда его увидел, еженедельный созвон и сборка для установки. Ломается, когда решения идут через комитет. На шестинедельной сборке неделя задержки решений — это 20% перерасхода ещё до того, как разработчик сделал что-то не так.

Инварианты, заданные сразу. Причина, по которой наш третий месяц стоит примерно столько же, сколько первый. Ломается, когда дедлайн соблазняет пропустить первую неделю и сразу взяться за экраны.

Короткие циклы обратной связи. Устанавливаемые сборки каждые одну-две недели, QA в CI, демо, которое вы правда открываете. Ломается, когда клиент замолкает: цикл работает, только если на другом конце кто-то есть.

И честное: наши оценки ошибаются в одну сторону. Сильнее всего они промахиваются на интеграциях. Любой сторонний SDK выглядит в презентации как работа на вечер и превращается в двухнедельную отладку пограничных случаев на Android 10. Мы закладываем на это запас, а не делаем вид, что его не нужно, — и если фаза поедет, вы услышите об этом на той же неделе, а не на дедлайне.

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

Давайте определим объём вашей сборки

Вот так и создаются Flutter-приложения, когда процессом действительно кто-то управляет. Если вы выбираете подрядчика, процесс и есть продукт: скриншоты вам покажет кто угодно. Выйдет ли приложение в срок, решает то, стоит ли за ним настоящая машина — список отсечения, который кто-то защищает, инварианты, заданные на первой неделе, сборка у вас на телефоне каждые две недели и тесты, которые проходят раньше, чем на код посмотрит человек.

• Запишитесь на дискавери-звонок, и мы прогоним вашу идею через первый шаг: напишите нам. На выходе — упорядоченный бэклог, список отсечения и оценка с фиксированным объёмом, а не вилка, в которой можно спрятаться.
• Посмотрите предложение — команда, стек и тарифы на странице разработки Flutter-приложений.
• Уже есть сборка? Если этот процесс до нас вёл кто-то другой и вёл плохо, аудит кода покажет, во сколько обойдётся починка на месте — почти всегда дешевле, чем переписывание, которое вам предлагают.

Расскажите, что вы строите и где застряли, а мы честно скажем, какие фазы пройдут легко, а какие будут болеть.

Дима — ведущий Flutter-разработчик Nerdy Production, Flutter-first агентства, которое доводит приложения от дискавери до App Store в финтехе, ритейле и AI-продуктах.