Was passiert nach dem Upload in Google Play und App Store?

Du hast einen grünen Build. Alle Tests bestanden. Der Release-Branch ist sauber. Jemand im Team sagt: "Okay, einfach in den Store hochladen und auf das Review warten." Wenn du schon einmal einen echten mobilen Release durchgeführt hast, weißt du, dass dieser Satz eine Menge Komplexität verbirgt.

Das Hochladen in die Google Play Console oder App Store Connect ist nicht einfach nur das Versenden einer Datei. Es ist ein mehrstufiger Prozess, der Metadaten, Screenshots, Changelogs, Review-Warteschlangen und die sehr reale Möglichkeit einer Ablehnung umfasst. Und wenn deine Pipeline den Upload als letzten Schritt betrachtet, bereitest du dich auf eine nächtliche Panik vor, wenn das Review mit einer Ablehnung zurückkommt.

Der Upload ist mehr als eine Dateiübertragung

Wenn du ein Android App Bundle (AAB) oder eine iOS IPA-Datei hochlädst, erwartet der Store mehr als nur die Binärdatei. Du musst auch Folgendes bereitstellen:

  • App-Titel und Beschreibung für die neue Version
  • Was sich in diesem Release geändert hat (Changelog)
  • Screenshots für verschiedene Gerätegrößen
  • App-Kategorie und Aktualisierungen der Altersfreigabe
  • Welche Länder oder Regionen das Update erhalten

Sowohl die Google Play Console als auch App Store Connect bieten APIs, mit denen deine Pipeline all dies programmatisch erledigen kann. Dein CI/CD-System kann das Artefakt pushen, die Metadaten ausfüllen, die richtigen Screenshots anhängen und den Release-Track festlegen. Für Android kannst du zuerst in den internen Test, geschlossenen Test oder offenen Test hochladen, bevor du überhaupt an die Produktion denkst. Für iOS lädst du zuerst auf TestFlight hoch.

Das folgende Sequenzdiagramm zeigt den typischen Ablauf von der Pipeline bis zum Release:

Zum Beispiel kannst du mit fastlane supply auf Android die Binärdatei hochladen, das Changelog setzen und Screenshots in einem Befehl anhängen:

# AAB in den internen Test-Track von Google Play hochladen
fastlane supply \
  --aab ./app/build/outputs/bundle/release/app-release.aab \
  --track internal \
  --metadata_path ./fastlane/metadata/android \
  --json_key ./path/to/service-account-key.json \
  --package_name com.example.myapp

# Der Metadaten-Ordner sollte enthalten:
#   metadata/android/en-US/title.txt
#   metadata/android/en-US/short_description.txt
#   metadata/android/en-US/full_description.txt
#   metadata/android/en-US/changelogs/1.txt (Versionscode als Dateiname)
#   metadata/android/en-US/images/phoneScreenshots/
sequenceDiagram participant CI as CI/CD Pipeline participant Store as Store API participant Review as Review Queue participant Track as Release Track CI->>Store: Binary + Metadaten hochladen Store->>Review: Zum Review einreichen Review-->>Store: Genehmigung oder Ablehnung alt Abgelehnt Store-->>CI: Ablehnungsmitteilung CI->>Store: Korrigieren und erneut hochladen else Genehmigt Store->>Track: Release-Track setzen (internal/closed/open/production) Track->>Track: Gestaffelter Rollout oder vollständiger Release end

Die entscheidende Erkenntnis hier ist, dass der Upload-Schritt nicht das Ende deiner Pipeline sein sollte. Er sollte der Beginn eines kontrollierten Release-Prozesses sein.

Warum du nicht direkt in die Produktion hochladen solltest

Es ist verlockend, eine Pipeline zu bauen, die direkt von "Tests bestanden" zu "im Store veröffentlicht" führt. Aber mobile Stores fügen ein Tor hinzu, das es bei Web- oder Backend-Bereitstellungen nicht gibt: die menschliche Überprüfung.

Apple überprüft jede App und jedes Update anhand der App Store Review Guidelines. Google überprüft Einreichungen ebenfalls, obwohl der Prozess im Allgemeinen schneller und weniger streng ist. Wenn deine Pipeline direkt in die Produktion hochlädt und das Review ein Problem findet, musst du es beheben, erneut hochladen und wieder warten. Das kann deinen Release um Tage verzögern.

Ein besserer Ansatz ist es, zuerst auf einen Test-Track hochzuladen. Auf Android kannst du den internen Test-Track verwenden. Auf iOS verwendest du TestFlight. Das gibt deinem Team und einer kleinen Gruppe von Testern die Möglichkeit, den eigentlichen Store-Build auszuprobieren, bevor er durch das öffentliche Review geht. Wenn etwas nicht stimmt, entdeckst du es frühzeitig, behebst es und lädst es erneut hoch, ohne den Druck einer abgelehnten Produktionseinreichung.

Metadaten und Screenshots müssen zum Build passen

Einer der häufigsten Gründe für eine Ablehnung ist eine Diskrepanz zwischen dem, was die App tut, und dem, was der Store-Eintrag sagt. Wenn deine neue Version eine Funktion hinzufügt, deine Screenshots aber noch die alte Oberfläche zeigen, kann Apple oder Google sie als irreführend ablehnen.

Deine Pipeline kann hier helfen. Speichere die Screenshots und Metadaten für jede Version zusammen mit deinem Code. Wenn du einen Release auslöst, wählt die Pipeline die richtigen Assets basierend auf der Versionsnummer oder dem Release-Tag aus. Das stellt sicher, dass das, was du in den Store hochlädst, auch tatsächlich dem entspricht, was die Binärdatei enthält.

Halte Changelogs kurz und sachlich. Schreibe nicht bei jedem Release "Fehler behoben und Leistung verbessert". Benutzer lesen diese. Noch wichtiger ist, dass auch Store-Reviewer sie lesen. Wenn dein Changelog "Dark Mode hinzugefügt" sagt, die App aber keinen Dark Mode hat, ist das ein Problem.

Plane Review-Zeit in deinen Release-Zeitplan ein

Mobile Store-Reviews brauchen Zeit. Apple benötigt in der Regel 24 bis 48 Stunden für App-Updates und länger für neue Apps. Google ist normalerweise schneller, manchmal nur wenige Stunden, aber es gibt immer eine Warteschlange. Wenn du ein festes Release-Datum hast, musst du früh genug hochladen, um die Review-Zeit plus mögliche Wiedereinreichungen zu berücksichtigen.

Gehe nicht davon aus, dass das erste Review bestanden wird. Selbst erfahrene Teams werden aus Gründen wie diesen abgelehnt:

  • Anfordern von Berechtigungen ohne Erklärung, warum
  • Verwendung privater APIs
  • Unvollständige oder falsche Metadaten
  • UI-Elemente, die nicht zu den Screenshots passen
  • Verstöße gegen storespezifische Richtlinien (wie Apples Regeln für In-App-Käufe)

Baue Pufferzeit in deinen Release-Plan ein. Wenn die App bis Freitag live sein muss, versuche, sie spätestens am Dienstag oder Mittwoch einzureichen. Das gibt dir Spielraum, um Probleme zu beheben und erneut einzureichen.

Was passiert, nachdem das Review bestanden ist

Sobald das Review deinen Build genehmigt hat, beginnt die Release-Phase. Dies ist keine Entweder-oder-Entscheidung. Beide Stores unterstützen gestaffelte Rollouts.

Auf Android kannst du einen gestaffelten Rollout verwenden, um das Update für einen Prozentsatz der Nutzer freizugeben, z. B. 10 % oder 25 %. Auf iOS kannst du die phasenweise Freigabe verwenden, die das Update schrittweise über mehrere Tage ausrollt. So kannst du Absturzraten, Benutzerfeedback und wichtige Kennzahlen überwachen, bevor du es für alle freigibst.

Deine Pipeline sollte dies unterstützen. Nachdem das Review bestanden ist, kann die Pipeline den anfänglichen Rollout-Prozentsatz festlegen, auf einen Überwachungszeitraum warten und dann den Prozentsatz erhöhen oder auf die vollständige Freigabe umstellen. Wenn etwas schief geht, kannst du den Rollout anhalten, ohne alle Benutzer zu beeinträchtigen.

Praktische Checkliste für Store-Uploads

  • Lade zuerst auf einen internen oder geschlossenen Test-Track hoch, bevor du ihn zum öffentlichen Review einreichst
  • Speichere Metadaten und Screenshots in versionierten Verzeichnissen zusammen mit deinem Code
  • Verwende Store-APIs, um die Metadatenübermittlung zu automatisieren, nicht nur den Binär-Upload
  • Füge ein Changelog hinzu, das genau beschreibt, was sich in dieser Version geändert hat
  • Plane mindestens 48 Stunden Pufferzeit vor deinem Ziel-Release-Datum ein
  • Konfiguriere den gestaffelten Rollout oder die phasenweise Freigabe als Standard, nicht die vollständige Freigabe
  • Habe einen Rollback-Plan: Wisse, wie du die Veröffentlichung rückgängig machen oder zu einer vorherigen Version zurückkehren kannst

Das Fazit

Das Hochladen in einen mobilen Store ist nicht die Ziellinie. Es ist der Beginn eines Prozesses, der Review, mögliche Ablehnung, gestaffelten Rollout und Überwachung umfasst. Wenn deine Pipeline den Upload als letzten Schritt betrachtet, wirst du immer wieder von Ablehnungen und verzögerten Releases überrascht werden. Baue den Review-Prozess in dein Pipeline-Design ein, lade zuerst auf Test-Tracks hoch und lasse immer Raum für einen zweiten Versuch. So verwandelst du mobile Releases von einem stressigen Ereignis in einen routinemäßigen Vorgang.