LaunchLint Academy
Die kurze Antwort
- TestFlight verteilt Beta-Builds, reicht sie aber nicht automatisch zur App-Store-Prüfung ein. Für die Review wählst du eine konkrete Version und genau den Build aus, dessen Metadaten, Zugang und Datenschutzangaben vollständig sind.
- Nutze Beta-Feedback als Freigabenachweis, friere den Kandidaten ein und entscheide Review, Veröffentlichung und Monitoring als getrennte Schritte.
- Diese Checkliste ist kein einmaliger Content-Check. Führe sie vor dem ersten Store-Upload, nach relevanten Änderungen an Abhängigkeiten oder Konfigurationen und unmittelbar vor der Freigabe erneut aus. Entwicklung, Produkt und die Person mit Zugriff auf die Store-Konsole müssen denselben Build beurteilen. Statische Signale im Projekt sind besonders wertvoll, weil sie reproduzierbar sind, beweisen aber weder das Laufzeitverhalten noch die Antwort eines Backends. Ergänze sie deshalb mit Tests des signierten Artefakts, offiziellen Store-Angaben und einem klaren Freigabeprotokoll.
1. Beta-Ziel und Testergruppen festlegen
Definiere, welche Risiken interne und externe Tester prüfen sollen, statt TestFlight nur als Downloadkanal zu verwenden.
Behandle beta-ziel und testergruppen festlegen als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für beta-ziel und testergruppen festlegen eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
2. Exakten Build einfrieren
Ordne Build-Nummer, Commit, Umgebung, Feature Flags und Testdaten eindeutig zu; ein späterer Upload ist ein anderer Kandidat.
Behandle exakten build einfrieren als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für exakten build einfrieren eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
3. Externe Beta-Review einplanen
Externe Testgruppen können eine Beta-App-Review benötigen. Plane Angaben und Wartezeit ein, ohne dies mit der eigentlichen App Review zu verwechseln.
Behandle externe beta-review einplanen als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für externe beta-review einplanen eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
4. Feedback und Abstürze triagieren
Klassifiziere Rückmeldungen nach Blocker, Regression und Verbesserung und dokumentiere bewusst akzeptierte Restrisiken.
Behandle feedback und abstürze triagieren als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für feedback und abstürze triagieren eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
5. App-Store-Version vervollständigen
Wähle den Build in App Store Connect und schließe erforderliche Metadaten, Datenschutz, Altersfreigabe, Exportfragen und Testzugang für das Prüfteam ab.
Behandle app-store-version vervollständigen als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für app-store-version vervollständigen eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
6. Hinweise für das Prüfteam am Build testen
Ein frischer Tester muss Login, Käufe, besondere Hardware und geschützte Funktionen allein mit den eingereichten Hinweisen erreichen.
Behandle hinweise für das prüfteam am build testen als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für hinweise für das prüfteam am build testen eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
7. Status und Antworten kontrollieren
Unterscheide Waiting for Review, In Review, Metadaten Rejected und Binary Rejected und antworte mit konkretem Pfad sowie Nachweis.
Behandle status und antworten kontrollieren als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für status und antworten kontrollieren eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
8. Freigabe und Rollout planen
Automatische, manuelle oder gestaffelte Veröffentlichung brauchen Owner, Monitoring, Stop-Kriterien und einen Plan für kritische Fehler.
Behandle freigabe und rollout planen als überprüfbaren Teil des konkreten Release-Kandidaten. Verknüpfe die Entscheidung mit der zuständigen Datei, dem Store-Feld oder einem reproduzierbaren Gerätetest. Notiere erwartetes und beobachtetes Verhalten getrennt, benenne einen Owner und stoppe die Veröffentlichung, wenn ein sicherheits- oder review-relevanter Widerspruch offen bleibt.
Prüfnachweis für den Release
- Produktionsstand für freigabe und rollout planen eindeutig benannt
- Betroffene Projektdatei oder Store-Einstellung verlinkt
- Prüfung auf einem sauberen Gerät wiederholt
- iOS- und Android-Abweichungen dokumentiert
- Offene Frage mit Owner und Termin versehen
- Ergebnis ohne Secrets oder persönliche Testdaten gespeichert
Häufige Fragen
Sendet TestFlight meine App automatisch zur App Review?
Nein. TestFlight ist Beta-Verteilung. Die App-Store-Version und der konkrete Build müssen separat zur Review eingereicht werden.
Wie lange kann ein TestFlight-Build getestet werden?
Apple kennzeichnet Beta-Builds mit einer begrenzten Testdauer. Prüfe den aktuellen Ablauf in App Store Connect und plane nicht mit einem dauerhaften Beta-Artefakt.
Sollte ich nach jedem kleinen Fix einen neuen Build einreichen?
Erzeuge einen neuen Build, wenn sich das Binary ändert, und wiederhole die betroffenen Abnahmen gezielt.
Kann LaunchLint TestFlight-Crashs ausführen?
Nein. LaunchLint prüft Projektdateien statisch; Crash- und Gerätedaten müssen separat ausgewertet werden.