Flutter 3.47: почему после апгрейда падает сборка 1С-приложения

Flutter 3.47 переводит рендеринг на Impeller на всех платформах, добавляет полноценную сборку в WebAssembly для веба и обновляет набор виджетов Material 3. Для бизнеса это означает более плавную анимацию и быстрый старт приложения, но одновременно — риск сломать сборку из-за устаревших пакетов и зависимостей, если обновляться без аудита кода.

Что изменилось в Flutter 3.47 для бизнес-приложений

Главное изменение — Impeller как рендерер по умолчанию на всех платформах, а не только на iOS и части Android-устройств. Раньше сложные экраны с анимированными графиками — например, дашборд остатков склада, который тянет данные из 1С в реальном времени, — иногда подвисали на первом кадре из-за компиляции шейдеров на лету. Impeller компилирует шейдеры заранее, и это подвисание пропадает.

Второе изменение — сборка веб-версии в WebAssembly становится основным путём вместо чистого JavaScript. Для личного кабинета сотрудника или клиента, который открывают в браузере на слабом офисном ноутбуке, это ощущается как более быстрый первый экран: движок парсит и запускает код быстрее, чем интерпретируемый JS.

Третье — у Material 3 закрыли токены темизации, а инструменты вроде hot reload и DevTools стали стабильнее на крупных кодовых базах. Для конечного пользователя это незаметно, а для команды поддержки означает, что правки по тикетам долетают до прод быстрее.

Отдельно стоит сказать про Android: до 3.47 часть проектов держала Impeller выключенным флагом из-за мерцания на бюджетных смартфонах — частый сценарий для курьерских и складских приложений, где парк устройств собирают из того, что есть, а не из топовых моделей. В 3.47 эти баги закрыты, и флаг можно убирать без опасения, что приложение на трёхлетнем Android-смартфоне склада замигает при открытии камеры сканера.

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

Почему после обновления до Flutter 3.47 падает сборка корпоративного приложения

В пятницу вечером релиз-инженер логистической компании с парком в 40 машин запускает flutter upgrade перед понедельничной сдачей трек-листа для водителей. Сборка под iOS падает сразу: один из виджетов формы использует deprecated API, а форма тянет данные из 1С через плагин интеграции приложения с 1С. Дальше pub get конфликтует: этот же плагин держал жёсткий пин версии http-пакета под старый рендерер, а Impeller требует более свежую ветку зависимостей. CI зависает на предупреждениях компиляции шейдеров — кэш шейдеров собирался ещё под прежнюю версию движка и не совместим с новой.

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

Как исправить конфликты зависимостей и deprecated API после апгрейда

Снять карту зависимостей до апгрейда, а не после

Команда flutter pub outdated показывает, какие пакеты отстали и какие держат жёсткий пин версии. dart fix --apply автоматически переписывает часть вызовов, помеченных как deprecated, под новый API. Это стоит прогонять до апгрейда Flutter, а не постфактум, когда сборка уже красная и релиз горит.

Что смотреть в release notes перед апгрейдом

В release notes Flutter 3.47 отдельным блоком идут breaking changes — именно они, а не список новых фич, определяют, сколько часов уйдёт на миграцию. Стоит выписать все пункты, которые касаются виджетов форм, работы с сетью и рендеринга изображений: это как раз то, что чаще всего пересекается с плагинами обмена данными с 1С.

Поднять тестовый контур с копией 1С

Апгрейд проверяют не на синтетических данных, а на тестовом контуре, который бьёт по тем же HTTP- и OData-запросам, что и продакшн. Если приложение — часть B2B-контура с 1С, такой контур обязателен: ошибка синхронизации остатков видна не тестировщику в логе, а кладовщику на складе в момент отгрузки.

Если внутренней команде не хватает часов на такой аудит, разовую правку конфликтов и тестовый прогон делают по тарифу сопровождения — 1С-инженер и сисадмин в связке от 3 800 руб/час, без абонемента и без обязательства продлевать поддержку дальше этой задачи.

Что делать, если ошибка сборки повторяется после каждого обновления пакетов

Если конфликт устранили один раз, а через неделю сборка падает снова — уже на другом пакете, — дело не в конкретной версии Flutter, а в отсутствии дисциплины версионирования. Типичная причина: команда одним коммитом поднимает и Flutter, и десяток pub-пакетов, без lock-файла и без фиксации канала обновлений stable или beta. Разобраться, какой из апдейтов сломал сборку, в таком коммите невозможно.

• ✓Обновить только Flutter SDK, прогнать полный набор тестов и зафиксировать коммит.
• ✓Отдельным шагом обновить pub-пакеты пачками по 3-5, а не все разом.
• ✓После каждой пачки собрать билд под обе платформы, не только под ту, что под рукой.
• ✓Зафиксировать версию через fvm и добавить в CI проверку соответствия версии.

Если приложение уже несколько лет латают точечными патчами и каждый релиз Flutter превращается в расследование на пару дней, дешевле один раз пересобрать проблемные модули заново, чем оплачивать разбор конфликтов ежеквартально. Полная разработка мобильного приложения под актуальный стек стоит от 500 000 руб и снимает вопрос совместимости на несколько крупных релизов Flutter вперёд. Каждый месяц простоя релиза считается не в часах разработки, а в сорванных отгрузках и ручной работе склада, которую никто не планировал.

Как предотвратить проблемы при переходе на новую версию Flutter в проде

• ✓Держать продакшн-релизы на канале stable, апгрейд на beta тестировать отдельно и не в спешке перед сдачей.
• ✓Раскатывать новую сборку поэтапно — на 5-10% пользователей через магазины приложений, смотреть отчёты о падениях первые двое суток.
• ✓Проверять апгрейд на staging-копии 1С с той же структурой данных, но без реальных ФИО и телефонов клиентов.
• ✓Если обновлённые виджеты Material 3 добавили новые поля автозаполнения в формах — свериться, какие персональные данные при этом попадают в лог устройства и в кэш: это требование 152-ФЗ о персональных данных, а не формальность для галочки в чек-листе.

Этот список закрывает большинство сценариев, но не защищает от ситуации, когда апгрейд делают за один вечер перед сдачей — тогда даже подробный чек-лист не успевают пройти полностью.

Мониторинг первых 48 часов после раскатки

После выката новой версии в сторы смотрят не только на крэш-репорты, но и на количество неудачных синхронизаций с 1С в логах бэкенда — рост ошибок или таймаутов именно в эти двое суток чаще указывает на несовместимость мобильного клиента, чем на проблему сервера. Если график ошибок пошёл вверх сразу после раскатки на первые 5-10% пользователей, раскатку останавливают и откатывают версию в сторе, не дожидаясь, пока проблему заметят все.

Часть компаний вместо поддержки отдельного кросс-платформенного стека переносит логику мобильного клиента на 1С:Мобильную платформу — тогда приложение обновляется вместе с релизами конфигурации 1С, и отдельный цикл апгрейдов Flutter отслеживать не нужно.

Сколько стоит поддержка мобильного приложения на актуальной версии Flutter

Цена зависит от масштаба проблемы. Точечный аудит зависимостей и правка сборки после апгрейда — почасовая работа, от 3 800 руб/час. Полная миграция крупного B2B-приложения на актуальный Flutter с переписыванием проблемных модулей — отдельный проект разработки, от 500 000 руб. Точную сумму называем после аудита кода и списка плагинов, актуальные условия — на странице тарифов.

В аудит перед апгрейдом обычно входит список пакетов с версиями и флагами устаревания, прогон сборки под iOS и Android на тестовом контуре, проверка форм и сетевых вызовов, которые обмениваются данными с 1С, и проверка полей с автозаполнением на соответствие 152-ФЗ. Итоговый отчёт передаём внутренней команде вместе с патчами, а не списком рисков без решения.

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

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

Стоит ли сразу обновляться на Flutter 3.47 в рабочем приложении?

Не сразу и не в пятницу перед релизом. Сначала обновите Flutter на тестовой ветке, прогоните сборку под iOS и Android, проверьте плагины интеграции с 1С на конфликты версий и только потом переносите изменения в продакшн-ветку с поэтапным раскатыванием в сторах.

Что делать, если после апгрейда Flutter приложение не проходит проверку в Google Play?

Чаще всего причина — устаревший таргет SDK или deprecated-разрешение в манифесте, которое подсветил апдейт движка. Смотрите лог отклонения магазина построчно, обновите таргет и разрешения по требованиям текущей версии, пересоберите и отправьте повторно с описанием изменений в release notes. Это снимает большинство отказов после апгрейда.

Ломает ли Flutter 3.47 интеграцию мобильного приложения с 1С?

Сама версия ничего не ломает — падают старые плагины синхронизации, которые держали жёсткий пин версий под прежний рендерер. Перед апгрейдом проверьте, какой пакет отвечает за обмен с 1С, и обновите его отдельно, до перехода движка на актуальную версию. Это займёт меньше времени, чем разбирать упавшую сборку в проде.

Сколько стоит перевести мобильное приложение на актуальную версию Flutter?

Точечный аудит зависимостей и правка сборки после апгрейда идёт почасово — от 3 800 руб/час. Если приложение годами латали и конфликты пакетов повторяются каждый релиз, разумнее пересобрать проблемные модули заново — такой проект стартует от 500 000 руб. Точную цифру назовём после короткого аудита кода.

Как понять, что пора менять подрядчика по поддержке Flutter-приложения?

Тревожный сигнал — каждый апдейт пакетов превращается в расследование на несколько дней, а команда не может объяснить, из-за какого плагина упала сборка. Это значит, что зависимости никто не документирует и не тестирует на контуре с 1С перед релизом в прод. Такой процесс стоит формализовать до следующего крупного релиза Flutter.