Phased release w App Store: jak działa 7-dniowe wdrażanie, kiedy je wstrzymać i jak wydać poprawkę (2026)

Phased release w App Store wysyła aktualizację wersji do rosnącej części użytkowników z włączonymi automatycznymi aktualizacjami przez siedem dni: od 1% pierwszego dnia do 100% siódmego. Jeśli codziennie sprawdzasz crashe i e-maile do supportu i wstrzymujesz wdrażanie, gdy tylko coś wygląda niepokojąco, wadliwy build trafi do małej grupy osób, a nie do całej bazy użytkowników. Phased release ma jednak jedno duże ograniczenie: kontroluje tylko automatyczne aktualizacje. Każdy nadal może pobrać nową wersję ręcznie.

Co kontroluje phased release w App Store, a czego nie?

Phased release kontroluje wyłącznie to, którzy użytkownicy z włączonymi automatycznymi aktualizacjami otrzymują aktualizację wersji i kiedy. Nie ukrywa nowej wersji przed ręcznym pobraniem i nie cofa nikogo, kto już ją ma.

Według App Store Connect Help od Apple „aktualizację otrzyma losowa próba użytkowników z włączonymi automatycznymi aktualizacjami na kwalifikujących się urządzeniach, bez żadnego powiadomienia o ich udziale w wydaniu etapowym”. Funkcja działa dla aktualizacji wersji na iOS, macOS i tvOS, więc nie można jej użyć przy pierwszym wydaniu aplikacji. Do jej skonfigurowania potrzebna jest rola Account Holder, Admin lub App Manager. Apple podaje też: „Aplikacje i aktualizacje aplikacji objęte wydaniem etapowym może w dowolnym momencie ręcznie pobrać z App Store każdy”.

Jaki jest harmonogram phased release w App Store?

Według stanu na listopad 2026 harmonogram jest stały: 1%, 2%, 5%, 10%, 20%, 50% i 100% w ciągu siedmiu dni, i nie da się go edytować. Ty decydujesz tylko o tym, kiedy wstrzymać wdrażanie i kiedy przeskoczyć od razu do 100%.

Traktuj każdy dzień jako punkt kontrolny zakończony jedną decyzją: kontynuować czy wstrzymać.

Jak włączyć phased release w App Store Connect?

Phased release włącza się na stronie wersji, w sekcji Phased Release for Automatic Updates, w dowolnym momencie przed opublikowaniem aktualizacji. Nie musisz decydować przed wysłaniem do recenzji.

Apple pozwala na to, gdy wersja ma status Prepare for Submission, Waiting for Review, In Review, Waiting for Export Compliance, Pending Developer Release, Developer Rejected, Rejected lub Metadata Rejected.

1. W sekcji Apps wybierz swoją aplikację, a następnie kliknij na pasku bocznym wersję, którą wysyłasz.
2. Przewiń do Phased Release for Automatic Updates.
3. Zaznacz Release update over a 7-day period using phased release.
4. Kliknij Save. Po zatwierdzeniu status pokaże Ready for Distribution z dopiskiem Phased Release.

Wydaniami etapowymi możesz też zarządzać przez App Store Connect API, co przydaje się, jeśli Twój proces wydawniczy jest już oskryptowany.

Kiedy wstrzymać phased release i jak działa limit 30 dni?

Wstrzymaj wdrażanie, gdy tylko zadziała jeden z wcześniej uzgodnionych wyzwalaczy. Pauzy mogą łącznie trwać do 30 dni, a po wznowieniu wdrażanie jest kontynuowane od dnia, w którym zostało zatrzymane.

Spisz wyzwalacze przed dniem premiery, żeby nikt się o nie nie spierał, gdy użytkownicy trafiają na błąd. Dobre wyzwalacze są konkretne: odsetek sesji bez crashy spada poniżej poziomu bazowego poprzedniej wersji, płatność lub logowanie zawodzi w mierzalnej części prób albo kilku użytkowników zgłasza ten sam błąd.

Aby wstrzymać, otwórz wersję w statusie Ready for Distribution, wybierz Pause Phased Release i kliknij Save. Aby wznowić, wybierz Use Phased Release. Przykład Apple: jeśli wstrzymasz na 10 dni, a potem wznowisz, zostaje Ci 20 dni pauzy. W ramach tego limitu możesz wstrzymywać wdrażanie dowolną liczbę razy. Aby pominąć pozostałe etapy, kliknij Release to All Users w prawym górnym rogu strony wersji.

Jak wygląda phased release, gdy pojawi się błąd?

Gdy pojawi się błąd, wstrzymujesz wdrażanie, naprawiasz go i wydajesz nową wersję, ponownie z włączonym phased release. Użytkownicy, którzy wciąż czekają na automatyczną aktualizację, pozostają w tym czasie na poprzedniej wersji.

Załóżmy, że wersja 3.4 wymienia Twój silnik synchronizacji. Pierwszego dnia dostaje ją 1% użytkowników z automatycznymi aktualizacjami, a Ty dwa razy sprawdzasz narzędzie do raportowania crashy i logi błędów synchronizacji. Trzeciego dnia, przy 5%, pojawia się skupisko błędów synchronizacji na jednej starszej wersji iOS. Od razu wstrzymujesz wdrażanie. Dotkniętych jest znacznie mniej użytkowników, niż gdyby aktualizację dostali wszyscy, a użytkownicy z automatycznymi aktualizacjami, do których jeszcze nie dotarła, zostają na 3.3.

Następnie naprawiasz błąd i wysyłasz 3.4.1 z włączonym phased release. Przetestuj poprawkę w buildzie release, a nie tylko w debug; nasz plan testów buildu release opisuje ten krok. W informacjach o wydaniu 3.4.1 napisz wprost, że synchronizacja została naprawiona; nasze przykłady informacji o wydaniu pokazują, jak to zrobić. Jeśli poprawka jest pilna i masz do niej zaufanie, po zatwierdzeniu użyj Release to All Users zamiast czekać kolejny tydzień.

Jeszcze jedno zabezpieczenie: umieść nowy silnik synchronizacji za flagą po stronie serwera. Pauza zatrzymuje rozprzestrzenianie się aktualizacji, ale flaga pozwala wyłączyć ryzykowny kod osobom, które już zainstalowały 3.4. Oba mechanizmy dobrze się uzupełniają.

Na co trafili inni deweloperzy, wstrzymując phased release?

W publicznych wątkach powtarza się ten sam schemat: deweloperzy wstrzymują wadliwą wersję, a potem nie wiedzą, co kolejny phased release oznacza dla użytkowników, którzy już ją dostali. Dokumentacja Apple tego nie wyjaśnia, więc planuj tak, jakby poprawka wymagała osobnego wdrażania.

• Deweloper na Apple Developer Forums napisał, że „zauważył crash, wstrzymał wdrażanie aktualizacji, załatał aplikację, wgrał ją i rozpoczął kolejne wdrażanie etapowe”, gdy na wadliwym buildzie było mniej niż 10% użytkowników. Pytał, czy nowe wdrażanie trafi do tych samych użytkowników. Wątek nigdy nie doczekał się oficjalnej odpowiedzi; w jednej z odpowiedzi stwierdzono, że użytkownicy 8.0 „powinni dostać informację o dostępnej aktualizacji 8.1, gdy tylko się ukaże”.
• W innym wątku na forum deweloper napisał, że z powodu krytycznego błędu „zatrzymał się na 1%” przy wersji 15.0.1 i chciał również stopniowo wydać 15.0.2, licząc, że 15.0.1 zostanie „praktycznie pominięta przez większość użytkowników”. We wcześniejszej odpowiedzi w tym wątku zasugerowano poproszenie o przyspieszoną recenzję (expedited review), gdy wadliwa wersja jest wstrzymana, i ewentualne wycofanie aplikacji ze sprzedaży, „żeby żaden nowy użytkownik nie pobrał zepsutej wersji”. Zanim to zrobisz, pamiętaj o zasadzie dotyczącej wycofania ze sprzedaży z ramki powyżej.
• Zespół narzędzi wydawniczych stojący za notatkami store-quirks od Tramline dokumentuje, że rozpoczęcie nowego wydania „po prostu anuluje bieżące wdrażanie”, a starsza wersja przechodzi w status REPLACED_WITH_NEW_VERSION, z phased release oznaczonym jako COMPLETE. Te same notatki podają, że pauza „nic nie zmieni w przypadku użytkowników, którzy już otrzymali aktualizację”.

We wszystkich trzech przypadkach pauza dawała jedynie czas. Poprawką zawsze była nowa wersja i nikt nie mógł liczyć na to, że ta sama grupa użytkowników zostanie zaktualizowana jako pierwsza. Dlatego flagi po stronie serwera i gałąź hotfix, którą da się szybko wydać, są ważniejsze niż przycisk pauzy.

Jak wypada na tym tle stopniowe wdrażanie w Google Play?

Stopniowe wdrażanie (staged rollout) w Google Play opiera się na odsetku, który sam wybierasz i ręcznie zwiększasz. Po zatrzymaniu wznowienie trafia do tej samej grupy użytkowników. Planuj wdrażanie w obu sklepach osobno.

Według Play Console Help „odsetek stopniowego wdrażania aplikacji nie zwiększy się automatycznie”, a stopniowego wdrażania „można używać tylko w przypadku aktualizacji aplikacji, a nie przy pierwszej publikacji aplikacji”. Po zatrzymaniu użytkownicy, którzy już otrzymali wersję, zostają na niej, a Google zaleca wydanie nowej wersji z poprawionym pakietem zamiast wznawiania wadliwej. Wdrażanie produkcyjne można ograniczyć do wybranych krajów, ale po jego rozpoczęciu nie da się usuwać krajów. Jeśli Twoja następna aktualizacja na Androida musi też spełnić nowy docelowy SDK, zajrzyj do naszego poradnika o docelowym poziomie API 36 w Google Play.

Co sprawdzić przed rozpoczęciem phased release?

Przed startem wdrażania upewnij się, że phased release jest zapisany w wersji, poziomy bazowe i wyzwalacze pauzy są spisane, a poprawkę da się szybko wydać. Skorzystaj z tej listy kontrolnej:

• Phased release zaznaczony i zapisany na stronie wersji
• Dashboardy raportowania crashy i błędów backendu dodane do zakładek, z poziomami bazowymi z poprzedniej wersji
• Spisane wyzwalacze pauzy, uzgodnione przez wszystkich, którzy mogą nacisnąć przycisk
• Ryzykowne funkcje za flagami po stronie serwera
• Wyznaczona osoba sprawdzająca metryki każdego z 7 dni
• Gotowa gałąź hotfix oraz nasza lista kontrolna wysyłki do App Store dla kolejnego buildu
• Zmiany w karcie aplikacji wstrzymane, dopóki wdrażanie nie obejmie wszystkich

Jeśli wolisz przekazać samo wydanie, nasza usługa wysyłki do App Store obejmuje konfigurację App Store Connect i Play Console, przygotowanie do recenzji oraz wydania w obu sklepach za $599 (opłaty za konta deweloperskie są osobne). Jeśli chcesz drugiej opinii na temat ryzykownej aktualizacji, napisz na yagyeshsrbobde@gmail.com, podając swoją aplikację i to, co się zmienia.