LaunchLint Academy
Die kurze Antwort
- App Hinweise für das Prüfteam erklären ausschließlich prüfrelevanten Kontext: Zugang, Navigation, besondere Voraussetzungen, nicht offensichtliche Funktionen, digitale Käufe und Änderungen gegenüber einer vorherigen Ablehnung. Wiederhole nicht die Store-Beschreibung.
- Stelle ein dauerhaftes Demo-Konto oder einen genehmigten voll funktionsfähigen Demo-Modus bereit, halte das Backend während der Review erreichbar und teste den beschriebenen Weg auf einem frischen Gerät mit exakt dem eingereichten Build.
- Schreibe kurz, konkret und überprüfbar. Nenne Build, Menüpfad, erwarteten Zustand und besondere Bedingungen. Teile keine produktiven API-Keys, internen Admin-Zugänge oder personenbezogenen Nutzerdaten in den Notes.
1. Wofür Hinweise für das Prüfteam gedacht sind
Apple empfiehlt detaillierte Erklärungen für nicht offensichtliche Funktionen und In-App Purchases. Die Notes gehören zu den App Store Review Details und sind nicht öffentlich im Store. Sie ergänzen Kontaktinformationen, Demo-Account und optional Anhänge. Ihr Zweck ist, vermeidbare Rückfragen und einen blockierten Testweg zu verhindern.
Die Notes sind keine zweite App-Beschreibung und kein Ort für allgemeine Versprechen. Ein Satz wie ‚Unsere App nutzt modernste KI und funktioniert vollständig‘ hilft dem Prüfer nicht. Nützlich ist dagegen: ‚Der PDF-Export erscheint nach Auswahl eines Demo-Projekts unter Projekte > Beispielprojekt > Export; keine Zahlung erforderlich.‘
2. Die Mindestinformationen vor jeder Einreichung
App Store Review Details enthalten Kontaktname, Telefon, E-Mail und die Information, ob ein Demo-Account erforderlich ist. Halte diese Daten aktuell und überwacht. Eine Person, die während der Review nicht reagiert, kann den Prozess verzögern. Verwende keine persönliche Wegwerfadresse, wenn ein Team-Postfach möglich ist.
Beginne die Notes mit Version und Build. Nenne danach nur Änderungen oder Voraussetzungen, die für genau diesen Build relevant sind. Wenn eine Funktion keine Erklärung benötigt, beschreibe sie nicht künstlich. Gute Notes werden mit jedem Release überprüft und von veralteten Anweisungen befreit.
Minimum:
- Versions- und Build-Nummer
- Ein Satz zur wesentlichen Änderung
- Aktuelles Review-Konto oder Demo-Modus
- Kürzester Navigationspfad zur Kernfunktion
- Besondere Rollen, Regionen, QR-Codes oder Hardware
- Sichtbarkeit und Voraussetzungen von In-App Purchases
- Erreichbarer Review-Kontakt
3. Ein Demo-Konto bauen, das die Review überlebt
Apple erwartet bei accountbasierten Funktionen ein aktives Demo-Konto oder einen voll funktionsfähigen Demo-Modus. Das Konto darf nicht von deinem eigenen Telefon, einer kurzlebigen E-Mail, einem manuellen Admin-Schritt oder einem zeitlich begrenzten Magic Link abhängen. Das Backend und alle benötigten Medien müssen während der Review erreichbar bleiben.
Befülle den Account mit sicheren, fiktiven Daten, die jeden relevanten Zustand zeigen. Ein leeres Dashboard kann wie eine unvollständige App wirken. Wenn Rollen existieren, entscheide, ob ein Konto alle Funktionen zeigt oder mehrere klar bezeichnete Konten nötig sind. Teste die Credentials unmittelbar vor dem Submit außerhalb deines Firmennetzes.
Robustes Review-Konto:
- Kein persönlicher Nutzeraccount
- Keine produktiven Kundendaten
- Stabiles Passwort und überwachte Recovery
- 2FA nur mit dokumentiertem Review-Weg
- Beispieldaten für leere und gefüllte Zustände
- Keine automatische Löschung während der Review
- Backend-Monitoring und verantwortlicher Kontakt
4. Nicht offensichtliche Flows präzise beschreiben
Ein Prüfer sollte nicht raten müssen, wann ein Feature Flag aktiv wird, welche Rolle einen Button sieht oder warum eine Funktion erst nach QR-Code, Standort, Bluetooth-Gerät oder genehmigtem Inhalt erscheint. Beschreibe Vorbedingung, Navigation, Aktion und erwartetes Ergebnis in dieser Reihenfolge. Füge bei Bedarf eine fiktive Beispieldatei oder einen QR-Code als Attachment hinzu.
Für Permissions erkläre nicht nur, welcher Systemdialog erscheint, sondern die Funktion dahinter. Für Account-Löschung nenne den Pfad. Für User Generated Content zeige Melden und Blockieren. Für einen regionalen Flow nenne die im Review-Konto aktive Region. Halte den Text so kurz, dass der kritische Schritt nicht zwischen Nebensätzen verschwindet.
| Zu vage | Prüfbare Note |
|---|---|
| Login funktioniert | Mit dem Demo-Konto anmelden; danach öffnet sich Projekte mit zwei Beispielen |
| Kamera wird benötigt | Projekt > Beleg scannen öffnet die Kamera zur Erfassung eines Belegs |
| Löschung vorhanden | Einstellungen > Konto > Konto löschen; Bestätigung mit Passwort |
| Premium kann getestet werden | Demo-Account besitzt aktives Testabo; Export liegt in Beispielprojekt > Export |
5. In-App Purchases und Abos reviewbar machen
Apple verlangt, dass zur Review eingereichte In-App Purchases vollständig, aktuell, sichtbar und funktionsfähig sind. Wenn ein konfiguriertes Produkt nicht gefunden werden kann, erkläre den Grund in den Notes. Das betrifft etwa eine Paywall, die erst nach einem Nutzungslimit erscheint, ein Produkt für eine bestimmte Region oder einen Kauf, der eine besondere Rolle voraussetzt.
Nenne Produkt nicht nur beim internen Identifier, sondern beim sichtbaren Namen und Pfad. Teste außerdem Restore Purchases, bereits aktives Abo, fehlgeschlagenen Kauf und Neuinstallation. Wenn das Review-Konto schon Premium besitzt, erkläre, wie der Prüfer trotzdem Paywall und Restore sehen kann, ohne Produktionsdaten zu verändern.
- Produkte gemeinsam mit dem Build zur Review bereit
- Agreements und steuerliche Angaben aktiv
- Paywall im Demo-Flow erreichbar
- Produktname und Bedingungen stimmen mit Store-Konfiguration überein
- Restore nachvollziehbar
- Sandbox-Zustand getestet
- Sonderbedingung in einem Satz erklärt
6. Eine belastbare Review-Notes-Vorlage
Nutze eine wiederholbare Struktur, aber behandle sie nicht als unveränderten Boilerplate-Text. Entferne Abschnitte, die nicht gelten, und aktualisiere Build, Pfade und Konten. Englisch ist für ein internationales Prüfteam oft die klarste gemeinsame Sprache; kurze einfache Sätze sind wichtiger als Marketingstil.
BUILD
- Version / build: [1.0.0 / 42]
- Main change: [one factual sentence]
REVIEW ACCESS
- Demo account: [dedicated review account]
- Path: Launch app > Sign in > [feature]
- Required role or setup: [only if applicable]
NON-OBVIOUS FLOWS
- Purchase appears when: [condition]
- Account deletion: Settings > Account > Delete account
- Permission purpose: [feature and user value]
CONTACT
- Name: [responsible person]
- Email / phone: [monitored during review]Speichere die Vorlage im Release-Prozess, nicht als fest verdrahtetes Secret im Projekt. Eine interne Checkliste kann die Felder enthalten; echte Credentials gehören in einen sicheren, kontrollierten Prozess und nur in das vorgesehene App-Store-Connect-Feld. Prüfe nach dem Einfügen, ob keine alten Build-Nummern oder Pfade stehen geblieben sind.
7. Nach einer Ablehnung sachlich und mit Nachweis antworten
Bei einer Ablehnung kannst du im App-Review-Bereich antworten und bis zum Resubmit Anhänge hinzufügen. Lies die zitierte Guideline und den konkreten Testweg. Reproduziere ihn mit dem abgelehnten Build. Wenn nur Metadaten betroffen sind, kann derselbe Build nach Korrektur erneut eingereicht werden; Code- oder Konfigurationsänderungen benötigen ein neues Binary.
Antworte mit Ursache, Änderung und Verifikation. Beispiel: ‚Der in den Notes genannte Account war abgelaufen. Wir haben ihn ersetzt und in Build 42 mit einem frischen Gerät geprüft. Nach Login öffnet Projekte > Beispielprojekt den Export ohne weitere Einladung.‘ Frage höflich nach konkreten Schritten, wenn die Nachricht nicht reproduzierbar ist.
Vor dem Reply:
- Prüfer-Nachricht vollständig sichern
- Problem im genannten Build reproduzieren
- Fix oder Metadatenänderung fertigstellen
- Regression auf frischem Gerät testen
- Notes und Credentials aktualisieren
- Build und Navigation exakt nennen
- Nur relevante Screenshots oder Dokumente anhängen
- Keine Freigabegarantie behaupten
Häufige Fragen
Soll ich die Hinweise für das Prüfteam auf Deutsch oder Englisch schreiben?
Apple schreibt keine universelle Sprache vor. Klares, einfaches Englisch ist für internationale Prüfteams meist robust. Entscheidend sind präzise Pfade, aktuelle Credentials und verständliche Voraussetzungen.
Darf ich Testzugangsdaten in Hinweise für das Prüfteam eintragen?
Ja, wenn sie für die Prüfung benötigt werden und ausschließlich zu einem kontrollierten Demo-Konto führen. Teile keine API-Keys, Admin-Tokens, Produktionsdaten oder andere Infrastruktur-Secrets.
Brauche ich Notes, wenn die App keinen Login hat?
Nicht zwingend ausführlich. Nenne dennoch nicht offensichtliche Funktionen, Käufe, Hardware- oder Regionsvoraussetzungen und relevante Änderungen. Leere oder irrelevante Boilerplate ist schlechter als eine kurze präzise Note.
Kann ich nach einer Ablehnung einen Screenshot statt eines neuen Builds senden?
Ein Screenshot kann Kontext belegen, ersetzt aber keinen nötigen Code- oder nativen Konfigurationsfix. Bei reinen Metadatenproblemen kann derselbe Build nach der Korrektur erneut eingereicht werden.