erberkk/Review-Readiness

Überprüfungsbereitschaft

Zweck

Einmal einreichen und bestehen. Die meisten Ablehnungen betreffen nicht die Idee der App; sie betreffen einen Prüfer, der sich nicht anmelden, nicht kaufen konnte, einen Platzhalter sah oder einen Widerspruch zwischen Metadaten und der App fand.

Voraussetzungen

• Der genaue Build zur Einreichung befindet sich auf TestFlight / einer Play-Testspur.
• Der Checkpoint subscriptions-and-payments ist bestanden (ein echter Kauf hat Premium auf beiden Plattformen freigeschaltet).
• privacy-and-declarations ist abgeschlossen; die listing-and-aso-Validierung ist sauber; Screenshots sind hochgeladen.

Denken Sie wie ein Null-Wissens-Prüfer

Gehen Sie davon aus, dass der Prüfer einen sauberen Build auf einem Gerät installiert, das Sie nicht getestet haben (eine iPhone-only-App kann auf einem iPad im Kompatibilitätsmodus überprüft werden), mit einem frischen Store-Konto, und wenig Zeit hat. Sie lesen Ihre Notizen, versuchen die Anmeldung, suchen nach dem Kauf und vergleichen Screenshots mit der App. Eine einzelne Ablehnung kann mehrere Ebenen kombinieren: Kontostatus, Backend-Verhalten und Metadaten.

Vorgehen

1. Demo-Konto

• Die Anmeldedaten gehen in App Store Connect › App Review Information („Anmeldung erforderlich“) und Play › App-Inhalt › App-Zugriff. Niemals im Repository.
• Das Konto meldet sich mit E-Mail + Passwort an. Wenn Ihre normale Anmeldung ein einmaliger E-Mail-Code oder Magic Link ist, kann der Prüfer ihn nicht empfangen. Fügen Sie einen Passwort-Pfad nur für die Überprüfungsadresse hinzu (server-seitige Positivliste) oder einen festen Testcode, der nur für diese Adresse funktioniert.
• Mit Daten gefüllt: Vollständiges Profil, ein paar Tage Verlauf, alle Hauptbildschirme bevölkert. Ein leeres Konto verbirgt Funktionen und lädt zu „Wir konnten Funktion X nicht finden“ ein.
• Premium freigeschaltet über eine server-seitige manuelle Berechtigung (kein Ablauf während der Prüfung), damit Prüfer kostenpflichtige Funktionen sehen, ohne zu kaufen.
• Stellen Sie separat sicher, dass ein neuer Benutzer die Paywall erreichen und mit dem Sandbox-Konto des Prüfers kaufen kann (auch sie werden den Kauf testen).
• Ändern, löschen oder neu befüllen Sie dieses Konto nicht, während eine Prüfung offen ist.

2. Käufe (2.1(b) und 3.1.x)

• Abonnements der ersten Version sind an die Version in App Store Connect angehängt (Abschnitt „In-App-Käufe und Abonnements“) und haben einen Überprüfungs-Screenshot und Notizen. In der neueren App Store Connect-Oberfläche gibt es möglicherweise keinen solchen Abschnitt auf der Versionsseite: Öffnen Sie die Abonnementgruppe und jedes Abonnement und verwenden Sie Für Überprüfung hinzufügen → Entwurfeinreichung; die Version selbst wird von ihrer eigenen Seite hinzugefügt. Der Entwurf muss die Version, die Gruppe und jedes Abonnement auflisten, bevor Sie „Zur Überprüfung einreichen“ drücken.
• Jedes Abonnement benötigt mindestens eine Anzeigename + Beschreibung Lokalisierung und einen Überprüfungs-Screenshot; ohne sie schlägt „Für Überprüfung hinzufügen“ fehl („Sie müssen mindestens eine Abonnementlokalisierung / einen Überprüfungsinformations-Screenshot hinzufügen“).
• Der Überprüfungs-Screenshot muss die echte Paywall mit echten Preisen und der richtigen Store-Formulierung zeigen. Wenn Sie ihn aus einem Widget/UI-Test rendern, erzwingen Sie die iOS-Plattform (sonst steht dort „Google Play“) und geben Sie realistische Store-Preise ein; ein Zustand „Preise nicht verfügbar“ ist nicht akzeptabel.
• Die App Store-Versionszeichenfolge muss der Marketing-Version des Builds entsprechen (CFBundleShortVersionString). Eine Version namens 1.0 wird keine Builds anbieten, die als 1.0.0 hochgeladen wurden; der Build-Abschnitt sagt nur „Laden Sie Ihre Builds hoch“ ohne die Schaltfläche „Build hinzufügen“. Benennen Sie die Version um, damit sie übereinstimmt.
• Auf TestFlight mit einem frischen Sandbox-Apple-Konto (nicht mit einem Ihrer App-Konten verknüpft): Produkte laden, Kauf funktioniert, Wiederherstellung funktioniert.
• Der Paywall-Fehlerzustand zeigt „Wiederholen“, niemals ein deaktiviertes „Coming Soon“.
• Wenn ein IAP in der App nicht erreicht werden kann (z. B. nur für eine Region), erklären Sie dies in den Überprüfungshinweisen.
• „Käufe wiederherstellen“, „Bedingungen“- und „Datenschutz“-Links sowie der Link zur Abonnementverwaltung sind vorhanden.

3. Geräte und Builds

• Kaltstart ohne Netzwerk, langsames Netzwerk und Flugmodus umgeschaltet: kein Absturz, kein endloser Spinner.
• iPad: Sogar eine iPhone-only-App läuft auf dem iPad im Kompatibilitätsmodus und kann dort überprüft werden. Führen Sie den gesamten Ablauf auf einem iPad-Simulator durch: Anmeldung (einschließlich „Mit Apple anmelden“), Scrollen durch die Paywall, Kaufblatt, Tastatur über Formularen, Berechtigungsaufforderungen, Drehung. Wenn HealthKit oder eine andere API dort nicht verfügbar ist, zeigen Sie eine höfliche Nachricht, keinen Absturz.
• Kleinstes unterstütztes Telefon und größte Textgröße: keine abgeschnittenen Schaltflächen auf der Paywall oder den Einverständnisbildschirmen.
• Release-Build, kein Debug: kein Debug-Banner, keine Testmenüs, Analytics/Absturzberichterstattung in der Produktionskonfiguration aktiviert.
• Gehen Sie den gesamten Account-Lebenszyklus auf einem physischen Gerät mit dem genauen Build durch, den Sie einreichen: Installieren, Anmelden, Hauptfunktionen, Sandbox-Kauf, Account-Löschung und was die App nach der Löschung anzeigt.

4. Inhalt und Metadaten

• Durchsuchen Sie die Zeichenfolgen und Auflistungen der App nach: TODO, lorem, coming soon, beta, test, [PRICE], Platzhalterbilder. Keines darf sichtbar sein.
• iOS-Build und Metadaten enthalten keine Android/Google Play-Formulierungen; Play enthält keine Apple-only-Formulierungen (2.3.10). Dazu gehören In-App-Zeichenfolgen wie „In App Store oder Google Play kündigen“ – wählen Sie den Plattformtext zur Laufzeit aus.
• Jeder Screenshot stimmt mit der aktuellen Benutzeroberfläche überein; jede Zahl in der Beschreibung stimmt mit der App überein.
• Datenschutzerklärung, AGB, Support- und Account-Löschungs-URLs laden ohne Anmeldung, erwähnen die App und stimmen mit den Datenschutzformularen überein.
• Altersfreigabe konsistent mit den AGB.

5. Backend

• Backend läuft und befindet sich auf einem Tarif, der während der Prüfung keine Limits erreicht (kostenlose Stufen, die pausieren oder drosseln = Ablehnung).
• Keine Deployments mit bahnbrechenden Änderungen während der Prüfung. Rückwärtskompatible API für den Build in der Prüfung.
• Warnungen sind aktiviert (post-launch-ops), sodass Sie einen Ausfall während der Prüfung bemerken.

6. Überprüfungshinweise

Füllen Sie templates/review-notes.md aus. Bleiben Sie sachlich: Wo sich die Funktionen befinden, wie man sich anmeldet, wie man den Kauf testet, wie KI- und Gesundheitsdaten behandelt werden, wo die Account-Löschung ist.

Apple kann mit Richtlinie 2.1 „Informationen benötigt“ anstelle einer Überprüfung antworten. In einem beobachteten Fall wurden die folgenden sechs Punkte angefordert; wenn Sie sie gleich in der ersten Einreichung beantworten, vermeiden Sie eine Hin- und Herkommunikation:

1. Eine Bildschirmaufnahme von einem physischen Gerät mit dem neuesten Betriebssystem, beginnend beim App-Start und den typischen Ablauf zeigend: Registrierung, Anmeldung, Account-Löschung, benutzergenerierte Inhalte mit Melden/Blockieren und Zugriff auf kostenpflichtige Inhalte. Nehmen Sie es mit dem eingereichten Build auf; fügen Sie die Datei der Antwort in den Nachrichten der Einreichung bei (oder verlinken Sie sie) und erwähnen Sie es in den Notizen. Verwenden Sie niemals das Demo-Überprüfungskonto für den Löschungsteil: Erstellen Sie in der Aufnahme ein neues Konto.
2. Der Zweck und die Zielgruppe der App: das Problem, das sie löst, und ihr Wert.
3. Einrichtungs- und Zugriffsanweisungen für die Hauptfunktionen mit Demo-Anmeldedaten und Menüpfaden.
4. Jeder externe Dienst hinter Kernfunktionen: Authentifizierung/Datenbank, Zahlungen (StoreKit + jeder Wrapper), KI-Anbieter, Datenquellen (z. B. Karten-APIs), E-Mail, Health-Frameworks.
5. Regionale Unterschiede oder eine Aussage, dass die Funktionen überall gleich sind.
6. Für regulierte Bereiche oder durch Dritte geschützte Inhalte: Dokumentation oder eine Aussage, dass nichts dergleichen zutrifft (z. B. „Allgemeines Wohlbefinden, kein medizinisches Gerät“).

7. Go/No-Go-Bericht

Füllen Sie templates/go-no-go-report.md mit Nachweisen für jede Zeile aus (Screenshot, Buildnummer, Befehlsausgabe). Jedes Nein in einer blockierenden Zeile bedeutet keine Einreichung.

8. Einreichen (GENEHMIGUNG)

Bitten Sie den Kontoinhaber um ausdrückliche Genehmigung mit dem beigefügten Bericht. Wählen Sie auf iOS manuelle Veröffentlichung, damit die Genehmigung nicht sofort veröffentlicht wird. Auf Play benötigt der Produktionszugriff (neue persönliche Konten) den abgeschlossenen 14-tägigen geschlossenen Test und den Antrag auf Produktionszugriff.

Nach einer Ablehnung

Siehe references/rejection-playbook.md: Lesen Sie die genaue Richtlinie, reproduzieren Sie sie, beheben Sie die Ursache (oft mehr als eine Ebene), antworten Sie im Resolution Center mit Einzelheiten, reichen Sie erneut ein; legen Sie nur Einspruch ein, wenn der Prüfer eine Tatsache falsch gelesen hat, die Sie beweisen können.

Entscheidungspunkte, die menschliche Genehmigung erfordern

Einreichen, Veröffentlichungsmethode wählen, auf eine Ablehnung antworten (Ton und Zusagen), Einspruch einlegen, Premium für das Überprüfungskonto gewähren.

Verifikation

Der Go/No-Go-Bericht ist vollständig mit Nachweisen, und jemand, der die Funktion nicht erstellt hat, ist die Überprüfungshinweise auf einem sauberen Gerät durchgegangen und hat Erfolg gehabt.

Häufige Fallstricke

• Demo-Konto hängt von einem E-Mail-Code ab, den der Prüfer nicht lesen kann.
• Demo-Konto leer, eingefroren oder durch einen Bereinigungsjob gelöscht.
• Produkte in „Fehlende Metadaten“ (kein Überprüfungs-Screenshot), sodass sie bei der Prüfung nie geladen werden.
• Entfernen einer Version aus der Prüfung („Developer Rejected“) entfernt auch die Abonnements aus dem Entwurf; fügen Sie die Gruppe und jedes Abonnement vor dem erneuten Einreichen wieder hinzu, sonst geht die Version allein.
• Produktseiten-Assets sind gesperrt, während die Version auf „Warten auf Überprüfung“ ist (z. B. das neuere Header-Asset). Fügen Sie alles vor dem Einreichen hinzu; andernfalls müssen Sie die Version aus der Prüfung entfernen, bearbeiten und erneut einreichen (Sie verlieren Ihren Platz in der Warteschlange).
• Apples eigene „Für Überprüfung hinzufügen“-Prüfung besteht, aber optionale Assets sind nicht gesetzt: Ein leeres Header-Asset ist zulässig, also entscheiden Sie sich davor vor dem Einreichen.
• Ein frisches Apple-Konto eines Prüfers kollidiert mit Ihren Wiederherstellungs-/Übertragungsregeln und der Kauf schlägt fehl.
• Backend auf einem Tarif, der nach Inaktivität pausiert oder den Prüfer drosselt.
• „Coming Soon“ irgendwo im Build.
• In-App-Text, der den anderen Store erwähnt.
• Überprüfungshinweise, die nur die Demo-Anmeldung erklären (keine Aufnahme, Zweck, Dienste oder Regionen).