CommunityCodierung & Entwicklunggithub.com

new-app-info

Erstellt das Informationspaket, das Apple anfordert, wenn die App-Review mit „Wir benötigen zusätzliche Informationen, um die App besser zu verstehen“ antwortet. Es deckt alle sechs geforderten Punkte ab.

Was ist new-app-info?

Diese Fähigkeit hilft Entwicklern, effizient auf Apples Anfrage nach zusätzlichen Informationen im App-Review-Prozess zu reagieren. Sie erstellt eine strukturierte Antwortdatei, die alle sechs von Apple geforderten Punkte abdeckt: eine Bildschirmaufnahme auf einem physischen Gerät, den Zweck und die Zielgruppe der App, Einrichtung und Hauptfunktionen, genutzte externe Dienste, regionale Unterschiede sowie regulierte Branchen oder geschützte Drittanbieter-Inhalte. Die Fähigkeit analysiert den Quellcode der App, um präzise und faktenbasierte Antworten zu generieren, führt Apples „Häufige Probleme vermeiden“-Prüfungen durch, liest die iOS-Version des verbundenen iPhones und stellt sicher, dass diese aktuell ist. Sie endet mit der Anweisung, die Antwort in App-Review-Informationen → Notizen einzufügen. Unterstützt werden Plattformen wie Claude Code, Cursor und Codex, und die Ausgabe erfolgt als Markdown-Datei (app-store-assets/new-app-info.md oder ./new-app-info.md).

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/jamesisbuilding/App-Building-Skills/tree/main/skills/new-app-info

Installed? Explore more Codierung & Entwicklung skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

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 nachBeantwortet durch
1Eine 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 FunktionenTeil 1 (die Aufnahmeliste) + Antwort §1
2Zweck und Zielgruppe der App: das Problem, das sie löst, und den Wert, den sie bietetAntwort §2
3Anweisungen zum Einrichten und Zugreifen auf die Hauptfunktionen, einschließlich erforderlicher Anmeldeinformationen oder BeispieldateienAntwort §3
4Die externen Dienste, Tools oder Plattformen, die für die Kernfunktionalität verwendet werden (Datenanbieter, Authentifizierung, Zahlungsabwickler, KI-Dienste)Antwort §4
5Regionale Unterschiede bei Funktionen oder Inhalten oder die Bestätigung, dass die App in allen Regionen gleich funktioniertAntwort §5
6Für eine stark regulierte Branche oder geschützte Drittanbieter-Inhalte: Dokumentation oder Anmeldeinformationen, die die Autorisierung belegenAntwort §6

Harte Regeln

  1. 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.
  2. 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.
  3. „Nicht zutreffend“ ist ebenfalls eine Antwort. Gib sie in einem Satz mit Begründung (z.B. „Die App hat keine Kontoregistrierung oder Anmeldung“).
  4. 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.
  5. Sende, übermittle oder bearbeite niemals etwas in App Store Connect. Der Benutzer fügt die Antwort ein und hängt das Video an.
  6. 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.

PunktWo suchen
1, 3: Hauptablauf ab StartRouter und Bildschirme; Onboarding; der Kernkreislauf
1, 3: Konten, Anmeldung, Löschungfirebase_auth, sign_in_with_apple, supabase, Auth, login, signUp, deleteAccount, delete.*data
1: Benutzergenerierte InhaltePosten, Kommentare, Chat, Uploads; report, block, flag
1, 3: Kostenpflichtige Inhaltepurchases_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-Blockierungno_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 ZielgruppeStore-Listing-Text, Marken- oder Voice-Dokumente, README, Launch-Checkliste, Onboarding-Texte (.arb, .strings, strings.xml)
3: BeispieldateienDateiimporte, Dokumenten-Picker, QR-/Barcode-Scanner, Hardware, die die App benötigt
4: Externe DiensteAbhä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: RegionenAusgelieferte Locales; Regionsprüfungen (locale, countryCode, region); regionsspezifische Preise, Funktionen oder Inhalte
6: Reguliert oder geschütztGesundheit, Medizin, Finanzen, Glücksspiel, rechtliche oder Kinderinhalte und Behauptungen; lizenzierte Inhalte, Musik, Bilder, Schriftarten und deren Lizenzen
KontaktSupport-E-Mails in Einstellungen, Datenschutzdokumente und Website-Dateien
PlattformIPHONEOS_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)

  1. xcrun devicectl list devices zeigt gekoppelte Geräte an. Nimm das eigene iPhone des Benutzers, das verfügbar ist.
  2. xcrun devicectl device info details --device <id> | grep -i osVersion zeigt seine iOS-Version.
  3. 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.
  4. 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ürzeDie 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 AppAnmeldung → Demo-Anmeldedaten werden in App Store Connect eingegeben, ein Satz pro Kontotyp, und funktionieren noch
2.3.3 ScreenshotsListe 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-KaufJede 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äftsmodelleWenn 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.

  1. 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.plist diese 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) mit cp hinein, ohne sie zu lesen. Sage dem Benutzer, welchen Commit du baust und was auf neueren Branches ist, das nicht im Video sein wird.
  2. Finde den normalen Geräte-Build des Projekts (Run-Skripte, tool/*.sh, Makefile, Fastlane). Entferne alle Flags, die Käufe vortäuschen, wie DUMMY_PURCHASES, MOCK, FAKE, USE_TEST_STORE, einen RevenueCat test_-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.
  3. 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 --release mit den üblichen Defines des Projekts, abzüglich der vorgetäuschten.
  4. Ü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.plist muss die eingereichte Version und den Build ausgeben. Wenn nicht, stoppe und informiere den Benutzer.
  5. 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.
  6. 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:

  1. 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.
  2. 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.
  3. Ü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.

Individual skills in this repo

This repo contains 6 individual skills — each has its own dedicated page.

app-icon-design

Create, revise, and audit app icons using Apple's Human Interface Guidelines, with a clear visual identity and production-ready deliverables.

app-keyword-research

Validate an app idea against the App Store before building it. Turns the idea into search phrases, measures demand (App Store autocomplete) and competition (current top-10 apps) for each, ranks keywords by opportunity, and maps which apps own the market. Use when the user wants keyword research, ASO, "is there demand for…", "who are the competitors for…", "what should we call it / which keywords", or to validate or compare app ideas.

app-offer

Designs one opinionated "Grand Slam Offer" for any app idea, new or already shipped, by running Alex Hormozi's $100M Offers method adapted to app stores. It covers the market and niche, the commodity check, a value-equation audit, the problem inventory, delivery vehicles, the trimmed value stack, pricing and tiers, scarcity, urgency, bonuses, the guarantee, naming, the paywall per placement, the onboarding fast win, a test plan and a ship plan. It works within App Store and Google Play rules. For a shipped app it reads the code and notes first and produces a before/after. Use it when the user says "/app-offer", "run app-offer on <idea>", "make a grand slam offer for my app", "Hormozi my app", "price my app" or "design my paywall offer", or asks how to package, price, name, guarantee or paywall an app. It writes offer/grand-slam-offer.md (or ./<app-slug>-grand-slam-offer.md for a new idea).

brand-reference-pack

Build or refresh a shortform brand reference pack for any app from its real surfaces — website, App Store listing and reviews, socials, the live app (driven end to end on the simulator) and its code tokens — plus a status check of the upstream foundations (ICP, voice of customer, brand voice). Produces the context that content formats and design decisions are made from, as markdown, tokens.json and a PDF. Use for "build a brand pack for <app>", "refresh the brand pack", "capture the site/app/socials for shortform", "/brand-reference-pack".

deep-work

Timekeeper and scribe for the user's own timeboxed build session, default 90 min, also 1h / 1.5h / 2h (Orient, Build, Verify, Harden, Close, scaled to the block). Use when the user says "start a session", "deep work", "90 min block", "work block", or invokes /deep-work. Subcommands: status, park <note>, close, abort.

reel-motion-graphics

Turn a script or concept into an on-brand 9:16 explainer reel (luxury tech, warm sand on near-black, glassmorphism, CSS 3D, Bodoni + Instrument Sans) built in HyperFrames, with the animation above the fold and the presenter's talking head below. Use when the user gives a script, transcript, paper summary or concept and asks for a reel, motion graphics, an animated explainer or "the same style as the upcycling reel". Produces a HyperFrames project, a rendered MP4 and a live artifact player.

Verwandte Skills