Apple hat aufgeschrieben, wie App Review funktioniert. Das würde ich ändern, bevor ich einreiche

Das meiste, was ich über App Review weiß, habe ich aus Ablehnungs-E-Mails gelernt. Als also Apples Hello Developer vom November 2026 „Browse new App Review help articles“ sagte, habe ich alle gelesen. Sie stehen jetzt an einem Ort, App Review Help, und sagen laut vieles, was bisher Folklore war.

Das steht darin, was für eine Mac-App wichtig ist, und das würde ich vor meiner nächsten Einreichung ändern.

Zuerst: für wen das ist

App Review prüft nur, was über App Store Connect läuft: den Mac App Store, TestFlight, In-App-Käufe und den Rest. Wenn du deine Mac-App mit einer Developer ID von deiner eigenen Website aus verkaufst, prüft sie bei Apple niemand. Sie durchläuft die Notarisierung, eine automatische Prüfung. Wenn du also nur direkt vertreibst, überflieg das hier und heb es dir für den Tag auf, an dem du eine Mac-App-Store-Version dazunimmst.

Wie lange eine Prüfung dauert

Der Artikel zum Prüfstatus nennt Apples eigenes Ziel: mindestens 50 % der Einreichungen in weniger als 24 Stunden prüfen und 90 % in weniger als 48 Stunden. Er sagt auch, was eine Prüfung verlangsamt, etwa ein kurzer Prüfverlauf, Dokumente, die Apple braucht, oder komplexe oder neuartige Probleme.

Das würde ich tun: einen Launch-Tag mit zwei freien Tagen davor planen, bei einer ersten App mehr. Und früh einreichen, mit manueller Veröffentlichung, damit du die Minute wählen kannst, in der sie live geht.

Im Notes-Feld werden Prüfungen gewonnen

Der Artikel zur vollständigen Prüfung ist deutlich: „Incomplete submissions will be rejected.“ Die Details, auf die es ankommt:

• Demo-Logins müssen funktionieren, wenn die Prüfung beginnt, nicht nur beim Einreichen. Ein Testaccount, der dazwischen abläuft oder sich ändert, kann dir eine Ablehnung einbringen.
• Wenn der Login einen Code braucht, schreib ihn in Notes. Ohne ihn muss Apple eventuell anrufen, und Anrufe werden meist innerhalb von drei bis fünf Werktagen erledigt. Das ist eine Woche weg.
• Abos brauchen einen Demo-Account mit abgelaufenem Abo, damit die prüfende Person den ganzen Kaufablauf sieht.

Das würde ich tun: das Notes-Feld wie eine kurze Anleitung für einen Fremden schreiben. Wo man zuerst klickt, welchen Account man nimmt und was das Menüleistensymbol macht, wenn deine App kein Fenster hat. Das Letzte ist sehr Mac.

Wenn sie abgelehnt wird

Das ist der Teil, den ich gern schon vor Jahren schriftlich gehabt hätte.

• Reiche nicht erneut ein, um eine Frage zu beantworten. Wenn App Review Informationen anfordert, antworte in App Store Connect. Reiche nur für eine Korrektur im Build erneut ein, und erst, wenn du alle genannten Probleme behoben hast.
• Such oben nach „Bug Fix Submissions:“. Beginnt eine Ablehnung mit dieser Notiz, sagt der Artikel zu Bug Fix Submissions, dass du antworten kannst, um sie anzunehmen, und das Problem im nächsten Update behebst. Reiche nicht erneut ein. Das klappt nur bei Apps, die schon einmal freigegeben wurden, nie bei rechtlichen oder Sicherheitsproblemen, und ein Problem lässt sich nicht zweimal aufschieben.
• Beschleunigte Prüfung nur, wenn es wirklich nötig ist. Apple sagt, Anfragen für eine beschleunigte Prüfung „sollten echten Dringlichkeitsfällen vorbehalten sein“, und nur für Builds, die schon zur Prüfung eingereicht sind. Hängt ein Launch an einem Event, schreib das Event und sein Datum in Notes.
• Einspruch zuletzt. Antworte zuerst auf die Ablehnung und erkläre dich. Hilft das nicht, nimmt das App Review Board einen Einspruch pro App an, und sobald du erneut eingereicht hast, kannst du gegen diese Ablehnung keinen Einspruch mehr einlegen.

Vier Regeln, mit Zahlen

Die Guideline-Artikel sind kurz und konkret.

• Screenshots, 2.3.3. Mehr als die Hälfte deiner Screenshots muss die App im Einsatz zeigen, gezählt pro Gerätetyp. Bei drei Screenshots müssen zwei die App zeigen. Ein Startbildschirm oder eine Titelkarte ist in Ordnung, solange sie in der Minderheit bleibt. Der Screenshot-Checker von MacPip prüft die Größen, und den Rest kannst du selbst zählen.
• Nachahmer, 4.1. Schreib keine Namen beliebter Apps oder markenrechtlich geschützte Begriffe in ein Metadatenfeld. Das gilt auch für deine Keywords, wo der Name eines Konkurrenten der klassische Ausrutscher ist. Der App-Store-Keyword-Checker zählt deine Felder, damit du siehst, was drinsteht.
• Purpose Strings, 5.1.1(ii). Jede geschützte Ressource braucht ihren eigenen, klaren Purpose String, lokalisiert, wenn deine App es ist. Apples eigenes schlechtes Beispiel ist „To use location.“ Und du bist auch dafür verantwortlich, was deine SDKs anfragen. Füg deine Info.plist in den Info.plist-Erklärer ein, dann markiert er leere und vage Einträge.
• Account löschen, 5.1.1(v). Wenn man in deiner App einen Account anlegen kann, muss man auch das Löschen direkt in der App starten können. Deaktivieren reicht nicht, und du kannst die Leute nicht zwingen, dich anzurufen. Gibt es ein Abo, sag ihnen, dass die Abrechnung über Apple weiterläuft, bis sie kündigen.

Die eine Zeile zum Mac

Nur der Artikel zu kompatiblen Geräten nennt den Mac. Er sagt, dass kompatible iPhone- und iPad-Apps unverändert auf Macs mit Apple silicon laufen können, und dass Apps, die auf Touch-Bedienung setzen, die mit einer Tastatur nicht geht, für macOS nicht gut geeignet sind. Wenn du eine iPad-App machst, prüf, ob sie im Mac App Store auftaucht, und schalte das ab, wenn sie mit Tastatur und Trackpad nicht gut funktioniert. Dieselbe Seite sagt, dass TestFlight bis zu 100 interne und 10.000 externe Tester zulässt und dass der erste Build, den du externen Testern gibst, ebenfalls zu App Review geht.

What's New zählt auch

Noch eins, aus den Guidelines und nicht aus den neuen Artikeln. Guideline 2.3.12 besagt, dass dein What's-New-Text neue Funktionen und Änderungen beschreiben muss, und nur einfache Fehlerbehebungen und Performance-Arbeit mit einer allgemeinen Zeile durchkommen. „Bug fixes and improvements“ bei einer Version mit neuer Funktion lädt zu einer Rückfrage ein.

Das neue kostenlose Tool von heute ist deshalb der Release-Notes-Formatierer. Füg grobe Notizen oder deine git log --oneline-Zeilen ein. Er sortiert sie in Neu, Verbessert und Behoben, lässt chore-, ci- und Merge-Zeilen weg, markiert Ticketnummern und Dateinamen, prüft das Limit von 4.000 Zeichen und gibt dir drei Kopien: Klartext für App Store Connect, HTML für deinen Sparkle-Appcast und Markdown für GitHub. Deine Notizen bleiben in deinem Browser. Der Sparkle-Appcast-Checker liegt gleich daneben, für den Feed, in den sie kommen.

Meine Kurzliste

1. Zwei freie Tage vor dem Launch-Tag und eine manuelle Veröffentlichung.
2. Ein Notes-Feld, dem ein Fremder folgen kann, mit einem funktionierenden Demo-Account.
3. Antworten statt erneut einreichen, wenn nur eine Frage gestellt wird.
4. Zähl die Screenshots, lies jeden Purpose String und halte die Namen anderer Apps aus den Keywords heraus.
5. Ein What's New, das sagt, was sich geändert hat.

Und sobald sie draußen ist, ist der Eintrag bei MacPip kostenlos, im Mac App Store oder nicht. Einträge werden beim Einreichen automatisch geprüft, und ein blauer Haken heißt nur, dass eine Person die App an einem Datum ausprobiert hat.

Quellen

• Apple Developer: Hello Developer, November 2026
• Apple Developer: App Review Help
• App Review Help: Den Prüfstatus einer Einreichung verfolgen
• App Review Help: Informationen für eine vollständige Prüfung bereitstellen
• App Review Help: Bug-Fix-Submission-Angebote annehmen
• App Review Help: Eine beschleunigte Prüfung anfragen
• App Review Help: Einspruch beim App Review Board einlegen
• App Review Help: 2.3.3, Deine App mit Screenshots im Einsatz zeigen
• App Review Help: 4.1, Ablehnungen wegen Nachahmung und Identitätsvortäuschung vermeiden
• App Review Help: 5.1.1(ii), Klare Purpose Strings schreiben
• App Review Help: 5.1.1(v), Das Löschen von Accounts in deiner App anbieten
• App Review Help: Deine App auf kompatiblen Geräten testen
• Apple Developer: App Review Guidelines

Weiterlesen

• Claude Fable 5.2 und Mythos 5.2: was neu ist, die Benchmarks und was das für deinen Mac bedeutetClaude Fable 5.2 und Mythos 5.2 sind am 9. November 2026 erschienen. Anthropics Benchmarks als Diagramme, die Preise, was sich auf dem Mac ändert, und vier kostenlose Tools.
• Die Swift Student Challenge nimmt jetzt Mac-Apps an. Das würde ich bauenDie Swift Student Challenge 2027 von Apple läuft vom 8. Februar bis 28 und nimmt zum ersten Mal Apps für jede Apple-Plattform an, macOS eingeschlossen. Die Regeln, die Termine und wie ich einen Mac-Beitrag planen würde.
• macOS 27.2.1 sorgt dafür, dass curl eMudhra nicht mehr vertraut. Das würde ich in meiner Mac-App prüfenmacOS 27.2.1, 26.7.3 und 15.8.3 entfernen nach der Kompromittierung der eMudhra-Schlüssel fünf Root-Zertifikate aus /etc/ssl/cert.pem. Was sich geändert hat, wen es betrifft und was Maker von Mac-Apps testen sollten.
• Live Activities kommen in die Menüleiste des Mac. Das würde ich mit meiner Mac-App machenDie Beta von macOS 27.3 bringt Live Activities in die Menüleiste von Macs mit Apple silicon, und Mac-Apps können eigene starten. Was sich geändert hat, die Grenzen und was du zuerst ausprobieren kannst.
• Speicher macht Macs teurer. Das würde ich mit meiner Mac-App tunApple sagt, der Speicher wird Macs bis 2027 knapp und teurer halten, und der günstigste Mac hat 8 GB. Warum das für deine Mac-App wichtig ist und welche Checks du diese Woche machen solltest.
• Apple lässt dich jetzt mit Leuten sprechen, die kündigen. Das würde ich mit meiner Mac-App machenSeit dem 4. November können Abos im App Store eine Nachricht oder ein Angebot zeigen, wenn jemand kündigt. Die Regeln, was Apple sagt und was du auf dem Mac prüfen solltest.
• Apple ergänzt zwei Fragen zur Altersfreigabe. Das würde ich mit meiner Mac-App tunAb 16. November fragt App Store Connect nach geteiltem Standort und Dating-Funktionen, und jede App muss bis 12. Januar 2027 antworten. Was sich ändert und was zu tun ist.
• Siri AI steht jetzt allen Entwicklern offen. Das würde ich mit meiner Mac-App machenApple hat Siri AI in der Beta von macOS 27.3 für alle Entwickler geöffnet. Was sich geändert hat, was du schon veröffentlichen kannst und was nicht, und ein kurzer Plan für eine kleine Mac-App.
• Touchscreen-Macs erscheinen am 6. November. Das würde ich in meiner Mac-App prüfenApples erste Touch-Macs erscheinen am 6. November. Was sich geändert hat, was Apple Entwicklern empfiehlt und eine kurze Liste mit Dingen, die du in deiner eigenen Mac-App testen kannst.
• MacPip vorgestelltWas MacPip ist, warum ich es gebaut habe, wie Eintragen und Launch-Tag funktionieren, was ein blauer Haken wirklich bedeutet und die echten Zahlen aus den ersten Tagen.
• Eine Mac-App launchen: eine Checkliste, die auf eine Seite passtWas du vor, am und nach dem Launch-Tag für eine Mac-App tun solltest: Signierung, deine Seite, Verzeichnisse, Product Hunt, Show HN und was du messen solltest.
• So schreibst du eine Ein-Zeilen-Beschreibung, die sagt, was deine Mac-App machtEin einfacher Weg, die eine Zeile unter dem Namen deiner Mac-App zu schreiben: nenne den Zweck, streiche Übertreibungen und teste sie an jemandem, der die App nie gesehen hat.
• Signierung und Notarisierung in einfachen Worten, für Menschen, die ihre erste Mac-App bauenWas Code-Signierung, Notarisierung und Stapling jeweils bewirken, in welcher Reihenfolge, was deine Nutzer ohne sie sehen und wie du deinen eigenen Build prüfst.
• Was ein Dofollow-Link ehrlich wert ist, von einer Seite, die einen anbietetWas Dofollow bedeutet, was Google über Links sagt, warum ein Link von einem neuen Verzeichnis heute wenig wert ist und was du stattdessen tun kannst, anstatt Links zu kaufen.

Deine App einreichenKostenlose Tools für Maker