Ошибка в конфигурации build.gradle или неправильный подбор версии Xcode часто превращают финальный этап релиза Flutter-приложения в многодневный дебаг. Подготовка к публикации — это не просто команда build, а синхронизация нативных требований iOS и Android с кроссплатформенным кодом.
Оптимизация размера сборки и обфускация
Стандартная сборка Flutter содержит избыточные отладочные символы. Для минимизации размера APK/AAB необходимо использовать флаг --split-debug-info и применять обфускацию кода через команду flutter build apk --obfuscate. Это затрудняет реверс-инжиниринг бизнес-логики, хотя и усложняет чтение стектрейсов в консоли ошибок.
Кейс: При переходе с одного общего APK на Android App Bundle (AAB) размер загружаемого файла для конечного пользователя может снизиться существенно, так как Google Play генерирует оптимизированные APK под конкретное устройство. Ошибка новичков — пытаться загружать APK в консоль, когда стандарт требует AAB.
Микро-вывод: Всегда собирайте AAB для Android и используйте обфускацию, если в приложении есть проприетарные алгоритмы.
Конфигурация App Store и требования Apple
Основной «затык» при релизе на iOS — работа с сертификатами и профилями подготовки (Provisioning Profiles). Flutter-разработчик должен четко разграничить Debug и Release схемы в Xcode, иначе приложение вылетит при первом запуске из-за отсутствия прав доступа к API или неправильного подписывания.
Пример: Попытка опубликовать приложение с включенным режимом отладки или без заполненного файла Info.plist (особенно в части разрешений на камеру или микрофон) ведет к мгновенному отклонению (Reject) в App Store Connect. Описание разрешений должно быть предельно конкретным, иначе модератор отклонит билд.
Микро-вывод: Проверяйте соответствие всех ключей в Info.plist реальному функционалу приложения до отправки на проверку.
Управление версиями и зависимостями перед релизом
Несоответствие версии в pubspec.yaml и версии в нативных файлах (build.gradle и project.pbxproj) приводит к ошибкам обновления приложения у пользователей. Важно соблюдать семантическое версионирование: версия до плюса — это версия приложения, после плюса — номер сборки (build number).
Кейс: Если вы обновили пакеты через flutter pub upgrade непосредственно перед релизом, вы рискуете получить конфликт версий в Gradle, что заблокирует сборку. Правильный подход — зафиксировать версии зависимостей за неделю до релиза и проводить только регрессионное тестирование.
Микро-вывод: Замораживайте зависимости и синхронизируйте версию сборки во всех трех конфигурационных файлах (Flutter, Android, iOS).
Автоматизация через CI/CD пайплайны
Ручная сборка на локальной машине — главный риск релиза: «у меня работает, а в сторе нет». Использование Fastlane или GitHub Actions позволяет автоматизировать подпись приложения и загрузку в TestFlight или Google Play Console, исключая человеческий фактор при выборе версии SDK.
Пример: Настройка пайплайна, который автоматически прогоняет unit-тесты и собирает билд при слиянии ветки в main, сокращает время выкатки обновления с нескольких часов до 15-20 минут. Это позволяет избежать ситуации, когда в релиз попал незакрытый TODO-комментарий или тестовый API-ключ.
Микро-вывод: Для проектов с циклом обновления чаще раза в месяц внедрение Fastlane обязательно для сохранения ментального здоровья команды.
Вывод
Подготовка к релизу на Flutter требует смещения фокуса с Dart на нативные настройки платформ. Мой опыт показывает: большинство задержек публикации случаются не из-за багов в коде, а из-за некорректных метаданных и сертификатов. Рекомендую начинать процесс подготовки за 5-7 дней до даты релиза, использовать AAB для Android, строго проверять Info.plist для iOS и автоматизировать деплой через Fastlane. Избегайте обновления зависимостей в день релиза — это гарантированный способ сорвать сроки.