App Store Phased Release: 7-Tage-Rollout, wann Sie pausieren und wie Sie einen Fix ausliefern (2026)

Ein App Store Phased Release liefert ein Versionsupdate über sieben Tage an einen wachsenden Anteil der Nutzer mit aktivierten automatischen Updates aus – beginnend mit 1 % am ersten Tag bis zu 100 % am siebten Tag. Wenn Sie täglich Abstürze und Support-E-Mails prüfen und pausieren, sobald etwas auffällig ist, erreicht ein fehlerhafter Build nur eine kleine Gruppe statt Ihrer gesamten Nutzerbasis. Der Phased Release hat allerdings eine große Einschränkung: Er steuert nur automatische Updates. Jeder kann die neue Version weiterhin manuell herunterladen.

Was steuert der App Store Phased Release – und was nicht?

Der Phased Release steuert nur, welche Nutzer mit aktivierten automatischen Updates Ihr Versionsupdate erhalten und wann. Er verbirgt die neue Version nicht vor manuellen Downloads und setzt niemanden zurück, der sie bereits installiert hat.

Laut der App Store Connect Hilfe von Apple erhält „eine zufällige Auswahl von Nutzern mit aktivierten automatischen Updates auf berechtigten Geräten das Update, ohne über ihre Teilnahme am Phased Release benachrichtigt zu werden“. Das funktioniert für Versionsupdates unter iOS, macOS und tvOS – für die erste Veröffentlichung einer App können Sie es also nicht nutzen. Für die Einrichtung brauchen Sie die Rolle Account Holder, Admin oder App Manager. Apple schreibt außerdem: „Apps und App-Updates im Phased Release können jederzeit von jedem manuell aus dem App Store heruntergeladen werden.“

Wie sieht der Zeitplan des App Store Phased Release aus?

Stand November 2026 ist der Zeitplan fest auf 1 %, 2 %, 5 %, 10 %, 20 %, 50 % und 100 % über sieben Tage eingestellt und lässt sich nicht ändern. Sie entscheiden nur, wann Sie pausieren und wann Sie direkt auf 100 % springen.

Behandeln Sie jeden Tag als Checkpoint, der mit einer einzigen Entscheidung endet: weitermachen oder pausieren.

Wie aktivieren Sie den Phased Release in App Store Connect?

Der Phased Release wird auf der Versionsseite unter Phased Release for Automatic Updates aktiviert, und zwar jederzeit, bevor das Update live geht. Sie müssen sich nicht schon vor dem Einreichen entscheiden.

Apple erlaubt das, solange die Version den Status Prepare for Submission, Waiting for Review, In Review, Waiting for Export Compliance, Pending Developer Release, Developer Rejected, Rejected oder Metadata Rejected hat.

1. Wählen Sie unter Apps Ihre App aus und klicken Sie dann in der Seitenleiste auf die Version, die Sie einreichen.
2. Scrollen Sie zu Phased Release for Automatic Updates.
3. Wählen Sie Release update over a 7-day period using phased release.
4. Klicken Sie auf Save. Nach der Freigabe zeigt der Status Ready for Distribution mit dem Hinweis Phased Release daneben.

Phased Releases lassen sich auch über die App Store Connect API verwalten – praktisch, wenn Ihre Release-Pipeline bereits automatisiert ist.

Wann sollten Sie einen Phased Release pausieren, und wie funktioniert das 30-Tage-Limit?

Pausieren Sie, sobald einer Ihrer vorab vereinbarten Auslöser greift. Pausen können sich auf insgesamt 30 Tage summieren, und beim Fortsetzen läuft der Rollout ab dem Tag weiter, an dem er angehalten wurde.

Legen Sie Ihre Auslöser vor dem Launch-Tag schriftlich fest, damit niemand darüber diskutiert, während Nutzer schon auf den Bug stoßen. Gute Auslöser sind konkret: Die absturzfreien Sitzungen fallen unter den Basiswert der Vorgängerversion, Checkout oder Login schlagen bei einem messbaren Anteil der Versuche fehl, oder mehrere Nutzer melden denselben Bug.

Zum Pausieren öffnen Sie die Version mit Status Ready for Distribution, wählen Pause Phased Release und klicken auf Save. Zum Fortsetzen wählen Sie Use Phased Release. Apples Beispiel: Wenn Sie 10 Tage pausieren und dann fortsetzen, bleiben Ihnen noch 20 Tage Pause. Innerhalb dieses Gesamtrahmens können Sie beliebig oft pausieren. Um die restlichen Phasen zu überspringen, klicken Sie oben rechts auf der Versionsseite auf Release to All Users.

Wie sieht ein Phased Release aus, wenn ein Bug auftaucht?

Taucht ein Bug auf, pausieren Sie, beheben ihn und liefern eine neue Version wieder mit aktiviertem Phased Release aus. Nutzer, die noch auf das automatische Update warten, bleiben in der Zwischenzeit auf der Vorgängerversion.

Angenommen, Version 3.4 ersetzt Ihre Sync-Engine. Am ersten Tag erhalten 1 % der Nutzer mit automatischen Updates die Version, und Sie prüfen zweimal Ihren Crash-Reporter und die Sync-Fehlerlogs. Am dritten Tag, bei 5 %, zeigt sich eine Häufung von Sync-Fehlern auf einer älteren iOS-Version. Sie pausieren sofort. Es sind weit weniger Nutzer betroffen, als wenn alle das Update erhalten hätten, und die noch nicht erreichten Nutzer mit automatischen Updates bleiben auf 3.3.

Als Nächstes beheben Sie den Bug und reichen 3.4.1 mit aktiviertem Phased Release ein. Testen Sie den Fix in einem Release-Build, nicht nur im Debug-Modus; unser Testplan für Release-Builds deckt diesen Schritt ab. Schreiben Sie in den Release Notes zu 3.4.1 klar, dass der Sync behoben ist; wie das geht, zeigen unsere Beispiele für Release Notes. Ist der Fix dringend und sind Sie sich sicher, nutzen Sie nach der Freigabe Release to All Users, statt eine weitere Woche zu warten.

Noch eine Absicherung: Stellen Sie die neue Sync-Engine hinter ein serverseitiges Flag. Eine Pause verhindert, dass sich das Update weiter verbreitet, aber mit einem Flag können Sie den riskanten Code für alle abschalten, die 3.4 bereits installiert haben. Beides ergänzt sich gut.

Welche Erfahrungen haben andere Entwickler beim Pausieren eines Phased Release gemacht?

Öffentliche Threads zeigen immer dasselbe Muster: Entwickler pausieren eine fehlerhafte Version und wissen dann nicht genau, was ein nachfolgender Phased Release für Nutzer bedeutet, die die fehlerhafte Version bereits haben. Apples Dokumentation beantwortet das nicht – planen Sie also so, als bräuchte der Fix einen eigenen Rollout.

• Ein Entwickler berichtete in den Apple Developer Forums, er habe „einen Absturz bemerkt, den Rollout des Updates pausiert, die App gepatcht, hochgeladen und einen weiteren Phased Rollout gestartet“, als weniger als 10 % der Nutzer den fehlerhaften Build hatten. Er fragte, ob dieselben Nutzer den neuen Rollout erhalten würden. Eine offizielle Antwort kam nie; eine Antwort meinte, Nutzer von 8.0 „sollten einen Hinweis auf das verfügbare Update 8.1 bekommen, sobald es erscheint“.
• In einem anderen Forenthread schrieb ein Entwickler, er habe Version 15.0.1 wegen eines kritischen Bugs „bei 1 % gestoppt“ und wolle auch 15.0.2 gestaffelt ausliefern, in der Hoffnung, 15.0.1 werde „für die Mehrheit der Nutzer praktisch übersprungen“. Eine frühere Antwort in diesem Thread schlug vor, ein Expedited Review zu beantragen, solange die fehlerhafte Version pausiert ist, und die App eventuell aus dem Verkauf zu nehmen, „damit keine neuen Nutzer die kaputte Version laden“. Bevor Sie das tun, denken Sie an die Regel zur Entfernung aus dem Verkauf im Hinweis oben.
• Das Release-Tooling-Team hinter den Store-Quirks-Notizen von Tramline dokumentiert, dass der Start eines neuen Releases „den bestehenden Rollout einfach abbricht“; die ältere Version wechselt zu REPLACED_WITH_NEW_VERSION, und ihr Phased Release wird als COMPLETE markiert. Laut denselben Notizen kann eine Pause „nichts an den Nutzern ändern, die das Update bereits erhalten haben“.

In allen drei Fällen verschaffte die Pause nur Zeit. Die Lösung war immer eine neue Version, und niemand konnte sich darauf verlassen, dass dieselbe Kohorte zuerst aktualisiert wird. Deshalb sind serverseitige Flags und ein schnell auslieferbarer Hotfix-Branch wichtiger als der Pause-Button.

Wie schneidet der gestaffelte Rollout bei Google Play im Vergleich ab?

Der gestaffelte Rollout (Staged Rollout) bei Google Play nutzt einen Prozentsatz, den Sie selbst wählen und manuell erhöhen. Nach einem Stopp erreicht das Fortsetzen dieselbe Nutzergruppe. Planen Sie die Rollouts beider Stores getrennt.

Laut der Play Console Hilfe „erhöht sich der Prozentsatz des gestaffelten Rollouts Ihrer App nicht automatisch“, und gestaffelte Rollouts „können nur für App-Updates verwendet werden, nicht bei der ersten Veröffentlichung einer App“. Nach einem Stopp bleiben Nutzer, die die Version bereits erhalten haben, darauf, und Google empfiehlt, eine neue Version mit korrigiertem Bundle zu veröffentlichen, statt eine fehlerhafte fortzusetzen. Produktions-Rollouts lassen sich auf bestimmte Länder beschränken, aber sobald ein Rollout begonnen hat, können Sie keine Länder mehr entfernen. Wenn Ihr nächstes Android-Update auch das neue Ziel-SDK erfüllen muss, lesen Sie unseren Leitfaden zu Target API Level 36 bei Google Play.

Was sollten Sie vor dem Start eines Phased Release prüfen?

Stellen Sie vor Beginn des Rollouts sicher, dass der Phased Release auf der Version gespeichert ist, Ihre Basiswerte und Pause-Auslöser schriftlich festgehalten sind und ein Fix schnell ausgeliefert werden kann. Nutzen Sie diese Checkliste:

• Phased Release auf der Versionsseite ausgewählt und gespeichert
• Dashboards für Crash-Reporting und Backend-Fehler als Lesezeichen gespeichert, mit Basiswerten der Vorgängerversion
• Schriftlich festgelegte Pause-Auslöser, abgestimmt mit allen, die den Button drücken dürfen
• Riskante Features hinter serverseitigen Flags
• Eine namentlich benannte Person, die an jedem der 7 Tage die Kennzahlen prüft
• Ein vorbereiteter Hotfix-Branch, dazu unsere App Store Checkliste für die Einreichung für den Folge-Build
• Änderungen am Store-Eintrag zurückhalten, bis der Rollout alle erreicht hat

Wenn Sie das Release lieber abgeben möchten: Unser Service für die App Store Einreichung umfasst die Einrichtung von App Store Connect und Play Console, die Vorbereitung auf das Review und Releases in beiden Stores für $599 (Gebühren für Entwicklerkonten kommen hinzu). Für eine zweite Meinung zu einem riskanten Update schreiben Sie an yagyeshsrbobde@gmail.com – mit Ihrer App und dem, was sich ändert.