App-Updates schrittweise ausrollen: Phased Release & Co.
Kurz gesagt: Beide App-Stores erlauben es, ein Update zunächst nur einem Teil der Nutzer auszuliefern: Apple verteilt es per Phased Release automatisch über sieben Tage, bei Google Play legen Sie den Prozentsatz der gestaffelten Einführung selbst fest und erhöhen ihn von Hand. Taucht ein Fehler auf, pausieren beziehungsweise stoppen Sie die Verteilung, während Sie eine korrigierte Version vorbereiten. Feature-Flags ergänzen das, weil sie einzelne Funktionen ohne neues Update ein- und ausschalten.
Warum nicht einfach an alle?
Jedes Update ist eine kleine Wette. Selbst gut getestete Versionen treffen im echten Einsatz auf Geräte, Systemversionen und Nutzungsweisen, die im Test nicht vorkamen. Geht ein Update sofort an alle, trifft ein Fehler im Login oder im Bestellablauf auch sofort alle – und ein bereits installiertes Update lässt sich nicht mehr von den Geräten holen.
Eine gestaffelte Veröffentlichung verkleinert dieses Risiko: Ein paar Prozent der Nutzer erhalten die neue Version, Sie beobachten Absturzraten und Rückmeldungen, und erst wenn alles ruhig bleibt, geht das Update an den Rest. Für eine kleine Firma, deren App Termine, Bestellungen oder Kundenkonten trägt, ist das eine einfache Versicherung ohne Zusatzkosten.
Wichtig vorab: Beide Verfahren gelten nur für Updates. Die allererste Veröffentlichung einer App erreicht sofort alle, die sie herunterladen. Testgruppen vor dem Release – etwa über TestFlight oder die Testtracks der Play Console – sind ein eigenes Thema und ersetzen die gestaffelte Einführung nicht, weil dort nur ausgewählte Tester mitmachen.
Apple: Phased Release über sieben Tage
So läuft es ab
Laut App-Store-Connect-Hilfe (abgerufen November 2026) aktivieren Sie die Option beim Einreichen eines Updates im Abschnitt „Phased Release for Automatic Updates“. Nach der Freigabe verteilt Apple das Update über sieben Tage an eine zufällige Auswahl von Nutzern mit aktivierten automatischen Updates, die davon nichts erfahren. Die Anteile steigen nach festem Plan:
| Tag | Anteil der Nutzer |
|---|---|
| 1 | 1 % |
| 2 | 2 % |
| 3 | 5 % |
| 4 | 10 % |
| 5 | 20 % |
| 6 | 50 % |
| 7 | 100 % |
Was Sie wissen sollten
- Manuelle Downloads laufen trotzdem: Jeder kann die neue Version jederzeit von Hand aus dem App Store laden. Die Staffelung betrifft nur automatische Updates. Wer die App neu installiert, bekommt ebenfalls die aktuelle Version.
- Pausieren ist möglich: Sie können die Verteilung insgesamt bis zu 30 Tage pausieren, beliebig oft. Nach dem Fortsetzen geht es an dem Tag weiter, an dem Sie angehalten haben.
- Sofort an alle: Läuft alles glatt, können Sie mit „Release to All Users“ jederzeit abkürzen.
- Zurücknehmen geht nicht: Eine Pause stoppt die weitere Verteilung, holt die Version aber nicht von Geräten zurück. Die Lösung bei einem Fehler ist eine korrigierte neue Version.
Laut Apple braucht es dafür die Rolle Account Holder, Admin oder App Manager. Wenn ein Dienstleister Ihre App veröffentlicht, sollte mindestens eine Person im Betrieb diese Rolle haben, um im Ernstfall selbst pausieren zu können.
Google Play: gestaffelte Einführung nach Prozent
So läuft es ab
In der Play Console geben Sie beim Veröffentlichen eines Updates einen Prozentsatz an. Laut Play-Console-Hilfe werden Nutzer zufällig ausgewählt und nicht benachrichtigt. Ein wesentlicher Unterschied zu Apple: Der Prozentsatz steigt nicht automatisch. Sie erhöhen ihn selbst im Tab „Releases“ über „Manage rollout > Update rollout“ (so die Menünamen in der englischen Hilfe; die deutsche Oberfläche zeigt sie übersetzt).
Zusätzlich lässt sich eine gestaffelte Einführung laut Hilfe auf bestimmte Länder beschränken; einmal gestartet, können Sie aber keine Länder mehr entfernen. Gestaffelte Einführungen sind auch in offenen und geschlossenen Testtracks möglich.
Stoppen und fortsetzen
Entdecken Sie ein Problem, wählen Sie „Halt rollout“. Ab dann erhalten keine weiteren Nutzer diese Version; wer sie schon hat, behält sie. Ist die Version doch in Ordnung, setzen Sie die Einführung mit „Resume rollout“ fort – laut Google betrifft das dieselbe Nutzergruppe wie zuvor. Für einen echten Fehler empfiehlt Google, eine neue Version mit korrigiertem App Bundle zu veröffentlichen.
Zwei Tipps aus der Hilfe
Google rät, Änderungen am Store-Eintrag erst vorzunehmen, wenn das Update 100 Prozent erreicht hat, und während der Einführung Absturzberichte und Nutzerfeedback genau zu beobachten. Nutzer in der Staffelung können öffentliche Bewertungen abgeben – ein Fehler wird also auch bei fünf Prozent schon sichtbar.
Feature-Flags: die feinere Stellschraube
Store-Staffelungen steuern, wer eine Version bekommt. Feature-Flags steuern, welche Funktion innerhalb einer Version aktiv ist. Ein Beispiel: Ein neuer Bezahlablauf wird mit dem Update ausgeliefert, bleibt aber zunächst ausgeschaltet und wird dann für einen Teil der Nutzer aktiviert.
Firebase Remote Config ist ein Beispiel für einen solchen Dienst. Laut Firebase-Dokumentation lassen sich damit Verhalten und Aussehen einer App ändern, ohne dass Nutzer ein Update laden; Parameter können als Feature-Flags dienen und schrittweise an Nutzergruppen ausgerollt werden, inklusive Vergleich mit einer Kontrollgruppe anhand von Crashlytics- und Analytics-Daten. Der Vorteil: Fällt eine neue Funktion negativ auf, schalten Sie sie aus, statt auf eine korrigierte Version und eine weitere Store-Prüfung zu warten.
Feature-Flags müssen allerdings beim Programmieren eingeplant werden, und alte Flags sollten nach einiger Zeit wieder aus dem Code verschwinden, sonst wird er unübersichtlich.
Eine Routine für jedes Update
So lässt sich das in einem kleinen Team handhaben:
- Vor dem Einreichen: Bei Apple Phased Release aktivieren, bei Google einen niedrigen Startwert festlegen. Neue, riskante Funktionen zusätzlich hinter ein Flag legen.
- Erste zwei Tage: Absturzraten der neuen Version und neue Bewertungen täglich ansehen. Auch Support-Anfragen zählen.
- Erhöhen: Bei Google den Prozentsatz bewusst in Stufen erhöhen; bei Apple läuft es automatisch weiter.
- Bei Auffälligkeiten: Pausieren beziehungsweise stoppen, Ursache klären, korrigierte Version einreichen.
- Nach 100 Prozent: Store-Eintrag aktualisieren, falls nötig, und erledigte Flags aufräumen.
Kritische Korrekturen, etwa ein Fix für einen Absturz beim Start, können Sie bewusst schneller oder ohne Staffelung veröffentlichen – hier wiegt die Wartezeit schwerer als das Restrisiko.
Häufige Fragen
Merken Nutzer, dass sie Teil einer Staffelung sind?
Nein. Beide Stores geben an, dass Nutzer darüber nicht informiert werden. Sie bemerken höchstens, dass Bekannte schon eine neuere Version haben.
Kann ich bei Apple eigene Prozentstufen festlegen?
In App Store Connect nicht: Der Sieben-Tage-Plan ist fest vorgegeben. Sie können nur pausieren, fortsetzen oder sofort an alle veröffentlichen.
Was passiert mit Nutzern, die das fehlerhafte Update schon haben?
Sie behalten es, bis eine neue Version erscheint. Darum ist es wichtig, die Korrektur schnell nachzuschieben – und sie im Zweifel ohne Staffelung zu veröffentlichen.
Brauche ich bei sehr wenigen Nutzern überhaupt eine Staffelung?
Bei sehr kleinen Nutzerzahlen ist ein Prozent kaum aussagekräftig. Die Pausier-Möglichkeit ist trotzdem nützlich, weil sie die Zahl der Betroffenen begrenzt, während Sie reagieren.
Wenn Sie Ihre Release-Routine für die nächste App-Version sicherer aufstellen wollen, bespreche ich das gern mit Ihnen – ein kurzer Weg dorthin.