Hinweise zur App-Store-Prüfung

Nach dem manuellen Job release-ios prüft Apple die App, bevor sie im App Store erscheint. Bei Google läuft die Prüfung, nachdem release-android den Build in den Production Track befördert hat. Beide Prüfungen laufen gegen den Live-Stand, also gegen die Produktionsumgebung und die echten Store-Texte.

Demo-Zugang für die Prüfer

Hat die App einen Login, brauchen die Prüfer ein funktionierendes Demo-Konto. Du hinterlegst es im App-Repository unter ios/fastlane/metadata/review_information/ in drei Dateien: demo_user.txt enthält den Benutzernamen, demo_password.txt das Passwort und notes.txt Hinweise für die Prüfer, etwa zu Besonderheiten der App. Das Konto muss in der Produktionsumgebung funktionieren, weil die Prüfer den Live-Stand testen.

Häufige Ablehnungsgründe

Die meisten Ablehnungen haben wenige Ursachen. Beschreibung, Screenshots und Datenschutzangaben müssen zur tatsächlichen App passen; wie du sie im Repository pflegst, steht unter Store-Metadaten. Platzhalter wie leere Screens, „Lorem ipsum“ oder tote Links führen zuverlässig zur Ablehnung. Abstürze beim Start fallen den Prüfern als Erstes auf; genau deshalb stellt die Plattform jeden Stand zuerst in TestFlight und im Internal Track bereit, wo du den Release-Build vor der Einreichung ausprobieren kannst. Die Datenschutzerklärung unter der Privacy-URL und, wo nötig, ein Impressum müssen erreichbar sein. Jede Berechtigung für Kamera, Standort oder Tracking braucht in der App eine nachvollziehbare Begründung.

Nach einer Ablehnung

1. Lies die Begründung in App Store Connect bzw. in der Play Console. Sie verweist auf die konkrete Richtlinie, gegen die die App verstößt.
2. Behebe den Punkt, merge die Änderung auf main und warte, bis die Pipeline den neuen Build veröffentlicht hat.
3. Starte release-ios bzw. release-android erneut.

Wenn die Begründung von Apple unklar bleibt, kannst du direkt im Resolution Center von App Store Connect antworten und nachfragen.