In diesem Ratgeber
Diese Checkliste deckt die letzte Strecke ab: Ein Build hat TestFlight durchlaufen und soll in den App Store. Zu jedem Punkt steht, warum er zählt und wie du ihn prüfst. Geh sie der Reihe nach durch.
1. Der Build
- Teste genau den Build, den du einreichst. Warum: Ein neuer Build kann vom getesteten abweichen. So prüfst du: Vergleiche Build- und Versionsnummer in TestFlight und App Store Connect.
- Spiele deine wichtigsten Abläufe auf einem echten Gerät durch. Warum: Simulator-Läufe übersehen Hardware- und Netzprobleme. So prüfst du: Installiere aus TestFlight und teste Anmeldung, Kauf, Mitteilungen. Siehe Simulator oder echtes iPhone.
- Prüfe, ob der TestFlight-Build noch gültig ist. Warum: Laut Apple kann ein Build „bis zu 90 Tage“ getestet werden und steht danach Testern nicht mehr zur Verfügung. So prüfst du: Schau in TestFlight auf das Ablaufdatum.
- Offene Fehler schließen oder bewusst akzeptieren. Warum: Ein bekannter Absturz ist jetzt billiger zu beheben als nach einer Ein-Stern-Bewertung. So prüfst du: Sortiere dein Feedback nach Schwere und entscheide je Eintrag.
2. Der Store-Eintrag
- „Neu in dieser Version“ passt zum Build. Warum: Falsche Hinweise verwirren Nutzer und Prüfer. So prüfst du: Lies den Text gegen die Änderungen seit der letzten Version.
- Screenshots zeigen die aktuelle Oberfläche. Warum: Veraltete Bilder führen zu Rückgaben und schlechten Bewertungen. So prüfst du: Lege jeden Screenshot neben die laufende App.
- Datenschutzangaben und Erklärung passen zur App. Warum: Apples App-Review-Richtlinien (5.1.1) verlangen einen Link zur Datenschutzerklärung in den Metadaten in App Store Connect und in der App; die Erklärung muss sagen, welche Daten die App erhebt und nutzt, auch durch SDKs von Dritten. So prüfst du: Liste alle SDKs und Datentypen auf und vergleiche sie mit deinen Angaben und der Erklärung. Keine Rechtsberatung; prüfe die aktuellen Richtlinien.
3. Hinweise für die App-Prüfung
- Gib ein funktionierendes Demo-Konto an, wenn eine Anmeldung nötig ist. Warum: Prüfer können nichts testen, was sie nicht öffnen können. So prüfst du: Melde dich mit genau diesen Daten auf einer frisch installierten App an. Apples Richtlinien (2.1) verlangen Demo-Zugangsdaten, wenn die App eine Anmeldung hat; für zusätzliche Hinweise an die Prüfer verweist Apple auf den Bereich „App Review Information“.
- Erkläre Unauffälliges nicht stillschweigend. Warum: Hardware, Regionssperren oder versteckte Funktionen werfen Fragen auf, und laut Apples Richtlinien müssen deine Backend-Dienste während der Prüfung laufen. So prüfst du: Lass jemanden außerhalb des Projekts den Hinweis lesen und sagen, was unklar bleibt.
4. Einreichen und freigeben
- Rechne damit, dass die Reihenfolge nicht stimmt. Apple schreibt, Einreichungen würden nicht zwingend in der Reihenfolge geprüft. Plane vor einem festen Termin Puffer ein.
- Lege fest, wie die Version live geht. Warum: Bei manueller Freigabe wartest du auf den richtigen Moment. So prüfst du: Sieh dir die Freigabe-Option auf der Versionsseite an.
- Erwäge die gestaffelte Freigabe. Apple beschreibt sie als Verteilung „über 7 Tage“ an eine zufällige Auswahl von Nutzern mit automatischen Updates: 1 %, 2 %, 5 %, 10 %, 20 %, 50 %, 100 %. Wer manuell lädt, bekommt das Update jederzeit sofort. Pausieren kannst du insgesamt bis zu 30 Tage.
5. Nach der Freigabe
- Beobachte Abstürze und erste Bewertungen in den ersten Tagen. Warum: Die gestaffelte Freigabe hilft nur, wenn du hinsiehst. So prüfst du: Schau täglich in die Absturzberichte.
- Pausiere bei einem schweren Fehler die Freigabe und reiche eine korrigierte Version ein.
- Antworte sachlich auf frühe Bewertungen. Siehe Antworten auf Bewertungen.
Verwandt
- Hub: iOS-App-Testing-Leitfaden
- Anleitung für TestFlight-Tester zum Versenden
- TestFlight oder Ad-hoc-Verteilung
Du willst privates, strukturiertes Feedback zu deinem Build, bevor du einreichst? Bei AppReviewX bringt ein geschriebenes Feedback einen Credit. Bei AppReviewX loslegen.