Ошибки Flutter при вайб-кодинге: 12 ловушек и правки

Почему Flutter-проекты ломаются ближе к релизу

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

Flutter-проект растет слоями. Сначала появляется UI, потом состояние, навигация, сеть и обработка ошибок. Если правила не зафиксировать в начале, каждый новый экран начинает жить по своим законам. В чате это выглядит безобидно: «сделай так же, как на предыдущем экране». На практике «так же» часто означает «чуть иначе».

Ближе к релизу всплывают вещи, которые сложно заметить в ранней сборке:

• Экран иногда открывается «не тот», кнопка «назад» ведет странно, а состояние внезапно сбрасывается.
• Один и тот же API вызывается разными клиентами и моделями, и данные начинают расходиться.
• Формы пропускают пустые поля или показывают ошибки только после отправки.
• Разрешения на камеру, геолокацию или уведомления работают на Android, но ломаются на iOS (или наоборот).
• В релизной сборке появляются падения, которых не было в debug.

Есть и ранние признаки, что проект начинает расползаться. Например, новый экран каждый раз требует «подкрутить» навигацию в трех местах. Или исправление одного бага рождает два новых. Еще один сигнал - вы уже не уверены, где именно хранится состояние: в виджете, в отдельном классе или в глобальной переменной.

Задача на этом этапе простая: сделать поведение предсказуемым. Чтобы сборка работала одинаково в debug и release, экраны открывались одинаково на всех устройствах, а ошибки обрабатывались одинаково по всему приложению. На платформах, где код быстро генерируется и меняется (например, TakProsto), это особенно важно: правила должны держать проект в форме, пока вы добавляете функции.

12 типичных ловушек: симптомы и быстрые направления фикса

Проблемы чаще всего не про «плохой Flutter», а про размытые ожидания и куски логики, сделанные в разном стиле. Почти любую ловушку можно распознать по симптомам и быстро сузить круг причин.

Чтобы не чинить вслепую, перед правкой зафиксируйте ожидание пользователя:

• Что пользователь сделал (3-5 шагов) и что ожидал увидеть.
• Что увидел на самом деле (текст, экран, зависание).
• Повторяется ли это на «чистой установке» и в релизной сборке.
• Какие были условия (логин, пустой список, слабая сеть).

Если вы собираете приложение в TakProsto, полезно прямо в чате попросить: «опиши, где хранится источник правды для состояния и как устроена навигация». Дальше проще привести проект к одному выбранному стилю и убрать половину «мистических» багов еще до глубокого рефакторинга.

Навигация и состояние: когда экраны ведут себя странно

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

Типовые симптомы

Чаще всего видно такое:

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

Корень один и тот же: маршруты и параметры создаются на лету в разных местах, а состояние экрана хранится там, где оно постоянно пересоздается.

Как чинить

Начните с правила: один источник правды для маршрутов и параметров. Не собирайте путь к экрану строками в разных файлах. Держите маршруты в одном месте и передавайте параметры явно (лучше одним объектом), чтобы их было легко проверить и логировать.

Полезная договоренность: любой переход имеет понятное имя и одну схему параметров. Тогда диплинк, пуш и переход внутри приложения используют один и тот же код. Если вы работаете через TakProsto, удобно сначала сгенерировать единый роутер и тип параметров для ключевых экранов, а затем закрепить эти правила вручную.

Второе правило - про состояние:

• Состояние экрана (то, что можно безопасно потерять): выбранная вкладка, позиция скролла. Храните рядом с виджетом.
• Состояние фичи (то, что важно между экранами и сессиями): корзина, авторизация, черновик формы. Держите выше, в одном месте, и не пересоздавайте при каждом переходе.

И отдельно проверьте «сворачивание-возврат» и «открытие из пуша». Если стартовый экран выбирается по логике (например, авторизован или нет), убедитесь, что проверка работает одинаково при холодном старте и при возврате из фона.

API-клиент и модели: как не получить рассинхрон

Многие проблемы начинаются тихо: на одном экране все хорошо, на другом - внезапные падения или странные данные. Частая причина простая: один и тот же ответ сервера парсится по-разному в разных местах.

Типичный сценарий: поле в JSON называется одинаково, но в коде живет под разными именами. Где-то ждут phoneNumber, а где-то phone или tel. Пока вы тестируете один путь, все выглядит нормально. Добавляете второй экран или редактирование - начинается хаос.

Один API-клиент на весь проект

Еще одна ловушка - несколько клиентов с разными настройками. Один ходит на baseUrl для dev, второй случайно на prod. Один ставит заголовок авторизации, другой нет. В одном таймаут 5 секунд, в другом 30. В итоге ошибки «плавают» и зависят от экрана.

Чтобы убрать сюрпризы, закрепите простые правила:

• Один источник baseUrl, заголовков, таймаутов и логирования.
• Единый интерсептор: токен, общий формат ошибок, при необходимости корреляционный id.
• Одинаковый формат ошибки для UI: код, текст для пользователя, текст для логов.

DTO отдельно, доменные модели отдельно

Если одна и та же модель используется и для API, и для UI, вы неизбежно начинаете «подгонять» данные под интерфейс. Потом сервер меняет поле или делает его nullable - ломается половина приложения. Практичнее разделить: DTO (то, что пришло по сети) держать отдельно, а доменные модели (то, с чем работает UI) строить через явное преобразование.

Особенно больно это проявляется на датах и числах: сегодня дата приходит строкой, завтра - Unix timestamp. Или число приходит как строка ("100") и где-то парсится, а где-то нет. Если договориться о формате не получается, сделайте один общий парсер и используйте его везде.

Практический пример: на экране списка заказов вы мягко игнорируете total=null, а на экране деталей делаете total! и ловите падение только у части пользователей. При едином DTO и маппинге вы либо покажете понятную ошибку, либо одинаково подставите значение по умолчанию.

Если вы быстро накидываете экраны через TakProsto, отдельно проверьте, что все запросы идут через один клиент и один слой маппинга. Это экономит часы отладки прямо перед релизом.

Формы и валидация: баги, которые видит каждый пользователь

Если в приложении есть регистрация, оплата или хотя бы профиль, форма становится местом, где проблемы заметны сразу. Пользователь не будет разбираться, почему «не отправляется» или почему данные пропали после поворота экрана.

Клиент и сервер: не спорьте правилами

Частая ошибка: на клиенте вы проверяете одно, а сервер требует другое. Например, в UI написано «минимум 6 символов», а бэкенд требует 8 и спецсимвол. Итог - форма выглядит валидной, пользователь жмет «Создать аккаунт» и получает непонятную ошибку.

Практичнее считать сервер финальным источником истины, а клиент использовать для быстрых подсказок. Если сервер возвращает ошибки по полям, не прячьте их за «что-то пошло не так». Разложите ответ на ошибки конкретных полей (email, phone, password) и отдельную общую ошибку формы (например, «Аккаунт уже существует»).

Отправка формы: одна кнопка, один запрос

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

Закрепите минимум:

• Блокируйте кнопку и показывайте состояние отправки, пока запрос не завершился.
• На ошибку показывайте понятный текст и оставляйте данные в полях.
• Защищайтесь от повторных нажатий (например, флагом isSubmitting).
• Разделяйте сетевые ошибки и ошибки валидации: разные сообщения, разное поведение.

Данные пропали: ориентация и возврат назад

Больной сценарий: пользователь заполняет 7 полей, случайно переворачивает телефон или возвращается на предыдущий экран и снова заходит. Если TextEditingController создается не там, где нужно, ввод легко потерять.

Ориентир простой: контроллеры и ключ формы должны жить в состоянии виджета (State), а не пересоздаваться при каждом рендере. Если экран часто пересобирается, храните черновик формы в слое управления состоянием, чтобы можно было восстановить ввод.

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

Разрешения Android и iOS: где чаще всего забывают

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

Что ломается чаще всего

Проблема обычно не в плагине, а в моменте и логике запроса. Пользователь открывает экран, сразу видит системный диалог, жмет «Запретить» - и приложение оказывается в тупике: кнопка ничего не делает, объяснения нет.

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

Android и iOS отличаются сильнее, чем кажется. На iOS критичны тексты объяснений и строки Usage Description (без них функция может не заработать). На Android нужно учитывать версии и типы разрешений: где-то доступ дается один раз, где-то только «пока используется», где-то отдельным разрешением идут уведомления или доступ к медиа.

Минимум, который стоит продумать для камеры, фото, гео и файлов:

• Запрашивать разрешение не на старте, а прямо перед действием пользователя (после понятного объяснения).
• Обработать все исходы: разрешено, отказано, отказано навсегда.
• Дать замену: «Загрузить фото из галереи» вместо камеры, «Ввести адрес вручную» вместо гео.
• Показать, что делать дальше: где включить разрешение в настройках.
• Проверить на реальном Android и реальном iPhone (хотя бы по одному устройству).

Шаблон поведения, который спасает релиз

Рабочий паттерн простой: сначала коротко объяснить причину, потом вызвать системный диалог. Например: «Нужен доступ к камере, чтобы сканировать чек. Фото не сохраняются без вашего действия». Если пользователь отказал - покажите экран-состояние: что недоступно и какой есть обходной путь.

Если собираете приложение в TakProsto, лучше сразу прописывать требования: какие разрешения нужны, когда их спрашивать и что показывать при отказе. Тогда сюрпризов перед стором будет меньше.

Сеть и ошибки: таймауты, офлайн и повторные запросы

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

Таймауты и «вечная загрузка»

Если запрос может висеть бесконечно, пользователь видит крутилку и решает, что приложение сломалось. Любому сетевому вызову задайте таймаут и понятный выход: показать ошибку, дать кнопку «Повторить», вернуть экран в управляемое состояние.

Договоритесь об одной политике загрузки на экране. Если есть глобальный индикатор, убедитесь, что он снимается в любом исходе (успех, ошибка, отмена, таймаут).

Офлайн: что показывать и когда пробовать снова

Офлайн - это не только «нет сети», но и портал авторизации в Wi‑Fi, и недоступный сервер. Минимум поведения:

• Показывать последнюю удачную версию данных, если это уместно.
• Писать человеческий статус: «Нет соединения», а не «Exception».
• Дать явное действие: «Повторить».
• Делать автоповтор с паузой, а не каждую секунду.

Например, список заказов можно показать из кэша, а экран оплаты лучше блокировать до восстановления связи.

Повторные запросы без дублей

Повторы опасны там, где запрос меняет состояние: оплата, создание записи, отправка формы. Если сеть «моргнула», легко получить дубли.

Обычно спасает комбинация: блокировка кнопки на время выполнения плюс идемпотентность для важных операций (одинаковый ключ запроса дает один результат). На клиенте полезно хранить идентификатор операции и не отправлять ее повторно, пока не пришел ответ или не истек разумный таймаут.

Единый слой ошибок и кэш

Сведите ошибки к нескольким понятным типам: таймаут, нет сети, 401/403, 500, неизвестно. Пусть UI получает уже «переведенное» сообщение и подсказку действия (повторить, войти заново, попробовать позже).

Кэшируйте то, что можно безопасно показать устаревшим: справочники, настройки, списки. Не кэшируйте токены и одноразовые действия.

Релизные сборки: чем они отличаются и где ловушки

Release-сборка Flutter ведет себя иначе, чем debug: меньше подсказок, больше оптимизаций, другой режим логов и иногда другая инициализация. Поэтому «все было нормально на эмуляторе» не значит, что приложение переживет публикацию.

Почему debug работает, а release ломается

В release отключены многие проверки и меняется поведение asserts. Ошибки, которые в debug «прощались», превращаются в падения или пустые экраны. Частая причина - гонки при инициализации: в debug приложение медленнее, и проблема не проявляется.

Отдельный класс проблем - обфускация и R8/ProGuard на Android. Если библиотека полагается на reflection (например, для сериализации), в релизе нужные классы могут быть переименованы или «вырезаны». Симптомы похожи: ломается парсинг JSON, не создаются модели, не вызываются колбеки.

Ресурсы: «перед релизом пропали шрифты и иконки»

Если ассеты и шрифты не прописаны правильно, debug иногда подхватывает их из проекта, а release собирает только то, что заявлено явно. Проверьте pubspec.yaml и реальное расположение файлов. То же касается launcher icon и сплэш-ресурсов: они могут отличаться между flavors, и релиз соберется «без красоты».

Перед публикацией часто ошибаются и в метаданных: versionName/versionCode (Android) и build number (iOS). Это не баг рантайма, но блокер релиза.

Практичная мини-проверка перед стором:

• Соберите именно release на физическом устройстве, не только на эмуляторе.
• На Android посмотрите логи через adb logcat, на iOS - Device Logs в Xcode.
• Повторите критичные сценарии: логин, первая загрузка данных, формы, навигация назад.
• Проверьте подпись: keystore/provisioning, bundle id, совпадение идентификаторов.

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

Пошагово: проверяем проект перед тем, как «отправлять в стор»

Перед отправкой в стор лучше на час замедлиться, чтобы на день ускориться. Большинство сюрпризов в Flutter всплывает не в идеальном сценарии, а в реальных условиях: сеть, разрешения, возврат назад, «пустые» поля и поведение в релизной сборке.

Шаг 1. Зафиксируйте 3-5 главных сценариев пользователя

Выберите только то, что пользователь делает чаще всего и за что вас будут оценивать. Цель - поймать релизные стопперы.

Для простого приложения это обычно: первый запуск и онбординг, регистрация/логин и выход, основное действие (создать заявку, оформить заказ, отправить форму), экран списка и экран деталей, восстановление после закрытия приложения.

Шаг 2. Пройдите сценарии на реальном устройстве и записывайте сбои

Эмулятор не показывает часть проблем: медленный интернет, фоновые ограничения, странности клавиатуры, поведение «Назад». Пройдите сценарии минимум на одном Android и одном iPhone. Каждый сбой фиксируйте коротко: что делали, что ожидали, что получилось, как повторить.

Если вы делали приложение вайб-кодингом (например, в TakProsto), удобно сначала сделать snapshot, а правки вносить небольшими порциями. Так проще откатиться, если исправление потянуло новый баг.

Шаг 3. Проверьте разрешения и поведение при отказе

Разрешение должно запрашиваться не «на всякий случай», а в момент, когда оно реально нужно. И самое важное - приложение должно жить, если пользователь нажал «Запретить».

Проверьте: что показываем без доступа (камера, геолокация, уведомления), можно ли продолжить работу, есть ли понятная подсказка, что включить и зачем.

Шаг 4. Прогоните релизную сборку и проверьте критичный путь

Прогоните в релизе самый важный путь: старт приложения, логин, отправка данных (заказ, платеж, заявка), выход и повторный вход. Именно тут чаще проявляются проблемы с инициализацией, навигацией и сетью.

Шаг 5. Соберите правки и приоритизируйте по риску

Когда список багов готов, не пытайтесь «доделать все». Обычно спасает простая шкала:

• Блокер: нельзя пройти основной сценарий (не логинится, не отправляется форма, краш).
• Высокий риск: потеря данных, зависания, неверные суммы/статусы.
• Средний: раздражает, но есть обходной путь.
• Низкий: косметика.

План дальше простой: чините блокеры и высокий риск, снова проходите 3-5 сценариев, и только потом беритесь за «приятности».

Быстрый чеклист, пример и следующие шаги

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

Чеклист перед тестом и релизом (5 минут)

Пробегитесь по пунктам на реальном устройстве:

• Навигация: нет ли лишних экранов в back stack, не закрывается ли приложение «назад» раньше времени, корректно ли выбирается стартовый экран после авторизации.
• Состояние: не прыгает ли UI после возврата, не дублируются ли запросы при каждом открытии, не теряются ли выбранные фильтры.
• API и модели: нет ли разных версий одного DTO, одинаково ли парсятся даты и nullable-поля.
• Формы: ошибки показываются рядом с полем, пустые значения не проходят, нет ли двойной отправки при быстром тапе.
• Разрешения и релиз: камера/гео/уведомления запрашиваются вовремя, релизная сборка не падает на старте и не «молчит» при сетевой ошибке.

Что проверить за 15 минут, если времени мало

Сделайте «маршрут пользователя» от первого запуска до ключевого действия: установка -> первый старт -> вход/регистрация -> главный экран -> создание/оплата/запись -> выход и повторный вход. На каждом шаге задайте себе два вопроса: что будет без интернета и что будет при повторном открытии экрана.

Пара быстрых тестов, которые часто ловят поздние сюрпризы:

• Включите режим полета и попробуйте отправить форму. Приложение должно показать понятную ошибку и дать повторить.
• Сверните и разверните приложение во время загрузки. Если экран «сбрасывается», значит состояние живет не там.
• Быстро нажмите кнопку отправки 2-3 раза. Если улетело несколько запросов, нужна блокировка или защита на уровне API.

Пример из жизни: приложение записи к врачу

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

Что реально ломается:

• После выбора времени пользователь возвращается назад, а список слотов снова грузится и перескакивает наверх. Причина: состояние списка хранится в виджете, а запрос запускается в build.
• В API клиенте дата приема отправляется как строка в одном формате, а парсер ответа ждет другой. В debug это может «проглатываться», а в релизе вылезает как пустая дата и падение при форматировании.
• Телефон проходит с пробелами и скобками, сервер возвращает 400, а UI показывает «что-то пошло не так».
• На iOS камера для загрузки полиса не открывается, потому что разрешение не описано.

Как чинится быстро: вынести загрузку и выбранные значения в единый источник состояния, унифицировать модели (один DTO на сущность и один маппинг), нормализовать ввод (trim, маска, проверка), а ошибки API переводить в понятные сообщения для пользователя.

Как не повторять это в следующей фиче

Зафиксируйте договоренности в проекте: один способ навигации, один подход к состоянию, один API клиент, одно место для валидации. Добавьте короткие шаблоны: экран с загрузкой и ошибкой, форма с блокировкой кнопки, единый обработчик сетевых ошибок.

В TakProsto это удобно закреплять через planning mode: сначала описать поток экранов и контракты API, а потом уже генерировать и править код. Перед рискованными правками делайте snapshots, чтобы быстро откатиться, если новая версия повела себя хуже. Когда все стабильно, экспортируйте исходники и доведите релизную сборку до публикации через привычный вам процесс сборки и тестирования.