Поетапний реліз 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 радить випустити нову версію з виправленим бандлом замість відновлення зламаної. Розгортання в production можна обмежити певними країнами, але після початку вилучити країни вже не можна. Якщо ваше наступне оновлення для Android також має відповідати новому target SDK, перегляньте наш посібник про target API level 36 у Google Play.

Що перевірити перед запуском поетапного релізу?

Перед початком розгортання переконайтеся, що поетапний реліз збережено для версії, базові показники та тригери паузи записано, а виправлення можна швидко випустити. Скористайтеся цим чеклистом:

• Поетапний реліз вибрано і збережено на сторінці версії
• Дашборди краш-репортингу та помилок бекенду додано в закладки, з базовими показниками попередньої версії
• Письмові тригери паузи узгоджено з усіма, хто може натиснути кнопку
• Ризиковані функції сховано за серверними прапорцями
• Визначено конкретну людину, яка перевіряє метрики в кожен із 7 днів
• Гілка для хотфіксу готова, а для наступного білду є наш чеклист відправлення в App Store
• Зміни сторінки в сторі відкладено, доки розгортання не охопить усіх

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