LaunchLint Academy
Die kurze Antwort
- Ein Google-Play-Produktionsrelease ist mehr als das Hochladen eines Android App Bundles. Store-Eintrag, App-Inhalte, Data Safety, Test-Tracks, Signierung und Rollout müssen denselben Build beschreiben und alle offenen Warnungen vor der Freigabe auflösen.
- Dieser Leitfaden führt Expo- und React-Native-Teams von der Release-Kandidatin bis zum kontrollierten Produktionsstart. Er behandelt nicht nur die Play-Console-Schritte, sondern auch die Belege, Verantwortlichkeiten und Rückfalloptionen, die einen belastbaren Release-Prozess ausmachen.
- Führe unmittelbar vor Produktion eine Release-Probe mit klaren Rollen durch. Eine Person bedient die Play Console, eine zweite installiert ausschließlich das Artefakt aus dem vorgesehenen Testtrack und eine dritte beobachtet Monitoring sowie Backend. Startet mit einem frischen Konto, prüft Update und Neuinstallation, erzeugt mindestens einen kontrollierten Fehlerfall und bestätigt, dass Support- und Datenschutzziele erreichbar sind. Vergleicht anschließend die sichtbare App mit Beschreibung, Screenshots, Data-Safety-Angaben und Release Notes. Das Ergebnis gehört mit Uhrzeit, Build, Geräten und offenen Ausnahmen in das Release-Protokoll. Erst wenn jede Abweichung einen Owner und eine bewusste Entscheidung besitzt, wechselt der Kandidat in Produktion.
- Archiviert werden nur prüfbare Ergebnisse: Console-Status, Artefakt-ID, Testbericht, freigegebene Store-Matrix und Rollout-Entscheidung. Secrets, Schlüssel und personenbezogene Testdaten gehören nicht in diese Nachweis.
Release-Kandidat und Versionsdaten einfrieren
Markiere einen konkreten Commit als Release-Kandidat und ändere danach nicht stillschweigend Code, Konfiguration oder native Abhängigkeiten. Versionscode, Versionsname, Paketname und verwendetes Expo-EAS-Profil müssen eindeutig zur erzeugten AAB-Datei gehören.
Ein reproduzierbarer Datensatz verhindert, dass Tester, Play Console und Team über verschiedene Artefakte sprechen. Speichere Prüfsumme, Build-Link, Commit, Erstellungszeit und verantwortliche Person in einem Release-Protokoll.
Release-Protokoll
- Commit, Versionscode und Versionsname festhalten
- Produktionsprofil und Paketnamen verifizieren
- AAB-Prüfsumme und Ablageort dokumentieren
- Keine Änderungen nach Freigabe einschleusen
- Verantwortliche Person benennen
App Bundle und Play App Signing prüfen
Google Play veröffentlicht Android App Bundles und erzeugt daraus optimierte APKs für Geräte. Prüfe deshalb, ob genau das erwartete Bundle hochgeladen wurde und ob Play App Signing korrekt eingerichtet ist. Schlüsselwechsel oder ein falsches Paket lassen sich nicht als kleine Metadatenkorrektur behandeln.
Expo-Teams sollten das Produktionsprofil, Credentials und den Application Identifier vor dem Build überprüfen. Führe keinen fremden Code aus und tausche keine Signaturdatei ad hoc aus, nur um einen Uploadfehler zu umgehen.
Bundle- und Signaturcheck
- AAB statt lokaler APK veröffentlichen
- Play App Signing und Upload-Key prüfen
- Paketname muss unverändert stimmen
- Bundle in der Artefaktübersicht kontrollieren
- Credentials nicht in Logs oder Tickets kopieren
Store-Eintrag vollständig abgleichen
Titel, Kurzbeschreibung, vollständige Beschreibung, Icon, Feature-Grafik, Screenshots, Kontakt und Datenschutzlink müssen vollständig sein. Jede Aussage muss zur Funktion des Release-Kandidaten passen; alte Screenshots oder Versprechen aus einem Prototyp erzeugen unnötige Review- und Vertrauensrisiken.
Kontrolliere alle gepflegten Sprachen separat. Eine erfolgreiche Standardsprache verdeckt fehlende oder veraltete Inhalte in anderen Store-Listings. Nutze eine Matrix aus Locale, Asset, Owner und Prüfdatum.
Store-Listing
- Texte entsprechen dem aktuellen Funktionsumfang
- Grafiken und Screenshots sind nicht veraltet
- Datenschutz- und Supportlinks funktionieren
- Alle Zielsprachen separat geprüft
- Kontaktdaten sind erreichbar
App-Inhalte und Data Safety abschließen
Der Bereich App content bündelt Datenschutzrichtlinie, Werbeangaben, App-Zugriff, Zielgruppe, Berechtigungen, Altersfreigabe, Data Safety und weitere Erklärungen. Diese Antworten sind keine Formalität, sondern öffentliche und review-relevante Aussagen über die App.
Leite die Angaben aus Code, SDK-Inventar und Backend-Flüssen ab. Wenn ein Analyse- oder Werbe-SDK Daten verarbeitet, muss die Erklärung diese Realität widerspiegeln. Ein Fragebogen darf keine technische Prüfung ersetzen.
App-Content-Abnahme
- Werbung und Zielgruppe korrekt angegeben
- App-Zugriff für Prüfer bereitgestellt
- Berechtigungen und sensible Nutzung erklärt
- Data Safety gegen SDKs und Backend geprüft
- Altersfreigabe vollständig beantwortet
Interne und geschlossene Tests nutzen
Ein interner Track eignet sich für schnelle Team- und Gerätechecks; geschlossene Tests bilden größere reale Nutzung besser ab. Installiere die über Play verteilte Variante, nicht nur einen lokalen Debug-Build, damit Signierung, Bundle-Splits, Updates und Store-Kontext geprüft werden.
Definiere vorab Abnahmekriterien: Erststart, Anmeldung, Kernworkflow, Käufe, Berechtigungen, Deep Links, Offline- und Fehlerzustände. Tester sollten Buildnummer und Gerät in jeder Meldung nennen.
Testabdeckung
- Play-verteilten Build installieren
- Erststart und Updatepfad testen
- Kernworkflow und Fehlerfälle prüfen
- Käufe und Deep Links verifizieren
- Geräte- und Builddaten in Bugs erfassen
Pre-Launch-Report auswerten
Der Pre-Launch-Report testet hochgeladene Bundles auf Geräten und kann Stabilitäts-, Performance-, Zugänglichkeits- und Sicherheitsprobleme sichtbar machen. Er ist ein zusätzliches Signal und kein Ersatz für gezielte Produkttests.
Triage jedes Ergebnis: reproduzierbarer Blocker, relevantes Risiko, bekannte Einschränkung oder Fehlalarm. Dokumentiere die Entscheidung. Ignorierte Warnungen ohne Begründung tauchen in späteren Releases wieder auf und verlieren ihren Informationswert.
Report-Triage
- Crash und ANR reproduzieren
- Performance- und Accessibility-Hinweise bewerten
- Sicherheitswarnungen zuständig zuweisen
- Fehlalarme begründet dokumentieren
- Blocker vor Produktion schließen
Produktionsrelease kontrolliert ausrollen
Erstelle den Produktionsrelease erst, wenn erforderliche Store- und App-Content-Aufgaben abgeschlossen sind und die Play Console keine blockierenden Fehler meldet. Release Notes müssen die tatsächliche Änderung knapp erklären.
Ein gestaffelter Rollout begrenzt die Auswirkung unbekannter Fehler. Lege Stop-Kriterien, verantwortliche Person und Beobachtungsfenster fest, bevor du den Prozentsatz erhöhst. Ohne diese Regeln wird ein Staged Rollout nur zu einem langsameren Vollrelease.
Rollout-Gate
- Keine blockierenden Console-Fehler
- Release Notes sind korrekt
- Startprozentsatz und Beobachtungszeit festlegen
- Stop- und Abbruchkriterien definieren
- Owner darf Rollout pausieren
Nach dem Start beobachten und dokumentieren
Beobachte nach der Freigabe Crashes, ANRs, Bewertungen, Supportsignale, Backendfehler und geschäftskritische Funnels. Vergleiche sie mit einer bekannten Basis, damit normale Schwankung nicht als Incident oder ein echter Rückgang nicht als Rauschen behandelt wird.
Schließe das Release mit einem Protokoll ab: finale Version, Zeitpunkt, Rollout-Schritte, Auffälligkeiten und offene Folgeaufgaben. Diese Historie beschleunigt spätere Reviews und macht wiederkehrende Probleme sichtbar.
Betrieb nach Release
- Crashes und ANRs mit Basis vergleichen
- Support und Bewertungen beobachten
- Backend und Kernfunnels prüfen
- Rollout nur nach Gate erhöhen
- Erkenntnisse ins nächste Release übernehmen
Häufige Fragen
Brauche ich für Google Play ein AAB?
Für neue Veröffentlichungen ist das Android App Bundle der reguläre Uploadweg; Google Play erzeugt daraus geräteoptimierte APKs.
Reicht ein erfolgreicher Upload für den Produktionsstart?
Nein. Store-Eintrag, App-Inhalte, Richtlinienangaben, Testresultate und offene Fehler müssen ebenfalls abgeschlossen sein.
Sollte ich direkt auf 100 Prozent ausrollen?
Bei relevanten Änderungen ist ein gestaffelter Rollout mit vorher definierten Stop-Kriterien sicherer.
Ersetzt der Pre-Launch-Report manuelle Tests?
Nein. Er liefert zusätzliche Geräte- und Qualitätssignale, deckt aber nicht deinen vollständigen fachlichen Workflow ab.
Welche Version sollten Tester installieren?
Wenn möglich die über einen Play-Testtrack verteilte Version, weil sie Signierung, Bundle-Auslieferung und Store-Kontext realistisch abbildet.