Поэтапный релиз в App Store: 7-дневная раскатка, пауза и выпуск исправления (2026)

Поэтапный релиз в App Store (phased release) отправляет обновление версии растущей доле пользователей с включенными автообновлениями в течение семи дней: с 1% в первый день до 100% на седьмой. Если каждый день проверять краши и письма в поддержку и ставить паузу, как только что-то пошло не так, неудачная сборка дойдет до небольшой группы людей, а не до всей вашей аудитории. Но у поэтапного релиза есть одно серьезное ограничение: он управляет только автоматическими обновлениями. Любой пользователь по-прежнему может скачать новую версию вручную.

Что контролирует поэтапный релиз в App Store, а что нет?

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

Согласно справке App Store Connect от Apple, «обновление получит случайная выборка пользователей с включенными автообновлениями на подходящих устройствах, без какого-либо уведомления об их участии в поэтапном релизе». Функция работает для обновлений версий под iOS, macOS и tvOS, поэтому для первого релиза приложения ее использовать нельзя. Для настройки нужна роль Account Holder, Admin или App Manager. Apple также указывает: «Приложения и обновления приложений в поэтапном релизе может вручную скачать из App Store кто угодно в любое время».

Какой график у поэтапного релиза в App Store?

По состоянию на ноябрь 2026 года график фиксирован: 1%, 2%, 5%, 10%, 20%, 50% и 100% за семь дней, и изменить его нельзя. Вы управляете только тем, когда поставить паузу и когда сразу перейти к 100%.

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

Как включить поэтапный релиз в App Store Connect?

Поэтапный релиз включается на странице версии, в разделе Phased Release for Automatic Updates, в любой момент до того, как обновление станет доступно. Решать заранее, до отправки на ревью, не обязательно.

Apple разрешает включить его, пока версия находится в статусе Prepare for Submission, Waiting for Review, In Review, Waiting for Export Compliance, Pending Developer Release, Developer Rejected, Rejected или Metadata Rejected.

1. В разделе Apps выберите приложение, затем на боковой панели нажмите на версию, которую отправляете.
2. Прокрутите до блока Phased Release for Automatic Updates.
3. Выберите Release update over a 7-day period using phased release.
4. Нажмите Save. После одобрения статус будет Ready for Distribution с пометкой Phased Release рядом.

Управлять поэтапными релизами можно и через App Store Connect API — это удобно, если ваш процесс релиза уже автоматизирован скриптами.

Когда ставить поэтапный релиз на паузу и как работает лимит в 30 дней?

Ставьте паузу, как только срабатывает один из заранее согласованных триггеров. Паузы суммарно могут длиться до 30 дней, а после возобновления раскатка продолжается с того дня, на котором остановилась.

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

Чтобы поставить паузу, откройте версию в статусе Ready for Distribution, выберите Pause Phased Release и нажмите Save. Чтобы возобновить, выберите Use Phased Release. Пример Apple: если поставить паузу на 10 дней, а затем возобновить, у вас останется 20 дней паузы. В пределах этого лимита ставить паузу можно сколько угодно раз. Чтобы пропустить оставшиеся этапы, нажмите Release to All Users в правом верхнем углу страницы версии.

Как выглядит поэтапный релиз, когда обнаруживается баг?

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

Допустим, версия 3.4 заменяет движок синхронизации. В первый день ее получает 1% пользователей с автообновлениями, и вы дважды проверяете краш-репортер и логи ошибок синхронизации. На третий день, при 5%, появляется кластер сбоев синхронизации на одной старой версии iOS. Вы сразу ставите паузу. Затронуто гораздо меньше пользователей, чем если бы обновление получили все, а пользователи с автообновлениями, до которых раскатка еще не дошла, остаются на 3.3.

Дальше исправьте баг и отправьте 3.4.1 с включенным поэтапным релизом. Проверьте исправление в релизной сборке, а не только в debug; этот шаг описан в нашем плане тестирования релизной сборки. Прямо напишите в примечаниях к выпуску 3.4.1, что синхронизация исправлена; как это сделать, показывают наши примеры примечаний к выпуску. Если исправление срочное и вы в нем уверены, после одобрения нажмите Release to All Users, а не ждите еще неделю.

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

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

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

• Разработчик на Apple Developer Forums рассказал, что они «заметили краш, поставили раскатку обновления на паузу, пропатчили приложение, загрузили его и запустили новую поэтапную раскатку», когда на неудачной сборке было меньше 10% пользователей. Они спрашивали, получат ли новую раскатку те же пользователи. Официального ответа в треде так и не появилось; в одном из ответов говорилось, что пользователи 8.0 «должны получить уведомление о доступном обновлении 8.1 сразу после его выхода».
• В другом треде на форуме разработчик написал, что «остановился на 1%» с версией 15.0.1 из-за критического бага и хотел так же поэтапно выпустить 15.0.2, надеясь, что 15.0.1 «фактически пропустит большинство пользователей». В более раннем ответе в этом треде предлагалось запросить ускоренное ревью, пока версия с багом на паузе, и, возможно, снять приложение с продажи, «чтобы новые пользователи не скачали испорченную версию». Прежде чем так делать, вспомните правило о снятии с продажи из блока выше.
• Команда разработчиков инструментов для релизов, ведущая заметки Tramline о причудах магазинов, документирует, что запуск нового релиза «просто отменит текущую раскатку», а старая версия переходит в статус REPLACED_WITH_NEW_VERSION, и ее поэтапный релиз помечается как COMPLETE. В тех же заметках сказано, что пауза «ничего не сможет сделать с пользователями, которые уже получили обновление».

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

Чем отличается поэтапное развертывание в Google Play?

Поэтапное развертывание (staged rollout) в Google Play использует процент, который вы выбираете и повышаете вручную. После остановки и возобновления обновление получает тот же набор пользователей. Планируйте раскатки в двух магазинах отдельно.

Согласно справке Play Console, «процент поэтапного развертывания вашего приложения не будет увеличиваться автоматически», а поэтапное развертывание «можно использовать только для обновлений приложения, а не при первой публикации». После остановки пользователи, уже получившие версию, остаются на ней, и Google советует выпустить новую версию с исправленным бандлом, а не возобновлять сломанную. Развертывание в рабочей версии можно ограничить определенными странами, но после его начала удалить страны уже нельзя. Если следующее обновление под Android также должно соответствовать новому target SDK, читайте наше руководство по target API level 36 в Google Play.

Что проверить перед запуском поэтапного релиза?

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

• Поэтапный релиз выбран и сохранен на странице версии
• Дашборды краш-репортинга и ошибок бэкенда добавлены в закладки, есть базовые показатели предыдущей версии
• Письменные триггеры паузы согласованы со всеми, кто может нажать кнопку
• Рискованные функции спрятаны за серверными флагами
• Назначен ответственный, который проверяет метрики в каждый из 7 дней
• Готова ветка для хотфиксов, а для последующей сборки — наш чек-лист отправки в App Store
• Изменения страницы приложения в магазине отложены до завершения раскатки на всех

Если вы предпочитаете передать сам релиз, наша услуга по публикации в App Store включает настройку App Store Connect и Play Console, подготовку к ревью и релизы в обоих магазинах за $599 (взносы за аккаунты разработчика оплачиваются отдельно). Чтобы получить второе мнение о рискованном обновлении, напишите на yagyeshsrbobde@gmail.com, указав приложение и что меняется.