Что происходит после нажатия кнопки «Загрузить» в Google Play и App Store

У вас зелёная сборка. Все тесты пройдены. Релизная ветка чиста. Кто-то в команде говорит: «Окей, просто загрузи в магазин и жди ревью». Если вы когда-нибудь проходили через реальный мобильный релиз, вы знаете, что за этой фразой скрывается много сложностей.

Загрузка в Google Play Console или App Store Connect — это не просто отправка файла. Это многоэтапный процесс, включающий метаданные, скриншоты, списки изменений, очереди ревью и вполне реальную возможность отклонения. И если ваш пайплайн считает загрузку финальным шагом, вы рискуете получить ночной кошмар, когда ревью вернётся с отказом.

Загрузка — это больше, чем передача файла

Когда вы загружаете Android App Bundle (AAB) или iOS IPA-файл, магазин ожидает не только бинарник. Вам также нужно предоставить:

  • Название приложения и описание для новой версии
  • Что изменилось в этом релизе (список изменений)
  • Скриншоты для нескольких размеров устройств
  • Обновления категории приложения и рейтинга контента
  • Какие страны или регионы получат обновление

И Google Play Console, и App Store Connect предоставляют API, которые позволяют вашему пайплайну обрабатывать всё это программно. Ваша CI/CD-система может отправить артефакт, заполнить метаданные, прикрепить правильные скриншоты и установить трек релиза. Для Android вы можете загрузить на внутреннее тестирование, закрытое тестирование или открытое тестирование, прежде чем думать о продакшене. Для iOS вы сначала загружаете в TestFlight.

Следующая диаграмма последовательности иллюстрирует типичный поток от пайплайна до релиза:

Например, используя fastlane supply на Android, вы можете загрузить бинарник, установить список изменений и прикрепить скриншоты одной командой:

# Upload AAB to Google Play internal test track
fastlane supply \
  --aab ./app/build/outputs/bundle/release/app-release.aab \
  --track internal \
  --metadata_path ./fastlane/metadata/android \
  --json_key ./path/to/service-account-key.json \
  --package_name com.example.myapp

# The metadata folder should contain:
#   metadata/android/en-US/title.txt
#   metadata/android/en-US/short_description.txt
#   metadata/android/en-US/full_description.txt
#   metadata/android/en-US/changelogs/1.txt (version code as filename)
#   metadata/android/en-US/images/phoneScreenshots/
sequenceDiagram participant CI as CI/CD Pipeline participant Store as Store API participant Review as Review Queue participant Track as Release Track CI->>Store: Upload binary + metadata Store->>Review: Submit for review Review-->>Store: Approval or rejection alt Rejected Store-->>CI: Rejection notice CI->>Store: Fix and re-upload else Approved Store->>Track: Set release track (internal/closed/open/production) Track->>Track: Staged rollout or full release end

Ключевой вывод здесь: шаг загрузки не должен быть концом вашего пайплайна. Это должно быть началом контролируемого процесса релиза.

Почему не стоит загружать напрямую в продакшен

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

Apple проверяет каждое приложение и обновление на соответствие правилам App Store Review Guidelines. Google также проверяет заявки, хотя процесс обычно быстрее и менее строгий. Если ваш пайплайн загружает напрямую в продакшен и ревью находит проблему, вам придётся исправлять, перезагружать и снова ждать. Это может отложить ваш релиз на дни.

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

Метаданные и скриншоты должны соответствовать сборке

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

Ваш пайплайн может помочь здесь. Храните скриншоты и метаданные для каждой версии вместе с вашим кодом. Когда вы запускаете релиз, пайплайн выбирает правильные ресурсы на основе номера версии или тега релиза. Это гарантирует, что то, что вы загружаете в магазин, соответствует тому, что на самом деле содержит бинарник.

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

Планируйте время на ревью в вашем графике релизов

Ревью в мобильных магазинах занимает время. Apple обычно требуется от 24 до 48 часов для обновлений приложений и больше для новых приложений. Google обычно быстрее, иногда всего несколько часов, но всегда есть очередь. Если у вас фиксированная дата релиза, вам нужно загрузить достаточно рано, чтобы учесть время ревью плюс возможные повторные отправки.

Не рассчитывайте, что первое ревью пройдёт успешно. Даже опытные команды получают отказы по таким причинам, как:

  • Запрос разрешений без объяснения причин
  • Использование приватных API
  • Неполные или некорректные метаданные
  • Элементы интерфейса, не соответствующие скриншотам
  • Нарушение специфических политик магазина (например, правила Apple о покупках внутри приложения)

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

Что происходит после прохождения ревью

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

На Android вы можете использовать поэтапное развёртывание, чтобы выпустить обновление для процента пользователей, например 10% или 25%. На iOS вы можете использовать поэтапный релиз, который постепенно распространяет обновление в течение нескольких дней. Это позволяет вам отслеживать частоту сбоев, отзывы пользователей и ключевые метрики, прежде чем расширять охват на всех.

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

Практический чек-лист для загрузки в магазин

  • Загружайте на внутренний или закрытый тестовый трек перед отправкой на публичное ревью
  • Храните метаданные и скриншоты в версионированных директориях вместе с вашим кодом
  • Используйте API магазинов для автоматизации отправки метаданных, а не только загрузки бинарника
  • Включайте список изменений, который точно описывает, что изменилось в этой версии
  • Планируйте как минимум 48 часов буферного времени до целевой даты релиза
  • Настройте поэтапное развёртывание или поэтапный релиз по умолчанию, а не полный релиз
  • Имейте план отката: знайте, как отозвать публикацию или вернуться к предыдущей версии

Вывод

Загрузка в мобильный магазин — это не финишная черта. Это начало процесса, который включает ревью, возможное отклонение, поэтапное развёртывание и мониторинг. Если ваш пайплайн считает загрузку финальным шагом, вы будете постоянно удивляться отказам и задержкам релизов. Встройте процесс ревью в дизайн вашего пайплайна, сначала загружайте на тестовые треки и всегда оставляйте место для второй попытки. Именно так вы превратите мобильные релизы из стрессового события в рутинную операцию.