Was macht new-app-info?
Verwandele Apples „Wir benötigen zusätzliche Informationen“-Anfrage in eine einzige Datei. Der Benutzer antwortet damit in App Store Connect und fügt sie auch in das Notizen-Feld der App-Review-Informationen ein, damit zukünftige Einreichungen sie bereits enthalten. Die Aufnahme ist der einzige Teil, den nur der Benutzer erstellen kann.
Die sechs von Apple geforderten Punkte
Jedes Paket beantwortet alle sechs Punkte, nummeriert 1–6 in dieser Reihenfolge, selbst wenn die Nachricht des Benutzers von Apple fehlt oder anders formuliert ist. Wenn Apples Nachricht einen Punkt hinzufügt oder ändert, folge der Version von Apple und notiere, was anders war.
| # | Apple fragt nach | Beantwortet durch |
|---|---|---|
| 1 | Eine Bildschirmaufnahme, die auf einem physischen Gerät mit dem neuesten Betriebssystem aufgezeichnet wurde. Sie muss mit dem Starten der App beginnen und den typischen Benutzerablauf zeigen, einschließlich, wo die App diese hat: Kontoregistrierung, Anmeldung und Kontolöschung; benutzergenerierte Inhalte mit deren Melde- und Blockierfunktionen; sowie Zugriff auf kostenpflichtige Inhalte oder Funktionen | Teil 1 (die Aufnahmeliste) + Antwort §1 |
| 2 | Zweck und Zielgruppe der App: das Problem, das sie löst, und den Wert, den sie bietet | Antwort §2 |
| 3 | Anweisungen zum Einrichten und Zugreifen auf die Hauptfunktionen, einschließlich erforderlicher Anmeldeinformationen oder Beispieldateien | Antwort §3 |
| 4 | Die externen Dienste, Tools oder Plattformen, die für die Kernfunktionalität verwendet werden (Datenanbieter, Authentifizierung, Zahlungsabwickler, KI-Dienste) | Antwort §4 |
| 5 | Regionale Unterschiede bei Funktionen oder Inhalten oder die Bestätigung, dass die App in allen Regionen gleich funktioniert | Antwort §5 |
| 6 | Für eine stark regulierte Branche oder geschützte Drittanbieter-Inhalte: Dokumentation oder Anmeldeinformationen, die die Autorisierung belegen | Antwort §6 |
Harte Regeln
- Die Aufnahme muss von einem physischen Gerät stammen, auf dem neuesten Betriebssystem, in einem einzigen ungeschnittenen Take in normaler Geschwindigkeit, beginnend mit dem Tippen auf das App-Symbol. Biete niemals eine Simulatoraufnahme oder eine beschleunigte Bearbeitung als Einreichung an. Du kannst das Telefon des Benutzers nicht steuern, daher ist die Aufnahme seine Aufgabe; deine Aufgabe ist die Aufnahmeliste.
- Behaupte nur, was im Build enthalten ist. Jede Funktion, jeder Dienst und jede Sprache müssen aus dem Code stammen, nicht aus Plänen oder Notizen.
- „Nicht zutreffend“ ist ebenfalls eine Antwort. Gib sie in einem Satz mit Begründung (z.B. „Die App hat keine Kontoregistrierung oder Anmeldung“).
- Konten: Wenn Benutzer Konten erstellen können, ist die Kontolöschung erforderlich und muss in der Aufnahme enthalten sein; fehlt sie, melde dies als Hindernis. Wenn es eine Anmeldung gibt, benötigt Punkt 3 Demo-Anmeldedaten (einen Satz pro Kontotyp): Sage dem Benutzer, er solle sie in App Store Connect eingeben. Schreibe niemals echte Passwörter in die Datei.
- Sende, übermittle oder bearbeite niemals etwas in App Store Connect. Der Benutzer fügt die Antwort ein und hängt das Video an.
- Fülle jeden Platzhalter, den du aus dem Repository oder vom Gerät ermitteln kannst. Liste die verbleibenden auf und was jeden füllt.
Schritt 1: Lies die Nachricht von Apple
Wenn der Benutzer eine eingefügt hat, überprüfe ihre nummerierten Punkte anhand der obigen Tabelle und notiere, welche Aufnahmebedingungen (Konten, benutzergenerierte Inhalte, kostenpflichtige Inhalte) für diese App gelten.
Schritt 2: Im Code verankern
Lies den Code des eingereichten Commits, nicht die Arbeitskopie (pinne ihn zuerst, wie in Schritt 6 → Der Review-Build, Schritt 0). Die Arbeitskopie ist oft ein Feature-Branch mit nicht ausgelieferten Funktionen, und deren Beschreibung gegenüber Apple wäre eine Behauptung über einen Build, den sie nicht haben. Verwende git grep <muster> <commit> -- <pfade> und git show <commit>:<pfad>.
Schließe build, Pods, .dart_tool, node_modules und .git bei jeder Suche aus.
| Punkt | Wo suchen |
|---|---|
| 1, 3: Hauptablauf ab Start | Router und Bildschirme; Onboarding; der Kernkreislauf |
| 1, 3: Konten, Anmeldung, Löschung | firebase_auth, sign_in_with_apple, supabase, Auth, login, signUp, deleteAccount, delete.*data |
| 1: Benutzergenerierte Inhalte | Posten, Kommentare, Chat, Uploads; report, block, flag |
| 1, 3: Kostenpflichtige Inhalte | purchases_flutter, revenuecat, StoreKit, product_id, Paywall-Bildschirme. Finde heraus, welche Funktionen gesperrt sind, ob es kostenlose Testversionen gibt, wann die Paywall erscheinen kann und wo „Käufe wiederherstellen“ ist |
| 1: Bildschirmaufnahme-Blockierung | no_screenshot, isSecureTextEntry-Tricks, UIScreen.capturedDidChange, FLAG_SECURE. Ein blockierter Bildschirm erscheint in der Aufnahme leer, daher muss die Antwort erklären, warum |
| 2: Zweck und Zielgruppe | Store-Listing-Text, Marken- oder Voice-Dokumente, README, Launch-Checkliste, Onboarding-Texte (.arb, .strings, strings.xml) |
| 3: Beispieldateien | Dateiimporte, Dokumenten-Picker, QR-/Barcode-Scanner, Hardware, die die App benötigt |
| 4: Externe Dienste | Abhängigkeiten (pubspec.yaml, Podfile, package.json, Gradle) und Build-Defines (--dart-define, Schlüsseldateien, Release-Skripte). Für jeden: was er tut und welche Daten er erhält. Liste nur SDKs auf, die der Release-Build tatsächlich aktiviert |
| 5: Regionen | Ausgelieferte Locales; Regionsprüfungen (locale, countryCode, region); regionsspezifische Preise, Funktionen oder Inhalte |
| 6: Reguliert oder geschützt | Gesundheit, Medizin, Finanzen, Glücksspiel, rechtliche oder Kinderinhalte und Behauptungen; lizenzierte Inhalte, Musik, Bilder, Schriftarten und deren Lizenzen |
| Kontakt | Support-E-Mails in Einstellungen, Datenschutzdokumente und Website-Dateien |
| Plattform | IPHONEOS_DEPLOYMENT_TARGET, TARGETED_DEVICE_FAMILY (nur iPhone oder auch iPad) |
Überprüfe, ob die Formulierung zur Analyse in Punkt 4 mit der Datenschutzrichtlinie im Repository übereinstimmt. Melde es, wenn nicht oder wenn du die Antworten zum App-Datenschutz in App Store Connect nicht bestätigen kannst.
Schritt 3: Das Gerät und das Betriebssystem (Punkt 1)
xcrun devicectl list deviceszeigt gekoppelte Geräte an. Nimm das eigene iPhone des Benutzers, das verfügbar ist.xcrun devicectl device info details --device <id> | grep -i osVersionzeigt seine iOS-Version.- Suche im Internet nach der neuesten iOS-Version. Wenn das Telefon nicht auf dem neuesten Stand ist, sage es: Der Benutzer aktualisiert es in Einstellungen → Allgemein → Softwareupdate vor der Aufnahme, dann liest du die Version erneut aus. Das Betriebssystem des Telefons zu aktualisieren ist Sache des Benutzers.
- Wenn kein Telefon gekoppelt ist, lasse
[iOS version]stehen und sage dem Benutzer, wo er es findet (Einstellungen → Allgemein → Info).
Schritt 4: Häufige Probleme vermeiden
Überprüfe jedes von Apples häufigen Problemen und füge das Ergebnis in den Bericht an den Benutzer ein. Dies sind Überprüfungen für den Benutzer, nicht Teil der Antwort.
| Richtlinie | Überprüfung |
|---|---|
| 2.1 Fehler und Abstürze | Die Aufnahme verwendet den TestFlight-Build der eingereichten Version auf einem echten Gerät. Unterstützte Plattformen aus TARGETED_DEVICE_FAMILY: Wenn iPad unterstützt wird, sage dem Benutzer, er solle auch auf einem iPad testen |
| 2.1 Zugriff auf die App | Anmeldung → Demo-Anmeldedaten werden in App Store Connect eingegeben, ein Satz pro Kontotyp, und funktionieren noch |
| 2.3.3 Screenshots | Liste die Store-Screenshots auf (z.B. app-store-assets/*screenshots*). Markiere alle, die wie nur Titelgrafik, ein Splash oder ein Anmeldebildschirm aussehen |
| 3.1.1 In-App-Kauf | Jede Produkt-ID im Code ist in App Store Connect konfiguriert und dieser Einreichung zugeordnet. Liste die IDs auf, damit der Benutzer sie überprüfen kann |
| 3.2 Andere Geschäftsmodelle | Wenn die App für ein Unternehmen, eine Organisation oder deren Mitarbeiter bestimmt ist, markiere, dass eine andere Vertriebsoption erforderlich ist (benutzerdefinierte Apps oder nicht gelistete Verteilung) |
Schritt 5: Die Datei schreiben
Schreibe app-store-assets/new-app-info.md, falls dieser Ordner existiert, sonst ./new-app-info.md. Behalte diese Form (ein vollständiges Beispiel findest du in examples/seven-minute-math/new-app-info.md):
# App-Review-Informationen — <App-Name>
Antworte in App Store Connect mit Teil 2 und füge die Aufnahme bei. Füge dann Teil 2 in
App-Review-Informationen → Notizen ein, damit zukünftige Einreichungen sie haben.
<Noch auszufüllende Platzhalter, falls vorhanden.>
## Teil 1 — die Bildschirmaufnahme (Punkt 1; nimm dies selbst auf)
Warum: ein physisches Gerät, das neueste Betriebssystem, ein Take, normale Geschwindigkeit, beginnend mit dem Tippen auf das Symbol.
Einrichtung (Standard: ein Release-Build, der vom Mac installiert wurde; siehe „Der Review-Build“ unten):
erstelle einen Sandbox-Tester (App Store Connect → Benutzer und Zugriff → Sandbox → Testkonten);
lösche die App vom Telefon; du baust und installierst den Review-Build; Bildschirmaufnahme im
Kontrollzentrum mit ausgeschaltetem Mikrofon; Bitte-nicht-stören an; melde dich mit dem
Sandbox-Tester bei Apples Kaufblatt an (das Blatt mit „Sandbox“ ist zu erwarten).
Aufnahmeliste, nummeriert: Tippe auf das Symbol → Onboarding → der typische Ablauf von Anfang bis Ende → Ergebnisse →
jede zutreffende Aufnahmebedingung (Registrierung, Anmeldung, Kontolöschung; posten, melden,
blockieren; Paywall, Sandbox-Kauf, die freigeschaltete Funktion, Käufe wiederherstellen) → wie Benutzer ihre Daten löschen → Stopp.
Alle Bildschirme, die leer sein werden (Aufnahmeblockierung) und warum.
## Teil 2 — die Antwort (diese einfügen)
Begrüßung, plus das Gerät und die iOS-Version, auf der die Aufnahme gemacht wurde.
**1. Bildschirmaufnahme** … **6. Regulierte Branche / Drittanbieter-Material**: jeweils ein fett gedruckter Abschnitt.
Abschlusszeile mit der Support-E-Mail.
Schreiben:
- §1: was die Aufnahme zeigt, welche Aufnahmebedingungen nicht zutreffen und warum, sowie alle leeren Bildschirme.
- §2: für wen sie ist, das Problem, wie die App es löst, der Wert. Drei oder vier Sätze.
- §3: was zum Start benötigt wird (Anmeldedaten kommen in App Store Connect, niemals in die Datei), dann die Hauptfunktionen in einer kurzen Liste, mit kostenlos vs. kostenpflichtig und wann die Paywall erscheint.
- §4: ein Aufzählungspunkt pro Dienst mit seiner Funktion. Dann eine Zeile, die sagt, was die App nicht verwendet (KI, Datenanbieter, Auth), wo das zutrifft.
- §5: Sprachen und etwaige regionale Unterschiede oder „funktioniert in jeder Region gleich“.
- §6: Dokumentation oder „Nicht zutreffend“ mit Begründung.
- Sachlich, faktenbasiert und höflich. Keine Marketing-Sprache.
Schritt 6: Das End-to-End-Video (Punkt 1)
Der Review-Build
Nimm einen Release-Build genau der Version auf, die im Review ist, installiert auf dem Telefon direkt vom Mac. Du baust und installierst ihn; der Benutzer nimmt auf.
- Pinne die eingereichte Version. Frage den Benutzer nach der Versions- und Build-Nummer, die in App Store Connect für die im Review befindliche Einreichung angezeigt wird (z.B. 1.0.0 (1)), sofern er sie nicht bereits angegeben hat. Finde den Commit, der sie erstellt hat: ein Release-Tag, der Release- oder Haupt-Branch, eine Commit-Nachricht wie „an den App Store ausgeliefert“ oder der Commit, in dem
pubspec.yaml/Info.plistdiese Version und den Build gesetzt haben. Wenn zwei Commits infrage kommen, frage, welcher es ist. Baue niemals aus der Arbeitskopie: Sie befindet sich oft auf einem Feature-Branch mit nicht committeten Änderungen, die Apple nicht gesehen hat. Baue stattdessen in einem isolierten Worktree (git worktree add --detach <scratch>/review-build <commit>). Kopiere alle von Git ignorierten Schlüsseldateien (z.B.keys.json) mitcphinein, ohne sie zu lesen. Sage dem Benutzer, welchen Commit du baust und was auf neueren Branches ist, das nicht im Video sein wird. - Finde den normalen Geräte-Build des Projekts (Run-Skripte,
tool/*.sh, Makefile, Fastlane). Entferne alle Flags, die Käufe vortäuschen, wieDUMMY_PURCHASES,MOCK,FAKE,USE_TEST_STORE, einen RevenueCattest_-Schlüssel oder eine StoreKit-Konfigurationsdatei. Ein vorgetäuschter Kauf zeigt niemals Apples Blatt, und ein Reviewer, der sieht, dass sich kostenpflichtige Funktionen ohne es freischalten, könnte dies als Umgehung des In-App-Kaufs betrachten (3.1.1). Überprüfe, ob der Kaufschlüssel der Live-Store-Schlüssel ist, nur anhand seines Präfixes (z.B.grep -q '"REVENUECAT_IOS_KEY": "appl_'); gib niemals Schlüsselwerte aus. - Baue im Release-Modus, niemals im Debug-Modus: Debug-Builds von Flutter und React Native können nicht über das Startbildschirm-Symbol geöffnet werden, und Apple möchte, dass die Aufnahme dort beginnt. Flutter:
flutter build ios --releasemit den üblichen Defines des Projekts, abzüglich der vorgetäuschten. - Überprüfe, ob die gebaute App mit der Einreichung übereinstimmt:
/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" -c "Print CFBundleVersion" build/ios/iphoneos/Runner.app/Info.plistmuss die eingereichte Version und den Build ausgeben. Wenn nicht, stoppe und informiere den Benutzer. - Bitte den Benutzer, die App zuerst vom Telefon zu löschen (es löscht seine Daten auf dem Telefon, also ist es seine Entscheidung), dann installiere:
xcrun devicectl device install app --device <id> build/ios/iphoneos/Runner.app. - Von Mac installierte Builds kaufen über Apples Sandbox, daher benötigt der Benutzer einen Sandbox-Tester, um sich beim Kaufblatt anzumelden. Eine TestFlight-Installation derselben Build-Nummer funktioniert ebenfalls (Käufe sind mit der eigenen Apple-ID kostenlos) und garantiert das exakte Binary, das Apple hat. Verwende sie, wenn der Benutzer es bevorzugt.
Aufnahme und Überprüfung
Das Paket ist erst fertig, wenn die Aufnahme existiert und überprüft wurde. Der Benutzer nimmt sie auf; du leitest ihn dabei an. Gib ihm im Chat die Einrichtung von Teil 1 (einschließlich des Sandbox-Testers) und die nummerierte Aufnahmeliste. Bitte ihn, die Datei per AirDrop in app-store-assets/review-recording/ zu übertragen und dir zu sagen, wann sie da ist. Dann:
ffprobe -v error -show_entries format=duration:stream=width,height,codec_name -of default=nw=1 <datei>. Überprüfe, ob die Auflösung einem echten iPhone-Bildschirm entspricht (nicht einem Simulatorfenster oder einer beschnittenen Bearbeitung) und ob die Dauer den gesamten Ablauf abdeckt.- Erstelle ein Kontaktblatt mit einem Bild alle 10 Sekunden:
ffmpeg -i <datei> -vf "fps=1/10,scale=240:-1,tile=8x8" -frames:v 1 <verzeichnis>/contact.png. Speichere auch das erste Bild separat. Lese beide. - Überprüfe der Reihe nach: Das erste Bild zeigt den Startbildschirm oder das Antippen des App-Symbols; jeder Schritt der Aufnahmeliste ist sichtbar.
Bevor du die Datei schreibst, prüfe, dass das Gerät (iPhone) und die iOS-Version korrekt sind. Ersetze [iOS version] durch die tatsächliche Version, z.B. 18.2.1.
Schritt 7: Abschließen
Gehe alle noch leeren Platzhalter durch. Wenn einer übrig ist, den du nicht füllen konntest, schreibe einen klaren Hinweis darauf, z.B. „[Von dir auszufüllen: Screenshot-Dateinamen prüfen]“. Überprüfe die Datei auf Tippfehler und unvollständige Sätze. Gib einen kurzen Überblick darüber, was in der Antwort steht und dass der Benutzer jetzt die Aufnahme machen und die Antwort in App Store Connect einfügen muss, sobald die Aufnahme fertig ist.