Was App Store Review Teams wirklich kostet

Alle 111 Stories werden angezeigt.

1. 

   4.3(a) Spam iOS Richtlinie 4.3

   Ein ganzes Portfolio auf einmal geflaggt

   Was passiert ist

   Ein Entwickler mit mehreren Apps, die aus demselben Starter-Projekt gebaut wurden, erhielt für jede davon die identische 4.3-Meldung: Die Apps hatten eine ähnliche Binary, Metadaten oder ein ähnliches Konzept mit nur minimalen Unterschieden. Er entschied sich, die Apps nacheinander abzuarbeiten.

   Lösung

   Zum Zeitpunkt des Posts noch in Arbeit.

   Lektion

   4.3(a) deckt auch Überschneidungen zwischen eigenen Apps ab. Wenn mehrere Apps auf einem Template basieren, braucht jede einen wirklich eigenständigen Kern, nicht nur ein neues Icon und einen neuen Namen.

2. 

   4.3(a) Spam iOS Richtlinie 4.3

   Zweimal derselbe Ablehnungstext in einer Woche

   Was passiert ist

   Eine kleine, spezialisierte Foto-Hilfs-App wurde mitten in der Nacht unter 4.3(a) abgelehnt – eine Woche, nachdem bereits ein früherer Build exakt denselben Ablehnungstext erhalten hatte.

   Lösung

   Nicht angegeben.

   Lektion

   Ein erneutes Einreichen mit nur kosmetischen Änderungen kippt eine 4.3-Entscheidung selten. Ändere das Konzept oder erkläre in den Review-Notizen klar, was die App anders macht.

3. 

   4.3 Design / Spam iOS Richtlinie 4.3

   Entwicklung in einer überfüllten Kategorie

   Was passiert ist

   Ein Solo-Entwickler, der eine tägliche Build-Challenge dokumentierte, erhielt am vierten Tag eine Ablehnung wegen 4.3 Design / Spam und fragte sich, ob die Wahl einer gesättigten Kategorie ein Fehler war.

   Lösung

   Nicht angegeben.

   Lektion

   Kategorien, die Apple als gesättigt einstuft, werden strenger geprüft. Prüfe vor dem Build, was deine App anders macht – nicht erst nach dem Review.

5. 

   2.1 Benötigte Informationen iOS Richtlinie 2.1

   Sieben Fragen zu einem neuen Account

   Was passiert ist

   Die allererste Submission eines Teams kam mit 2.1 Information Needed zurück: sieben Fragen, die Bitte um ein Screen-Recording und einen Demo-Account. Ehrliche Antworten brachten vier Punkte ans Licht, die sie übersehen hatten.

   Lösung

   Sie behoben die Probleme und antworteten.

   Lektion

   Neue Developer-Accounts sollten damit rechnen. Bereitet einen Demo-Account, ein Recording und klare Review-Notizen vor, bevor ihr einreicht.

6. 

   2.1 App-Vollständigkeit iOS Richtlinie 2.1

   Der Reviewer konnte die App nicht nachvollziehen

   Was passiert ist

   Ein Entwickler, der zum ersten Mal eine App einreichte, wurde zweimal abgelehnt, bevor sie live ging. Die erste Ablehnung nach Richtlinie 2.1 kam, weil der Reviewer nicht erkennen konnte, wie die App genutzt werden sollte.

   Lösung

   Genehmigt, nachdem wir ein Demo-Video von einem echten Gerät und schrittweise Review-Notizen hinzugefügt haben.

   Lektion

   Reviewer haben Minuten, keinen Kontext. Sagen Sie ihnen genau, was sie antippen sollen und was sie sehen sollten.

7. 

   Metadaten und In-App-Kauf-Setup iOS Metadaten und IAP

   Zwei Ablehnungen wegen bekannter Checklistenpunkte

   Was passiert ist

   Ein Indie-Entwickler wurde zweimal wegen Dingen abgelehnt, die er bereits kannte. Zuerst wurde der Build ohne die zugehörigen In-App-Käufe eingereicht, und in der Beschreibung fehlte der Link zu den Nutzungsbedingungen. Wochen später bezeichnete ein Screenshot die App als kostenlos.

   Lösung

   Jedes Mal korrigiert und erneut eingereicht.

   Lektion

   Halte eine Pre-Submission-Checkliste für Metadaten, Abonnements und rechtliche Links bereit. Die meisten Metadaten-Ablehnungen sind vermeidbar.

8. 

   Review-Wartezeiten iOS Endlose Reviews

   9 Tage Wartezeit, dann 8 Tage in der Prüfung

   Was passiert ist

   Ein Entwickler wartete neun Tage, bis der Status von „Wartend auf Prüfung“ auf „In Prüfung“ wechselte, und saß dann weitere acht Tage in der Prüfung ohne jede Aktualisierung.

   Lösung

   Zum Zeitpunkt des Posts keine.

   Lektion

   Prüfzeiten sind nicht garantiert. Verknüpfe niemals ein Launch-Datum, eine Presse- oder Creator-Kampagne mit einem erwarteten Freigabedatum.

9. 

   Review-Wartezeiten iOS Endlose Reviews

   20 Tage im Reject-Fix-Wait-Loop

   Was passiert ist

   Mehr als 20 Tage lang durchlief ein Entwickler Ablehnung, Fix, Waiting for Review, Ablehnung, Fix – und wartete zum Zeitpunkt des Posts noch immer.

   Lösung

   Ausstehend.

   Lektion

   Jeder Roundtrip kann Tage kosten. Bündle alle Fixes aus einer Ablehnungsnachricht in einen einzigen Build.

10. 

    Account-Kündigung iOS Account-Kündigung

    Vor der ersten Review geschlossen

    Was passiert ist

    Einem Entwickler mit zehn Jahren Erfahrung wurde der Developer-Account gesperrt – mit einer Betrugsbeschuldigung, die nicht sagte, was er getan hatte –, während ein Sprachlernspiel noch auf seine allererste Review wartete. Seine bestehenden Apps verschwanden und Kunden fragten nach dem Warum.

    Lösung

    Keine gemeldet.

    Lektion

    Eine Account-Sperrung entfernt alle Apps auf einmal. Halte einen eigenen Kanal zu deinen Nutzern (E-Mail, Website) offen, damit du sie erreichen kannst, falls der Store verschwindet.

11. 

    Warnung vor Account-Sperrung iOS Account-Kündigung

    Zu viele abgelehnte Versionen

    Was passiert ist

    Ein äußerst produktiver Indie-Entwickler erhielt die Mitteilung, dass sein Account in zehn Tagen beendet würde. Apple nannte die Zahl der abgelehnten Versionen als einen der Gründe. Nach öffentlicher Aufmerksamkeit und einem Einspruch wurde der Account nicht beendet.

    Lösung

    Account nach Einspruch gerettet.

    Lektion

    Ablehnungen summieren sich. Vermeide Resubmits am selben Tag mit Ein-Wort-Änderungen oder nahezu identischen Klonen deiner eigenen Apps.

12. 

    Login-Pflicht (Richtliniennummer nicht angegeben) iOS Login-Pflicht

    Registrierung erforderlich: Du bist nicht diese große App

    Was passiert ist

    Die Social App eines Entwicklers wurde abgelehnt, weil Nutzer ein Konto erstellen mussten, bevor sie den Home-Feed sehen konnten. Als der Entwickler erklärte, dass jeder User einen Handle benötigt, damit die App überhaupt funktioniert, und auf ein großes Fotonetzwerk verwies, das dasselbe macht, entgegnete der Reviewer im Grunde, dass seine App nicht dieses Netzwerk sei.

    Lösung

    Nicht angegeben.

    Lektion

    Was große Apps durchkommen lassen, ist kein Präzedenzfall, auf den man sich berufen kann. Wenn eine Registrierung nötig ist, erkläre in den Review-Notizen, warum die Kernfunktion ohne Account nicht funktioniert, und überlege, Reviewern oder Gästen zuerst etwas Content zu zeigen.

13. 

    4.3 Spam iOS Richtlinie 4.3

    Von gar keinem Review zu fast alles abgelehnt

    Was passiert ist

    Ein Entwickler bekam tagelang keine seiner Apps durch den Review. Während er etwa eine Woche wartete, reichte er immer mehr Submissions ein. Als der Review endlich in Gang kam, kamen fast alle mit Ablehnung wegen Guideline 4.3 (Spam) zurück.

    Lösung

    Nicht angegeben.

    Lektion

    Eine stockende Queue ist kein Signal, mehr einzureichen. Submissions anzuhäufen, während nichts geprüft wird, kann deinen Account nach einem Spam-Muster aussehen lassen, sobald ein Reviewer sie endlich zusammen sieht.

14. 

    4.3 Spam iOS Richtlinie 4.3

    Unabhängige Apps gemeinsam abgelehnt

    Was passiert ist

    Ein Entwickler hatte mehrere Apps, die über Monate hinweg entwickelt wurden und nichts miteinander zu tun hatten. Alle wurden im selben Moment als Spam abgelehnt. Er fragte öffentlich, ob das normal sei.

    Lösung

    Nicht angegeben.

    Lektion

    4.3 kann auf Account-Ebene angewendet werden, nicht App für App. Wenn mehrere Apps gleichzeitig abgelehnt werden, beantworte jede einzeln und erkläre in den Review-Notizen genau, was jede App unterscheidet.

15. 

    Review-Wartezeiten iOS Endlose Reviews

    Eine Ablehnung, dann zwei Monate Funkstille

    Was passiert ist

    Nach einer einzigen Ablehnung hing die App eines Entwicklers etwa zwei Monate im Review fest, wobei jeder Review-Zyklus rund einen Monat dauerte. Sie vermuteten, dass lange Zyklen zu einem Mittel geworden waren, um neue Apps fernzuhalten.

    Lösung

    Zum Zeitpunkt des Posts immer noch festgefahren.

    Lektion

    Nach einer Ablehnung kann der nächste Zyklus deutlich langsamer ablaufen als der erste. Sorge dafür, dass deine Resubmission vollständig und gut dokumentiert ist, damit du nicht noch einen Monat für eine zweite Runde verschwendest.

16. 

    Anstößige Inhalte iOS Anstößige Inhalte

    Abgelehnt: erneut ohne Fix eingereicht

    Was passiert ist

    Eine KI-Foto-Editing-App wurde abgelehnt, weil sie mehrfach eingereicht wurde, ohne das von Apple gemeldete Problem – anstößige Inhalte – zu beheben.

    Lösung

    Abgelehnt.

    Lektion

    Denselben Build erneut einzureichen und auf einen anderen Reviewer zu hoffen, kann dir negativ ausgelegt werden. Behebe das gemeldete Problem oder frage über das Resolution Center nach einer Klärung, bevor du erneut einreichst. Füge bei generativen KI-Funktionen Filter für Inhalte hinzu, die Apple als anstößig einstuft.

17. 

    4.3 Spam iOS Richtlinie 4.3

    Ablehnung in derselben Minute wie der Review-Start

    Was passiert ist

    Ein Entwickler arbeitete wochenlang an einer App und wurde in derselben Minute, in der der Review begann, wegen 4.3 Spam abgelehnt. Er glaubte, der Reviewer habe die Nische bewertet, nicht die App.

    Lösung

    Nicht angegeben.

    Lektion

    In überfüllten Nischen kommt eine 4.3-Ablehnung oft, bevor überhaupt jemand genau hinsieht. Beginne deine Review-Notizen mit dem Alleinstellungsmerkmal und weise den Reviewer direkt darauf hin.

18. 

    4.2.6 Vorlage iOS Richtlinie 4.2.6

    Geflaggt wegen eines nie genutzten Templates

    Was passiert ist

    Ein Team wurde wegen Richtlinie 4.2.6 abgelehnt, die Apps aus kommerziellen Templates oder App-Generatoren regelt – obwohl sie weder ein Template noch einen Generator genutzt haben.

    Lösung

    Nicht angegeben.

    Lektion

    4.2.6 kann ein False Positive sein. Antworte im Resolution Center klar, dass die App individuell entwickelt wurde und wer sie gebaut hat, und biete an, den Quellcode oder die Entwicklungshistorie zu zeigen.

19. 

    3.1.2 Abonnements iOS Richtlinie 3.1.2

    Der monatliche Preis war höher als der abgerechnete Preis

    Was passiert ist

    Ein Entwickler-Paywall wurde abgelehnt, weil der berechnete Monatspreis eines längeren Abonnements prominenter dargestellt war als der tatsächlich abgerechnete Betrag. Derselbe Paywall war bei früheren Reviews ohne Anmerkungen durchgegangen. Sie stimmten der Regel zu, waren aber frustriert, dass sie erst jetzt bemängelt wurde, und gestalteten den Paywall so um, dass der abgerechnete Betrag im Vordergrund steht.

    Lösung

    Mit dem neuen Design erneut eingereicht.

    Lektion

    Ein Paywall, der zuvor bestanden hat, kann später trotzdem abgelehnt werden. Stellen Sie immer den abgerechneten Betrag und den Zeitraum als prominentesten Preis dar; zeigen Sie eine monatliche Aufschlüsselung kleiner und sekundär.

20. 

    Registrierung (keine App-Review-Richtlinie) Apple Developer Program Registrierung und Account

    Zwei Monate, dann eine Ablehnung ohne Grund

    Was passiert ist

    Ein Entwickler verbrachte über zwei Monate mit dem Versuch, sich zu registrieren – inklusive mehrerer Support-Anrufe und E-Mails, Identitätsverifizierung, Geräteinformationen und sogar Video-Beweisen. Apple lehnte die Registrierung dann ab, ohne einen konkreten Grund anzugeben.

    Lösung

    Zum Zeitpunkt der Veröffentlichung keine.

    Lektion

    Die Registrierung kann deutlich länger dauern als der App-Entwicklungsprozess. Beginnen Sie frühzeitig, bevor Ihr Launch-Plan davon abhängt, und dokumentieren Sie jeden Support-Kontakt.

21. 

    5.1.2 Datennutzung und -freigabe iOS Richtlinie 5.1.2

    Eine App Tracking Transparency-Ablehnung, die ein Startup bedrohte

    Was passiert ist

    Nach einigen Monaten schnellem Shipping und starkem User-Feedback wurde die App eines Startups im späten Herbst wegen App Tracking Transparency abgelehnt – der iOS-Privacy-Regel, die vor dem Tracking über Apps und Websites hinweg die Erlaubnis der Nutzer erfordert. Der Gründer beschrieb die Ablehnung später als eine, die das gesamte Unternehmen in Gefahr brachte.

    Lösung

    Nicht im Beitrag angegeben.

    Lektion

    Prüfe jedes SDK in deiner App auf Tracking, bevor du einreichst. Wenn etwas Nutzerdaten mit Daten anderer Unternehmen verknüpft, brauchst du den Tracking-Erlaubnis-Prompt und passende Privacy-Labels – selbst wenn das Tracking von einer Third-Party-Bibliothek stammt.

22. 

    Login (Richtliniennummer nicht angegeben) iOS Anmelden

    Reviewer konnte sich nicht mit Apple oder Google anmelden

    Was passiert ist

    Um Bot-Registrierungen zu verhindern, hat ein Entwickler die E-Mail- und Passwort-Anmeldung entfernt und nur Sign in with Apple und Google Sign-In beibehalten. Auf seinem eigenen iPhone und iPad funktionierte es, und auch beim vorherigen Reviewer, der die App aus einem anderen Grund abgelehnt hatte. Der nächste Reviewer lehnte sie ab, weil er sich nicht anmelden konnte.

    Lösung

    Nicht angegeben.

    Lektion

    Wenn deine App nur Social Login anbietet, können Reviewer trotzdem hängen bleiben. Gib ihnen in den Review Notes einen funktionierenden Weg, z. B. ein Demo-Konto oder einen Login nur für den Review, und teste die Anmeldung vor jeder Einreichung auf einem frischen Gerät und Konto.

23. 

    Simuliertes Glücksspiel (Richtliniennummer nicht angegeben) iOS Simuliertes Glücksspiel

    Ein In-Game-Staking-Feature auf einem individuellen Account

    Was passiert ist

    Ein Spiel wurde wegen simulierten Glücksspiels abgelehnt: Spieler konnten In-Game-Items gegeneinander setzen – eine Mechanik, die in klassischen Online-Rollenspielen üblich ist. Da der Entwickler unter einem Individual-Account statt als Unternehmen veröffentlichte, entschied er sich, das Feature vorerst zu entfernen.

    Lösung

    Feature entfernen und erneut einreichen.

    Lektion

    Mechaniken im Glücksspiel-Stil werden auch ohne Echtgeld besonders genau geprüft, und was Apple erlaubt, hängt teils von deinem Account-Typ und der Dokumentation ab. Prüfe die Glücksspiel-Regeln, bevor du Staking-, Loot- oder Wager-Features baust, und plane deinen Developer-Account-Typ entsprechend ein.

24. 

    Gefälschte Dokumente (Richtliniennummer nicht angegeben) iOS Gefälschte Dokumente

    A PDF editor blamed for what users might do

    Was passiert ist

    Eine PDF-Editor-App wurde abgelehnt, weil Apple behauptete, sie erlaube das Erstellen von gefälschten IDs und gefälschten Dokumenten. Der Entwickler argumentierte, dass nach derselben Logik auch jede Banking- oder Messaging-App abgelehnt werden könnte für das, was böswillige Akteure damit anstellen könnten.

    Lösung

    Nicht angegeben.

    Lektion

    Universal-Tools können nach ihrem schlimmsten Anwendungsfall beurteilt werden. Vermeiden Sie Vorlagen oder Marketing, die wie offizielle IDs oder Zertifikate aussehen, und erklären Sie in den Review-Notes, wofür die App gedacht ist und was sie nicht unterstützt.

25. 

    KI-Datenweitergabe (Richtliniennummer nicht angegeben) iOS Datenweitergabe an KI

    Kein Consent-Screen für die Datenweitergabe an KI-Drittanbieter

    Was passiert ist

    Ein Team bekam seine erste Ablehnung, weil es Nutzerdaten an einen externen KI-Anbieter weitergab. Apple verlangte die ausdrückliche Zustimmung der Nutzer und eine klare Offenlegung, welche Daten an welchen KI-Anbieter gehen. Die Sorge des Teams: einen Consent-Screen bauen, der das Review besteht, ohne die Conversion zu drücken.

    Lösung

    In Bearbeitung.

    Lektion

    Wenn deine App Nutzerinhalte an einen externen KI-Service sendet, hol vor der ersten Anfrage die Zustimmung ein und nenne den Anbieter und die betroffenen Daten. Baue diesen Screen vor der Einreichung, nicht erst nach der Ablehnung.

26. 

    Family Controls Entitlement (Guideline-Nummer nicht eindeutig angegeben) iOS Metadaten und IAP

    Fünf Ablehnungen wegen eines fehlenden Häkchens

    Was passiert ist

    Ein Entwickler, der eine App im Stil von Screen Time veröffentlichte, wurde fünfmal abgelehnt. Unklare Review-Notizen ließen ihn glauben, das Design selbst sei das Problem. Die eigentliche Ursache war eine einzige nicht aktivierte Family-Controls-Einstellung in seinem Developer-Setup. Sobald er sie aktivierte, wurde die App akzeptiert.

    Lösung

    Genehmigt nach Aktivierung der Family-Controls-Einstellung und erneutem Einreichen.

    Lektion

    Wenn die Review-Notizen unklar bleiben, prüfe Entitlements und Zertifikate, bevor du das Produkt überarbeitest. Screen-Time- und Family-Controls-Apps brauchen die passende Capability im Developer Portal, nicht nur in Xcode.

27. 

    Richtlinie 5.1.1(v) iOS Richtlinie 5.1.1 Login-Pflicht

    Konto erforderlich für eine kostenpflichtige Funktion, die auf dem Gerät läuft

    Was passiert ist

    Ein Entwickler, der von Web-Apps kam, wurde unter Richtlinie 5.1.1(v) abgelehnt. Im Web waren Käufe immer an ein Konto gebunden. Auf iOS gehört der Kauf Apple, also können Käufer bezahlen, ohne sich zu registrieren. Seine kostenpflichtige Stufe schaltete Gerätefilter frei, die nur auf dem Telefon liefen, aber sowohl das Freischalten dieser Stufe als auch „Käufe wiederherstellen“ erzwangen zuerst ein Konto.

    Lösung

    Wird umgebaut, damit ein Kauf ohne Konto auch nach einer optionalen Anmeldung noch seinen Besitzer findet. Zum Zeitpunkt des Beitrags in Arbeit.

    Lektion

    Wenn eine kostenpflichtige Funktion auf dem Gerät läuft und keine Server-Identität braucht, sollten Nutzer sie ohne Konto kaufen und wiederherstellen können. Anmeldung nur für Funktionen beibehalten, die wirklich eine brauchen, etwa Cloud-Backup.

28. 

    Richtlinie 1.4.2 Körperliche Schäden iOS Richtlinie 1.4.2

    Dosierungsrechner-Apps bei Regelverschärfung aus dem Store entfernt

    Was passiert ist

    Ein Entwickler stellte fest, dass zwei seiner Apps unter Richtlinie 1.4.2 markiert wurden, obwohl sich keine davon im Review befand. Beide waren bereits live: ein eigenständiger Rechner für Peptid-Dosierungen und ein Tracker mit integriertem Rechner – zusammen ihr erster echter Umsatzerfolg. Andere Entwickler in derselben Nische meldeten zur gleichen Zeit dieselbe Benachrichtigung. Darin hieß es, dass Apps zur Berechnung von Medikamentendosen, einschließlich Peptid-Dosierung und Rekonstitution, nur vom Arzneimittelhersteller oder einer anerkannten Institution wie Krankenhaus, Versicherung, Apotheke oder Universität veröffentlicht werden dürfen.

    Lösung

    Keine. Der Entwickler sagte, er verstehe die Sicherheitsbedenken, und betrachtete die Apps damit als beendet.

    Lektion

    Eine Freigabe ist nicht dauerhaft. Apple kann eine Live-App neu bewerten, wenn eine Regel verschärft wird. Wenn deine App Dosierungen berechnet oder Gesundheitshinweise gibt, die jemanden schädigen könnten, lies Richtlinie 1.4, bevor du baust – und plane, über eine qualifizierte Institution zu veröffentlichen oder die Berechnung wegzulassen.

29. 

    Richtlinien 4.3 Spam und 4.2.6 App-Generierungsdienste iOS Richtlinie 4.3 Richtlinie 4.2.6

    Eine Offline-Ticketing-App wurde erneut als Spam eingestuft

    Was passiert ist

    Ein Entwickler baute eine kleine App, die ein Spreadsheet in ein Ticketing- und Check-in-System verwandelt, das komplett offline läuft – ohne Account und ohne Abo. Im Sommer hatte sie bereits den Einlass bei einem lokalen Event mit mehreren hundert Teilnehmern abgewickelt. Apple lehnte sie erneut mit einer kombinierten 4.3- und 4.2.6-Meldung ab: Die App könnte bereits im Store vorhandene Apps duplizieren, eine opportunistische Variante einer überfüllten Kategorie sein oder von einem Template bzw. App-Generierungsdienst stammen. Der Entwickler sagte, er kenne keine andere App, die dasselbe macht, und die Android-Version sei seit etwa einer Woche live.

    Lösung

    Zum Zeitpunkt des Beitrags wurde sie immer noch abgelehnt. Der Entwickler sagte, er wolle ohnehin kein Geld mit dem App Store verdienen.

    Lektion

    Ein 4.3-Reviewer sieht nur deinen Store-Eintrag und ein paar Minuten der App, nicht deine echten Nutzer. Wenn die App wirklich anders ist, erkläre in den Review-Notizen und den ersten Screenshots genau, inwiefern. Erwähne den realen Anwendungsfall und stelle klar, dass du kein Template oder einen App-Generator verwendet hast.

30. 

    Guideline 5.6.4 App-Qualität Apple Developer Program Richtlinie 5.6.4

    Auszahlungen eingefroren wegen steigender Stornorate

    Was passiert ist

    Ein Entwickler mit einer schnell wachsenden Abo-App erhielt plötzlich eine Warnung von Apple: Sein Account verstoße gegen den Developer Code of Conduct gemäß Guideline 5.6.4 (App Quality). Der Hinweis nannte übermäßige Rückerstattungsanfragen und Kundenbeschwerden, warnte vor einer möglichen Kündigung des Accounts und teilte mit, dass alle Auszahlungen pausiert und App-Transfers deaktiviert seien. Die Rückerstattungsrate hatte sich in den letzten zwei Monaten fast verdoppelt. Bei der Analyse der Daten stellte der Entwickler fest, dass die meisten Rückerstattungsanfragen als „unbeabsichtigte Käufe“ markiert waren – seiner Einschätzung nach vor allem Nutzer, die vergaßen, die 3-tägige kostenlose Testphase zu kündigen, die in ein Jahresabo überging. Die Warnung kam, als ein großes Redesign der App bereits im Test war.

    Lösung

    Zum Zeitpunkt des Posts noch offen. Der Entwickler fügte während der Testphase mehr Reminder hinzu, machte die anstehende Abbuchung deutlicher, ermöglichte die Verwaltung und Kündigung des Abos direkt in der App, schloss das Redesign nach weiteren Tests ab und pausierte währenddessen jegliches bezahlte Creator-Marketing.

    Lektion

    Apple achtet nicht nur auf dein Binary, sondern auch auf Erstattungsraten und Beschwerden. Ein kostenloser Testzeitraum, der stillschweigend in eine Jahresgebühr übergeht, kann im großen Maßstab zum Problem ungewollter Käufe werden. Erinnere Nutzer vor Ablauf des Testzeitraums, zeige den echten Preis klar an, mach das Kündigen einfach und behandle steigende Erstattungsraten als Account-Risiko, lange bevor Apple es tut.

31. 

    Metadaten und In-App-Kauf-Setup iOS Metadaten und IAP

    Dreimal abgelehnt wegen eines Bildes, das die Konsole nicht löschen wollte

    Was passiert ist

    Ein Entwickler fügte in App Store Connect ein Werbebild zu einem Abonnement hinzu und hatte das Bild versehentlich doppelt drin. Danach ließ sich das Bild weder löschen noch ersetzen, und jeder Versuch scheiterte mit einer generischen Fehlermeldung, man solle es später erneut versuchen. Die App wurde dreimal wegen dieses Abo-Setups abgelehnt. Jedes Mal antwortete der Entwickler mit einer Bildschirmaufnahme des Löschversuchs und der Fehlermeldung, und jedes Mal wirkte es, als hätte der Reviewer das ignoriert. Der Entwickler war überzeugt, die Ursache sei ein Bug in App Store Connect selbst.

    Lösung

    Zum Zeitpunkt des Beitrags immer noch festgefahren, ohne Fix von Apple.

    Lektion

    Wenn App Store Connect selbst den Fix blockiert, erreicht eine Antwort im Rejection-Thread vielleicht niemanden, der das lösen kann. Lade Subscription-Bilder sorgfältig und nur einmal hoch, und falls die Konsole spinnt, wende dich wegen des Bugs separat an den Apple Developer Support, während du dem App Review antwortest.

32. 

    Richtlinie 4.3 Spam iOS Richtlinie 4.3

    Drei Ablehnungen für eine App, die ein einziges Fitnessstudio verwaltet

    Was passiert ist

    Ein Entwickler baute eine iOS-App für sein eigenes Fitnessstudio, rund 176 Commits Arbeit. Apple lehnte sie am 29. September ab, erneut am 7. Oktober und am 13. Oktober dann unter Guideline 4.3 Spam. Am selben Tag beantwortete er alle neun Fragen, die App Review ihm geschickt hatte. Sechs Tage später, am 19. Oktober, hatte er noch nichts gehört. In der App-Liste von App Store Connect standen zur selben Zeit mehrere andere Apps desselben Accounts ebenfalls auf abgelehnt – auf iOS wie auf macOS.

    Lösung

    Zum Zeitpunkt des Beitrags noch offen, keine Antwort von App Review nach dem Absenden der Antworten.

    Lektion

    Aufwand und Commit-Anzahl sind nicht das, was 4.3 misst. Wenn eine App wirklich nur für ein Unternehmen gebaut ist, kann eine Unlisted App außerhalb der Suche bleiben und ist trotzdem über den Direktlink für jeden erreichbar; die Custom App Distribution beschränkt die Verfügbarkeit auf bestimmte Organisationen. Wähle die Option, die zur gewünschten Zugriffskontrolle passt. Für ein öffentliches Listing sollte in den ersten Screens, Screenshots und Review Notes klar werden, was sich von bestehenden Apps unterscheidet.

33. 

    Guidelines 5.6 Developer Code of Conduct und 2.5.19 Hidden Features iOS Richtlinie 5.6 Developer Code of Conduct Guideline 2.5.19 Versteckte Funktionen

    Als Betrug abgelehnt wegen übrig gebliebener Test-Switches

    Was passiert ist

    Im September 2026 wurde eine iOS-App wegen Richtlinie 5.6 Developer Code of Conduct abgelehnt. Apple sagte, es habe ein Verhaltensmuster gefunden, das es mit Betrug verbindet – konkret Funktionen, die während des Reviews absichtlich verborgen wirkten. Der Entwickler führte es auf drei Test-Switches im Release-Build zurück: einen Modus für Store-Screenshots, einen Switch, der einen langsamen Entitlement-Check simulierte, und einen Switch, der Mock-Käufe freischaltete. Keiner davon war für normale Nutzer der App-Store-Version erreichbar. Mit Apples Update der App Review Guidelines vom 16. Oktober wurden versteckte, ruhende oder undokumentierte Features als eigene Richtlinie 2.5.19 eingeführt, und Apple sagt, ein Verstoß könne das gesamte Entwicklerkonto gefährden.

    Lösung

    Der Entwickler prüft jetzt vor dem Upload die Strings in jedem Release-Archiv. Ob genau dieser Build später genehmigt wurde, blieb offen.

    Lektion

    Halte Test-only-code zur Compile-Zeit aus Release-Builds heraus, z. B. mit DEBUG-Flags, statt hinter einem Runtime-Check. Prüfe, was tatsächlich in der archivierten Binary landet, und liste jeden Switch auf, der in den App Review Notes steht.

34. 

    2.1 Benötigte Informationen iOS Richtlinie 2.1

    Review pausiert, bis Apple wusste, für wen die App gedacht ist

    Was passiert ist

    Ein Entwickler hat Version 1.0 einer iPad-App eingereicht, und die Prüfung wurde unter Richtlinie 2.1 – Benötigte Informationen gestoppt. Es gab keinen Crash-Report, keine defekte Funktion und keine angeforderte Korrektur am Binary. Apple wollte nur eine ausführliche Antwort auf eine einzige Frage, bevor die Prüfung fortgesetzt werden konnte: Wer würde diese App nutzen?

    Lösung

    Apple verlangte eine Erklärung zur Zielgruppe, bevor die Prüfung fortgesetzt wurde.

    Lektion

    Behandle Zielgruppe und Use Case als Eingaben für die Prüfung, nicht als Marketingtext, den man später ausfüllen kann. Formuliere eine klare Antwort zur Zielgruppe, bevor du die erste Version einreichst.

35. 

    4.3 Design / Spam iOS Richtlinie 4.3

    Nicht ausreichend anders in einer gesättigten Kategorie für Sound-Apps

    Was passiert ist

    Eine Entertainment-Sound-App wurde unter Guideline 4.3(b) abgelehnt. Apple erklärte, der Store habe bereits genug ähnliche Apps, und stufte das Produkt als Duplicate Content in einer überfüllten Kategorie ein – obwohl das Team überzeugt war, dass zusätzliche Features den Unterschied machen.

    Lösung

    Ablehnung nach 4.3(b) wegen mangelnder Differenzierung in einer überfüllten Kategorie.

    Lektion

    In Kategorien, die Apple als gesättigt bezeichnet, muss die Neuartigkeit schon in der ersten Minute des Reviews offensichtlich sein. Setze auf das Einzigartige, nicht auf einen Gimmick, den Reviewer schon oft gesehen haben.

36. 

    Metadaten und Store-Listing-Copy iOS Metadaten und IAP Endlose Reviews

    Die Metadaten-Schleife, die die Launch-Woche auffraß

    Was passiert ist

    Ein Team für Produktivitäts-Apps für Endverbraucher lieferte einen sauberen Build aus, verbrachte dann aber über neun Tage damit, sich durch Metadaten-Einwände zu kämpfen. Jede erneute Einreichung beantwortete die vorherige Anmerkung, doch die nächste Rückmeldung konzentrierte sich auf eine andere Formulierung, einen Screenshot oder eine Erklärung. Kein code änderte sich, während Launch-, Presse- und Paid-Acquisition-Pläne auf die Review-Texte warteten.

    Lösung

    Freigegeben, nachdem Screenshots, Untertitel und Review-Notizen ohne Änderung am Binary überarbeitet wurden.

    Lektion

    Fixiere Listing-Texte, Screenshots und Review-Notizen in einem Durchgang, bevor du ein Launch-Datum festlegst. Metadaten-Ablehnungen können sich häufen, selbst wenn sich das Binary nie ändert.

37. 

    Export-Compliance (App Store Connect) iOS Metadaten und IAP

    Freigegeben, dann durch eine weitere Compliance-Frage blockiert

    Was passiert ist

    Ein Companion-Build für ein B2B-Dashboard wurde genehmigt, doch das Release blieb blockiert, als eine Compliance-Abfrage erneut auftauchte – obwohl das Team dachte, die Export-Fragen seien bereits geklärt. Der Release-Owner stoppte den Rollout, holte die rechtlichen Formulierungen ein, aktualisierte die Antwort in App Store Connect und wartete einen weiteren Review-Durchlauf ab, während Kunden die Ankündigung bereits sahen, bevor die App verfügbar war.

    Lösung

    Release erfolgte nach erneuter Beantwortung der Export-Compliance und dem Abwarten des nächsten Review-Durchlaufs.

    Lektion

    Betrachte Export-Compliance als Release-Gate, nicht als einmaliges Häkchen. Bestätige, dass App Store Connect einen releasefähigen Status anzeigt, bevor du einen Release-Termin ankündigst.

38. 

    Google-Play-Berechtigungen und Policy-Review Google Play Store Metadaten und IAP Endlose Reviews

    Die Permission-Policy als Zeitfresser

    Was passiert ist

    Eine Android-App für den Außendienst löste eine umfassende Policy-Prüfung aus, nur weil auf einem einzelnen Screen eine eng gefasste Berechtigung genutzt wurde. Das Team dokumentierte das Feature, fügte Anweisungen für Reviewer hinzu und zeichnete einen Demo-Pfad auf – und musste die Berechtigung nach dreizehn Tagen trotzdem aus dem Hauptrelease entfernen, um Kunden nicht zu blockieren.

    Lösung

    Genehmigt nach Entfernen der Berechtigung, Aufzeichnen eines neuen Demos und Neuschreiben der Store-Deklaration.

    Lektion

    Beschränke sensible Berechtigungen auf den kleinstmöglichen Umfang, den du zuerst ausliefern kannst. Eine einzige Berechtigung kann bei Google Play eine komplette Policy-Prüfung nach sich ziehen.

39. 

    Timing der Google-Play-Review-Queue Google Play Store Endlose Reviews

    Der Hotfix, der hinter einer Policy-Warteschlange wartete

    Was passiert ist

    Ein E-Commerce-Team brauchte einen schnellen Mobile-Fix für einen Checkout-Bug, doch das Store-Release hing zur Unzeit sechs Tage im Review. Die Support-Tickets stiegen, während der Status auf „ausstehend“ blieb. Sie entschärften das Problem zuerst serverseitig und sahen dann, wie die Binary-Freigabe erst eintraf, nachdem der Notfall schon ein ganzes Wochenende verbrannt hatte.

    Lösung

    Der native Store-Fix kam erst, nachdem das Team den Vorfall bereits anderweitig behoben hatte.

    Lektion

    Store-Review ist kein Incident-Response-Kanal. Halte für dringende Production-Bugs einen Mitigation-Weg außerhalb des Stores bereit, während die Binary in der Warteschlange wartet.

40. 

    Guidelines 3.1.1 In-App-Käufe und 3.1.3(f) Kostenlose Standalone-Apps iOS Richtlinie 3.1.1 Richtlinie 3.1.3

    Companion-App abgelehnt, weil ihre Testphase endet

    Was passiert ist

    Ein Entwickler hat eine kostenlose iOS-Companion-App für seinen kostenpflichtigen webbasierten E-Mail-Dienst veröffentlicht. Die App bot keine In-App-Käufe an. Er verwies App Review auf die Ausnahme 3.1.3(f) für kostenlose eigenständige Companion-Apps, doch die App wurde viermal abgelehnt. Er legte Berufung ein, und das App Review Board bestätigte die Ablehnung. Die Begründung: Der Dienst bot eine 14-tägige kostenlose Testphase, für iOS-Nutzer sei die App nach 14 Tagen nicht mehr nützlich und keine echte eigenständige Erfahrung. Apple bot zwei Auswege an: Entweder der App genug kostenlose Inhalte und Funktionen geben, damit sie eigenständig ist, oder App-Store-Kunden den Dienst per In-App Purchase kaufen lassen. Der Entwickler wies darauf hin, dass eine bekannte E-Mail-App mit einem 14-Tage-Limit scheinbar dasselbe tue.

    Lösung

    Zum Zeitpunkt des Beitrags noch ungelöst. Die Berufung scheiterte, und der Entwickler wog einen minimalen Free-Tier gegen das Hinzufügen von In-App Purchase ab.

    Lektion

    Die Companion-Ausnahme 3.1.3(f) wird eng ausgelegt. Wenn Ihr Webdienst eine zeitlich begrenzte Testphase hat, kann Apple die App nach Ablauf der Testphase als getarnte Paywall betrachten. Entscheiden Sie vor der Einreichung, was jemand in der App nach der Testphase noch kostenlos tun kann, oder planen Sie In-App Purchase ein. Der Verweis auf andere Apps, die scheinbar dasselbe tun, hilft bei einer Berufung selten.

41. 

    Guideline 3.1.1 In-App-Käufe iOS Richtlinie 3.1.1

    Eigene API-Schlüssel werden als Zahlung außerhalb des App Store behandelt

    Was passiert ist

    Ein Solo-Entwickler, der einen KI-Assistenten für das iPhone baute, erlaubte Nutzern, eigene API-Schlüssel von einem Drittanbieter-Modellaggregator einzufügen, um große Cloud-Modelle auszuführen. In der vierten Review-Runde lehnte die App Review die App gemäß Richtlinie 3.1.1 ab, da die Option, eigene Schlüssel zu verwenden, als Möglichkeit zur Bezahlung von Funktionen außerhalb des App Store interpretiert wurde. Nach dem Verständnis des Entwicklers kann ein woanders gekaufter Schlüssel nur dann eine kostenpflichtige Funktion in der App freischalten, wenn der Anbieter In-App-Purchase in seiner eigenen iOS-App anbietet – dieser Anbieter hat jedoch keine iOS-App. Der Entwickler legte keinen Einspruch ein.

    Lösung

    Sie entfernten die Funktion für eigene Schlüssel vollständig, bauten die nächste Version so um, dass die Modelle vollständig auf dem Gerät laufen, und planten, Cloud-Modelle später als In-App-Credits über In-App-Purchase wieder einzuführen. Das Ergebnis dieser erneuten Einreichung war zum Zeitpunkt der Veröffentlichung noch unbekannt.

    Lektion

    Wenn eine kostenpflichtige Funktion in eurer App durch Credentials freigeschaltet wird, die woanders gekauft wurden, prüft vor der Entwicklung, ob dieser Anbieter In-App-Purchase in seiner eigenen iOS-App anbietet. Falls nicht, plant einen eigenen In-App-Purchase-Pfad oder einen Modus, der ohne diesen auskommt.

42. 

    Richtlinie 1.2 iOS Richtlinie 1.2

    Outfit-Vergleich abgelehnt, weil ein Gewinner gekürt wurde

    Was passiert ist

    Ein Solo-Entwickler veröffentlichte eine KI-App, die zwei Outfits vergleicht. Nach dem Vergleich verkündete die App, welcher Look gewonnen hat. App Review lehnte sie unter Guideline 1.2 ab, weil das Ergebnis als Ranking von Personen statt von Kleidung gelesen wurde. Der Entwickler teilte die Bedenken.

    Lösung

    Sie entfernten alle Gewinner-Formulierungen, das Gewinner-Badge und jede größere Score-Anzeige oder Highlight-Farbe bei einer der Optionen. Jetzt haben beide Looks gleich viel visuelles Gewicht, jedes Outfit bekommt sein eigenes Feedback und der Nutzer entscheidet. Ob der korrigierte Build genehmigt wurde, wurde nicht mitgeteilt.

    Lektion

    Apple bewertet, wie sich ein Screen anfühlt, nicht nur, was er tut. Wenn deine App irgendetwas bewertet, das mit dem Aussehen von Menschen zusammenhängt, zeig das Feedback ohne Ranking und geh von der strengsten Auslegung aus.

43. 

    Kids-Kategorie, Guideline 3.1.2 und Datenschutzfragen iOS Kids-Kategorie Richtlinie 3.1.2 Endlose Reviews

    Eine Kids-Story-App, die auch nach einem Monat voller Ablehnungen noch wartet

    Was passiert ist

    Ein Solo-Entwickler hat eine Story-App für Kinder zwischen 4 und 10 Jahren gebaut, in der Kinder Geschichten hören und pausieren können, um Fragen zu stellen. Auf Android war die App bereits seit Wochen live. Am 19. September 2026 wurde sie im App Store eingereicht. Nach mehreren Runden mit Ablehnungen und Neueinreichungen wurde sie auch einen Monat später noch nicht genehmigt. In der letzten Runde forderte Apple zwei Dinge: Da die App wöchentliche, monatliche und jährliche Abonnements verkauft, braucht die App Store-Seite einen funktionierenden Link zu den Nutzungsbedingungen; und da die App in der Kids-Kategorie ist, konnte die Prüfung erst weitergehen, nachdem der Entwickler vier Fragen beantwortet hatte: zu Drittanbieter-Analytics, Drittanbieter-Werbung, ob Daten an Dritte weitergegeben werden und wo sie gespeichert sind, sowie ob weitere Nutzer- oder Gerätedaten erfasst werden und wofür.

    Lösung

    Der Entwickler hat beide Fehler behoben und die App erneut eingereicht. Das Ergebnis stand zum Zeitpunkt des Beitrags noch aus.

    Lektion

    Bei Apps für Kinder, Gesundheit, Finanzen oder Bildung sollten Sie frühzeitig klären, welche lokalen Datenschutzgesetze und Store-Vorgaben gelten – zum Beispiel die elterliche Einwilligung vor der Erhebung von Kinderdaten. Halten Sie den Link zu den Nutzungsbedingungen und die schriftliche Datenschutz-Antwort schon vor der ersten Einreichung bereit.

44. 

    Guidelines 5.1.1(v) und 3.1.2 iOS Richtlinie 5.1.1 Richtlinie 3.1.2

    Version 1.0 abgelehnt wegen Login-, Kauf- und Lösch-Flows

    Was passiert ist

    Die Version 1.0 eines Entwicklers wurde wegen drei Problemen auf einmal abgelehnt – keins davon betraf die App-Idee selbst. Nach dem Sign in with Apple fragte die App den Nutzer erneut nach einem Namen, den Sign in with Apple bereits geliefert hatte. Die Kontolöschung musste sich in der App starten lassen. Der Abo- und Support-Screen musste den Preis, die Verlängerungsbedingungen und einen Link zu den AGB anzeigen. Das Fazit des Entwicklers: Alle drei Punkte drehten sich um Login, Kauf und Löschung.

    Lösung

    Nicht angegeben.

    Lektion

    Gehe die Login-, Kauf- und Kontolöschungs-Flows vor der ersten Einreichung wie ein Reviewer durch. Diese drei Abläufe führen oft zu ersten Ablehnungen.

45. 

    Richtlinie 5.2.3 Audio/Video-Downloads iOS Richtlinie 5.2.3 Audio/Video-Downloads

    Vintage-Internetradio wegen Audio-Rechten von Drittanbietern abgelehnt

    Was passiert ist

    Die Internetradio-App eines Solo-Entwicklers im Vintage-Look (Version 1.0, fünfter Build) wurde nach Guideline 5.2.3 abgelehnt. Diese Regel gilt für Apps, die Audio oder Video aus Drittquellen abspielen oder herunterladen, und verlangt einen Nachweis, dass der Entwickler die Rechte an diesen Inhalten hat. Der Entwickler antwortete am nächsten Tag im Resolution Center mit einer Erläuterung zu den Inhaltsrechten.

    Lösung

    Das Ergebnis war zum Zeitpunkt der Veröffentlichung noch unklar.

    Lektion

    Wenn deine App Sender oder Medien streamt, die dir nicht gehören, hol dir eine Autorisierung ein oder nutze Quellen, deren Bedingungen die Wiedergabe in der App ausdrücklich erlauben. Füge diese Dokumentation den Review-Notizen hinzu, bevor du einreichst.

46. 

    Richtlinie 4.3 (Spam) iOS Richtlinie 4.3

    Sechs Ablehnungen, dann ein 4.3-Spam-Label und zwei Wochen Warten auf einen Call

    Was passiert ist

    Ein Solo-Entwickler arbeitete Monate an seiner ersten App – ein Eisbrecher für soziale Situationen. Sie wurde sechsmal abgelehnt, das letzte Mal unter Guideline 4.3 wegen Spam, obwohl der Entwickler fand, dass sie mehr bot als ähnliche Apps im Store. Er bat App Review um ein Einzelgespräch. Eine Woche verging ohne Antwort, und der Call fand erst etwa zwei Wochen nach der 4.3-Ablehnung statt. Der Entwickler hatte nach dem Gespräch den Eindruck, dass 4.3 inzwischen genutzt wird, um Apps zu markieren, die wie Low-Effort- oder KI-generierte Klone wirken – was seine App laut eigener Aussage nicht war.

    Lösung

    Der Entwickler legte Widerspruch ein. Zum Zeitpunkt des Schreibens war dieser noch offen.

    Lektion

    In einer überfüllten Kategorie beurteilt der Reviewer, was Screenshots, Beschreibung und die erste Session zeigen. Hebe den Unterschied zu bestehenden Apps dort deutlich hervor und fordere den App Review Call frühzeitig an, da es eine Woche oder länger dauern kann, einen zu bekommen.

47. 

    Vereinbarung nicht akzeptiert (keine Richtlinie genannt) iOS Registrierung und Account

    Eine Woche in der Warteschlange, Ablehnung wegen einer nicht unterzeichneten Vereinbarung, dann noch eine Woche

    Was passiert ist

    Eine App wartete etwa eine Woche auf das Review und wurde dann abgelehnt, obwohl in der App nichts zu beanstanden war. Der Account hatte eine neu veröffentlichte Vereinbarung in App Store Connect noch nicht akzeptiert. Der Entwickler akzeptierte sie und reichte erneut ein, woraufhin die App für etwa eine weitere Woche in der Warteschlange landete. Der Developer-Support antwortete lediglich, dass alles auf Kurs sei.

    Lösung

    Zum Zeitpunkt der Erstellung wartet die App noch auf das Review.

    Lektion

    Prüfe vor jeder Einreichung in App Store Connect, ob Vereinbarungen auf Annahme warten. Ein fehlender Klick kann eine komplette Runde durch die Review-Queue kosten.

48. 

    Crash während des Reviews (keine Richtlinie genannt) macOS Richtlinie 2.1

    Abgelehnt wegen eines Crashes auf einer macOS-Version, die der Entwickler nicht installiert hatte

    Was passiert ist

    Eine Mac-App wurde abgelehnt, weil sie unter macOS 27 abstürzte – eine Version, die der Entwickler noch nicht nutzte und nicht auf seinem Hauptrechner installieren wollte. Auf der Suche nach einer Möglichkeit, den Crash zu reproduzieren, entdeckte er, dass Apples Virtualization Framework kostenlos eine macOS-VM auf Apple Silicon ausführen kann, und setzte eine auf, um unter der neuen Version zu testen.

    Lösung

    Keine weiteren Angaben, außer der Reproduktion des Crashes in einer virtuellen Maschine.

    Lektion

    App Review testet auf dem neuesten OS. Halte eine virtuelle Maschine mit dem aktuellsten macOS bereit, um Review-Crashes zu reproduzieren, ohne deinen Hauptrechner upgraden zu müssen.

49. 

    Review-Verzögerung (keine Guideline angegeben) iOS Endlose Reviews

    Zwölf Tage in „Waiting for Review“ trotz zweier Expedite-Requests

    Was passiert ist

    Ein Entwickler, dessen Apps bereits im Store freigegeben waren, reichte Version 1.0 einer neuen App zusammen mit einer Abo-Gruppe mit fünf Abos ein. Zwölf Tage später stand sie immer noch auf „Waiting for Review“, obwohl man normalerweise mit unter 48 Stunden rechnet. Er beantragte zweimal einen Expedite-Request, kontaktierte den Support ohne Antwort und versuchte, einen App-Review-Termin zu buchen, der abgelehnt wurde.

    Lösung

    Zum Zeitpunkt dieses Berichts wartet er noch immer.

    Lektion

    Plane deinen Launch-Termin nicht anhand des 48-Stunden-Durchschnitts. Plane bei einer ersten Version mit Abos Wochen Puffer ein und sieh Expedite-Requests und Termine als möglich, nicht als garantiert an.

50. 

    Permission-Prompt + Screenshot-Metadaten (Regeln, oft zitiert als 5.1.1 und 2.3.7) iOS Richtlinie 5.1.1 Richtlinie 2.3.7

    Launch-Woche: eigener Allow-Screen und Preise in Screenshots

    Was passiert ist

    In der Launch-Woche wurde die App zweimal abgelehnt. Zuerst zeigte sie direkt vor dem System-Permission-Prompt einen eigenen Screen mit Allow-Button, was Apple nicht akzeptiert. Nach der Korrektur wurde sie zum zweiten Mal abgelehnt, weil die App-Store-Screenshots Preise zeigten. Beide Fixes waren klein, aber jede erneute Einreichung kostete etwa einen Tag in der Review-Queue.

    Lösung

    Der Entwickler hat beide Probleme behoben und hält beide Regeln jetzt im Projekt schriftlich fest, damit es nicht wieder vorkommt.

    Lektion

    Ein Pre-Permission-Screen kann erklären, warum du Zugriff brauchst, aber die einzige Allow-Option sollte der System-Prompt liefern. Verzichte in Screenshots auf Preise und geh vor jeder Einreichung eine kurze Checkliste durch.

51. 

    Review-Verzögerung (keine Guideline angegeben) iOS Endlose Reviews

    Zehn Tage in der Prüfung festgehangen, dann eine halbe Stunde nach dem Resubmit genehmigt

    Was passiert ist

    Die App hing mehr als zehn Tage ohne Bewegung in der Prüfung. Der Entwickler reichte sie erneut ein.

    Lösung

    Etwa 30 Minuten nach dem Resubmit wurde sie genehmigt.

    Lektion

    Eine stockende Prüfung ist nicht immer ein Urteil über deine App. Wenn sie deutlich länger als üblich hängt, kann ein Resubmit oder eine Anfrage auf beschleunigte Prüfung einen Versuch wert sein – garantiert ist beides nicht.

52. 

    4.3(a) Spam iOS Richtlinie 4.3

    Sieben Template-Apps in derselben Minute wegen 4.3 abgelehnt

    Was passiert ist

    Ein kleines Team reichte in einer Woche sieben Apps ein, die auf demselben Template basierten. Alle sieben erhielten in derselben Minute die identische 4.3(a) Spam-Ablehnung – darunter zwei Apps, die zuvor nie abgelehnt worden waren. Das Team kam zu dem Schluss, dass Apple das gesamte Paket statt der einzelnen Apps bewertet hat.

    Lösung

    Das Team reicht jetzt jeweils nur eine App ein.

    Lektion

    Apps mit derselben Codebase können wie ein Spam-Muster wirken, wenn sie zeitgleich eingereicht werden. Reicht sie zeitlich versetzt ein und sorgt dafür, dass sich jede App in Features, Design und Metadaten deutlich unterscheidet.

53. 

    Richtlinie 2.3.6 iOS Richtlinie 2.3.6

    Ablehnung wegen Altersfreigabe, obwohl Connect bereits passte

    Was passiert ist

    Eine App wurde wegen ihrer Altersfreigabe abgelehnt. Der Entwickler öffnete den Fragebogen zur Altersfreigabe in App Store Connect und stellte fest, dass alle Antworten bereits dem entsprachen, was in der Ablehnung gefordert wurde.

    Lösung

    Er änderte nichts in Connect, antwortete dem Reviewer, dass die Einstellungen bereits passten, und reichte die App erneut ein. Wenige Stunden später wurde sie genehmigt.

    Lektion

    Ein 2.3.6-Hinweis kann danebenliegen, was deine aktuellen Einstellungen betrifft. Prüfe App Store Connect, bevor du etwas änderst – und wenn es schon passt, sag das klar in deiner Antwort, statt auf gut Glück einen Fix zu raten.

54. 

    Richtlinie 2.1: Informationen erforderlich iOS Richtlinie 2.1

    Begrenzte Review-Historie: Device-Recording und Walkthrough der Paid Features

    Was passiert ist

    Eine App, die den Google-Play-Review bereits bestanden hatte, wurde unter 2.1 Information Needed zurückgeschickt. Apple erklärte, das Developer-Konto habe eine begrenzte Review-Historie, und verlangte ein Screen-Recording auf einem echten Gerät, einen Walkthrough der Paid Features und eine schriftliche Beschreibung, was die App macht und auf welche externen Services sie zurückgreift.

    Lösung

    Der Entwickler war zum Zeitpunkt des Posts dabei, das Recording und die Antworten vorzubereiten. Ergebnis nicht bekannt.

    Lektion

    Ein bestandener Google-Play-Review sagt nichts über Apple aus. Wenn dein Developer-Konto neu ist oder nur wenige frühere Einreichungen hat, bereite vor dem Einreichen ein Recording auf einem echten Gerät, einen Walkthrough der Paid Features und eine Liste der Third-Party-Services vor.

55. 

    Guidelines 2.1, 2.3.2 und 5.2.3 iOS Richtlinie 2.1 Richtlinie 2.3.2 Richtlinie 5.2.3 Audio/Video-Downloads Endlose Reviews

    Erste Submission: 2.1, dann 2.3.2, dann 5.2.3 über einen Monat

    Was passiert ist

    Die allererste Submission eines Entwicklers wartete sechs Tage und wurde dann unter 2.1 abgelehnt. Die Antwort kam noch am selben Tag. Zwölf Tage später wurde sie erneut abgelehnt, diesmal unter 2.3.2. Sie reichten wieder ein, und neun Tage danach wurde sie unter 5.2.3 abgelehnt. Auch diesmal antworteten sie am selben Tag und warteten zwei Tage später immer noch. Jede Runde brachte eine andere Guideline als die vorherige.

    Lösung

    Ich warte immer noch, mehr als einen Monat nach der ersten Einreichung.

    Lektion

    Jede Review-Runde kann eine neue Guideline ans Licht bringen, und jede kann eine Woche oder mehr kosten. Lies vor der ersten Einreichung nicht nur die Vollständigkeitsregeln (2.1), sondern auch die Metadaten-Regeln (2.3) und alle für dich geltenden Regeln zu Inhaltsrechten (5.2), und behebe in einem einzigen Build alles, was du findest.

56. 

    Guideline 4.2 Mindestfunktionalität iOS Richtlinie 4.2

    Gebets-App unter 4.2 als reines Buch abgelehnt

    Was passiert ist

    Eine religiöse Gebets- und Andachts-App wurde unter 4.2 abgelehnt, weil sie in erster Linie ein Buch sei. Der Entwickler verwies auf interaktive Features wie einen Kalender, einen Gebetszähler, einen Meditations-Timer, teilbare Sammlungen, Home-Screen-Widgets und Sprachsuche.

    Lösung

    Nicht angegeben.

    Lektion

    Wenn ein Reviewer deine App nur als statischen Inhalt wahrnimmt, sind interaktive Features in den ersten Minuten der Prüfung eventuell nicht sichtbar. Zeig sie auf den ersten Screens und Screenshots und liste sie in den Review-Notizen auf, mit den Schritten, um sie jeweils zu erreichen.

57. 

    Richtlinie 2.3.10 iOS Richtlinie 2.3.10

    Dreizehn Tage in der Warteschlange, in sieben Minuten wegen Android abgelehnt

    Was passiert ist

    Ein Entwickler wartete dreizehn Tage in der Review-Queue, checkte täglich App Store Connect und seine E-Mails und stellte zwei Support-Anfragen. Als der Review endlich startete, wurde die App rund sieben Minuten später abgelehnt, weil in der App-Store-Beschreibung stand, dass das Produkt in jedem Browser auf iPhone oder Android funktioniere.

    Lösung

    Sie entfernten den Verweis auf die andere Plattform, eine Ein-Zeilen-Änderung, und reichten erneut ein. Ergebnis noch nicht gemeldet.

    Lektion

    Apple lehnt Metadaten ab, die andere mobile Plattformen nennen. Scannt eure Beschreibung, Screenshots und Promo-Texte vor dem Einreichen auf Namen von Konkurrenzplattformen, denn ein winziger Formulierungsfehler kann eine komplette Wartezeit in der Queue kosten.

58. 

    Richtlinie 5 (Rechtliches) iOS Richtlinie 5 Rechtliches

    Ablehnung nach Guideline 5 wegen OpenAI in den Metadaten für China

    Was passiert ist

    Eine KI-App wurde unter Guideline 5 (Legal) abgelehnt, weil in den Metadaten OpenAI erwähnt wurde. Apple erklärte, dass China eine staatliche Lizenz für generative KI und Deep-Synthesis-Dienste verlangt, dass ChatGPT diese nicht hat und dass der Entwickler entweder die KI-Funktion sowie jeden OpenAI- oder ChatGPT-Verweis aus Name, Untertitel, Promo-Text, Beschreibung und Screenshots für den China-Storefront entfernen oder den Vertrieb in Festlandchina einstellen muss.

    Lösung

    Der Entwickler empfiehlt, den chinesischen Festland-Store in den Verfügbarkeitseinstellungen vor der App-Übermittlung zu deaktivieren, wenn diese Dienste genannt werden. So spart man einen Review-Zyklus.

    Lektion

    Wenn deine App auf einem generativen KI-Anbieter basiert, entscheide dich frühzeitig für die Verfügbarkeit in China. Die Ablehnung betrifft den Storefront und die Metadaten, nicht nur dein code.

59. 

    Richtlinie 3.1.2 iOS Richtlinie 3.1.2

    AGB-Link in der App, aber fehlt in der Beschreibung

    Was passiert ist

    Die erste Version einer Abo-App wurde zwei Tage nach der Übermittlung abgelehnt, weil der Link zu den Nutzungsbedingungen nicht in der App-Store-Beschreibung stand. Er war bereits in der App auf dem Paywall-Screen und in den Einstellungen vorhanden, nur nicht in diesem Metadatenfeld.

    Lösung

    Der Fix dauerte fünf Minuten, aber nach dem Resubmit hing der Build über zehn Tage in „Waiting for Review“, ohne dass eine Reaktion kam. Bisher wurde nichts gemeldet.

    Lektion

    Bei automatisch verlängerten Abonnements sollten Links zu den Nutzungsbedingungen (EULA) und der Datenschutzerklärung schon vor der ersten Submission sowohl in den App-Store-Metadaten als auch in der App hinterlegt sein – denn ein schneller Fix kann sonst eine lange zweite Wartezeit bedeuten.

60. 

    Account-Kündigung iOS Account-Kündigung

    Account gemäß 3.2(f) gekündigt, ausstehende Einnahmen nicht ausgezahlt

    Was passiert ist

    Das Apple-Developer-Konto eines Entwicklers wurde gemäß Abschnitt 3.2(f) des Developer Program License Agreement gekündigt. Fast drei Monate später waren die ausstehenden Einnahmen immer noch nicht ausgezahlt, woraufhin er andere Entwickler fragte, ob jemand schon einmal einbehaltene Einnahmen nach einer Kündigung erhalten hatte.

    Lösung

    Keine gemeldet.

    Lektion

    Eine Kündigung kann Einnahmen einfrieren, die du bereits verdient hast, nicht nur zukünftige Verkäufe. Halte Liquidität, Aufzeichnungen über deine Auszahlungen und deinen eigenen Kanal zu deinen Nutzern bereit, damit eine einzelne Kontobeschluss das Unternehmen nicht beendet.

61. 

    Richtlinien 2.1 und 5.1.2 iOS Richtlinie 2.1 Richtlinie 5.1.2 Endlose Reviews

    Fünfundzwanzig Tage in der Prüfung, dann 2.1 und 5.1.2 gleichzeitig

    Was passiert ist

    Ein Indie-Entwickler reichte die erste Version (1.0) einer iOS-App ein. Nach etwa siebzehn Tagen war der Build immer noch in der Prüfung. Nach insgesamt rund fünfundzwanzig Tagen lehnte App Review ihn in derselben Entscheidung gemäß Richtlinie 2.1 (Vollständigkeit der App) und 5.1.2 (Datennutzung und -freigabe) ab. App Store Connect blockierte daraufhin alle anderen Einträge in der Submission, bis die abgelehnte Version korrigiert wurde. Der Entwickler sagte, die genannten Probleme seien leicht zu beheben; der schmerzhafte Teil war die Erwartung, für die erneute Einreichung weitere zwei bis drei Wochen einplanen zu müssen.

    Lösung

    Sie behoben beide Probleme und reichten die App erneut ein. Das Ergebnis der nächsten Prüfung wurde nicht berichtet.

    Lektion

    Wenn die Warteschlangen so lang sind, kann jede Ablehnung Wochen kosten. Führen Sie vor der Einreichung einen vollständigen Vollständigkeits-Check durch: keine defekten Flows, ein funktionierendes Demo-Konto und keine Platzhalter. Stellen Sie sicher, dass die Antworten zur Datenschutzrichtlinie und die SDK-Datenteilung mit dem tatsächlichen Verhalten der App übereinstimmen.

62. 

    Richtlinie 2.3.1(a) iOS Richtlinie 2.3.1 Metadaten und IAP

    Echte Geldstake als versteckt gemäß 2.3.1(a) abgelehnt

    Was passiert ist

    Ein Entwickler baute einen Habit- und Disziplin-Tracker, bei dem Nutzer Geld aufs Spiel setzen und es verlieren konnten, wenn sie ihre Ziele verfehlten. Mitte Oktober 2026 lehnte die App Review sie unter Guideline 2.3.1(a) ab, da die App versteckte Funktionen enthielt – konkret monetäre Einsätze und den Verlust von Einsätzen, was in den Metadaten nicht beschrieben war. Das Schreiben enthielt außerdem einen Hinweis auf eine Extended Review: Wiederholte Einreichungen mit solchen Problemen führen zu längeren Review-Zeiten, und Accounts, die wiederholt gegen die Regeln verstoßen, können aus dem Apple Developer Program entfernt werden. Die App wurde insgesamt fünfmal abgelehnt; eine weitere Ablehnung nannte einen Crash während des Reviews auf dem iPad. Der Entwickler, der mit KI-Coding-Tools gebaut hatte, fasste die Learnings zusammen: Guidelines lesen, Metadaten mit der App abgleichen, Funktionen oder Datenerfassung niemals verbergen, generierten code prüfen und auf verschiedenen Geräten testen.

    Lösung

    Dazu wurde nur gesagt, dass die App nach fünf Ablehnungen überarbeitet wurde. Eine Genehmigung wurde nicht gemeldet.

    Lektion

    Jede Funktion, die echtes Geld bewegt – auch Einsätze oder deren Verlust –, muss in der Beschreibung und den App Review Notes klar ersichtlich sein. Testet auf dem iPad, auch wenn ihr nur fürs iPhone entwickelt, denn Reviewer machen das auch.

63. 

    Richtlinie 4.3(a) iOS Richtlinie 4.3

    Neue Features, neue Screenshots und eine 4.3(a) in drei Minuten inklusive Warnung

    Was passiert ist

    Ein Entwickler, der etwa zwei Monate damit verbracht hatte, eine App von Grund auf zu bauen, war bereits wegen 4.3 Spam abgelehnt worden. Für die nächste Runde fügte er neue Features hinzu, ersetzte alle Screenshots, optimierte die App für weitere Gerätegrößen und reichte sie erneut ein – mit Review-Notizen und einem Premium-Testkonto. Drei Minuten, nachdem die App in die Prüfung ging, wurde sie erneut unter Guideline 4.3(a) abgelehnt. Diesmal endete die Nachricht mit einer erweiterten Prüfungsanzeige: Wiederholte Einsendungen mit diesen Problemen würden zu längeren Prüfzeiten führen, und Accounts, die solche Apps weiterhin einreichen, riskieren die Entfernung aus dem Apple Developer Program. Aus Angst, dass eine weitere Einreichung den gesamten Account kosten könnte, überlegte der Entwickler, ob er die App fallen lassen oder App Review um ein Telefonat bitten sollte.

    Lösung

    Zum Zeitpunkt des Beitrags ungelöst.

    Lektion

    Sobald die erweiterte Prüfungsanzeige erscheint, ist ein schnelles erneutes Einreichen der riskanteste Schritt. Bitten Sie zuerst um ein App-Review-Telefonat und reichen Sie erst dann erneut ein, wenn Sie wissen, was als zu ähnlich gilt.

64. 

    Richtlinie 4.3(b) iOS Richtlinie 4.3

    In drei Minuten abgelehnt, dann drei Wochen Schweigen im Einspruchsverfahren

    Was passiert ist

    Die App eines Entwicklers wurde etwa drei Minuten nach dem Start der Prüfung wegen Richtlinie 4.3(b) abgelehnt. Er legte Beschwerde beim App Review Board ein. Drei Wochen später gab es immer noch keine Antwort, keine Statusänderung und keine Nachricht.

    Lösung

    Ungelöst.

    Lektion

    Eine Beschwerde kann wochenlang ohne Feedback liegen. Arbeiten Sie parallel daran, was Ihre App von der überfüllten Kategorie unterscheidet, damit Sie nicht nur auf die Beschwerde warten müssen.

65. 

    Account-Kündigung iOS Account-Kündigung

    Eine App sah aus wie eine Website, und Dutzende von Apps verschwanden

    Was passiert ist

    Bei einem Studio, das seit über einem Jahrzehnt mehr als 80 Apps veröffentlicht hatte, wurde der Developer-Account zur Kündigung markiert. Laut dem Studio lag der Grund darin, dass eine seiner Apps einer bestehenden Website zu ähnlich war. Es gab keine Vorwarnung und keine Möglichkeit, nur diese eine App zu entfernen. Alle Apps des Studios wurden aus dem App Store entfernt – auch völlig unbeteiligte, lizenzierte Apps für Kunden – und sämtliche Updates wurden blockiert.

    Lösung

    Ungeklärt. Das Studio widersprach der Entscheidung öffentlich.

    Lektion

    Ein einziger Developer-Account ist ein Single Point of Failure. Wenn du Apps für Kunden entwickelst, veröffentliche sie über den eigenen Developer-Account des Kunden. So kann ein Streit um eine deiner Apps nicht auch noch deren Account mit runterziehen.

66. 

    Abschnitt 3.2(f) (Developer Program License Agreement) iOS Account-Kündigung

    Erst ein Titel-Update, dann eine Kündigungsmitteilung nach 3.2(f)

    Was passiert ist

    Ein Indie-Entwickler reichte eine einfache Titeländerung für eine App ein und erhielt eine Kündigung nach Abschnitt 3.2(f). Alle seine Apps wurden aus dem Store entfernt. Er reichte offizielle Einsprüche ein und hatte 15 Tage später immer noch keine Antwort von einer Person erhalten.

    Lösung

    Ungelöst.

    Lektion

    Die Update, das eine 3.2(f)-Meldung auslöst, ist möglicherweise nicht das, worauf Apple reagiert. Sammeln Sie vor dem Einspruch klare Beweise dafür, wer jede App besitzt und betreibt, und rechnen Sie damit, dass Antworten Wochen dauern.

67. 

    Abschnitt 3.2(f) (Developer Program License Agreement) iOS Account-Kündigung

    Eine Paywall-Korrektur, dann eine Woche später eine 3.2(f)-Kündigung

    Was passiert ist

    Die App eines Indie-Entwicklers wurde einmal abgelehnt, weil die Jahres- und Wochenpreise auf der Paywall so angezeigt wurden. Die Paywall stammte aus einem Template, das ein KI-Coding-Assistent kopiert hatte. Sie korrigierten sie in code, reichten einen neuen Build ein und warteten etwa eine Woche. Statt eines Review-Ergebnisses wachten sie mit einer ausstehenden Kündigungsmitteilung nach Abschnitt 3.2(f) auf. Ihre gesamte Developer-Mitgliedschaft wurde geflaggt, alle Apps, die sie über Jahre gebaut hatten, wurden aus dem App Store entfernt und Auszahlungen wurden eingefroren. Der Entwickler gab an, nach der Einreichung nichts mehr an der App geändert zu haben, Logs als Beleg zu haben und fragte öffentlich, ob jemand jemals einen Account zurückbekommen hat.

    Lösung

    Zum Zeitpunkt des Beitrags ungelöst.

    Lektion

    Betrachte eine Ablehnung der Paywall oder der Preisgestaltung als Warnung, nicht als reine Formalität. Überprüfe vor der ersten Einreichung jedes Template oder jede generierte Paywall code darauf, wie Preise und Testzeiträume angezeigt werden. Führe Build- und Change-Logs, damit du genau dokumentieren kannst, was du eingereicht hast, falls dein Account jemals infrage gestellt wird.

68. 

    Guideline 3.1.1 In-App-Käufe macOS Richtlinie 3.1.1

    Ein kostenloser Cloud-Gaming-Client, abgelehnt unter 3.1.1 wegen Käufen in gestreamten Spielen

    Was passiert ist

    Ein Entwickler baute eine kostenlose Remote-Play-App für den Cloud-Gaming-Dienst eines großen Konsolenherstellers und reichte sie im App Store ein. Die Mac-Version wurde unter Richtlinie 3.1.1 abgelehnt. App Review gab an, dass einige gestreamte Spiele Nutzer dazu verleiten könnten, digitalen Inhalt außerhalb des App Stores zu kaufen. Der Entwickler verstand es so, dass der Gaming-Dienst keine Zahlungen während einer Streaming-Sitzung zulässt: Einige Spiele zeigen Kaufoptionen an, aber die Zahlung kann während des Streamings nicht abgeschlossen werden. Er wies darauf hin, dass bereits mehrere ähnliche Streaming-Apps im Store verfügbar waren, und legte Berufung ein.

    Lösung

    Appeal pending at time of posting.

    Lektion

    Bei Streaming- und Client-Apps bewertet App Review, was Nutzer innerhalb des gestreamten Inhalts sehen können, nicht nur deinen eigenen code. Erkläre in den Review-Notizen genau, wie Käufe innerhalb des Streams funktionieren, inklusive Screenshots, vor der ersten Einreichung, statt es für die Berufung aufzusparen.

69. 

    Login auf dem iPad (Richtliniennummer nicht angegeben) iOS Anmelden

    Dritte Ablehnung, weil der Login auf dem iPad während einer Backend-Störung fehlgeschlagen ist

    Was passiert ist

    Ein kleines Team, das eine Fitness-App entwickelte, sah sich mit der dritten Ablehnung seiner iOS-App konfrontiert, weil der Reviewer sich auf einem iPad nicht einloggen konnte. Die Ursache lag nicht in der App code: Der gehostete Backend-Anbieter hatte genau in dem Moment, als der Reviewer es versuchte, Probleme mit der Authentifizierung, sodass die Anmeldung schlicht fehlschlug. Das Team hatte ein Demo-Konto mit E-Mail und Passwort bereitgestellt, doch laut ihrem Bericht versuchte der Reviewer es später nicht erneut. Sie besaßen weder ein iPad noch einen Mac zum Testen. Sobald das Backend wieder funktionierte, reichten sie die App erneut ein. Apple hatte ihnen mitgeteilt, dass die App im Express-Review verbleiben würde, selbst bei erneuter Ablehnung – doch drei Werktage später wartete sie immer noch auf die Prüfung.

    Lösung

    Erneut eingereicht, zum Zeitpunkt der Veröffentlichung noch auf Review wartend.

    Lektion

    Reviewer testen oft auf dem iPad und versuchen sich in der Regel nur einmal anzumelden. Beobachte den Status deines Backends und deines Auth-Anbieters, während ein Build im Review ist, teste das Demo-Konto vor der Einreichung auf einem iPad-großen Bildschirm und gib in den Review-Notizen an, wen man kontaktieren soll, falls die Anmeldung fehlschlägt.

70. 

    Richtlinien 5.1.1(i) und 5.1.2(i) iOS Richtlinie 5.1.1 Richtlinie 5.1.2 Datenweitergabe an KI

    In den AGB versteckte KI-Einwilligung reichte für 5.1.1(i) und 5.1.2(i) nicht aus

    Was passiert ist

    Die Journal-App eines Entwicklers wurde unter den iOS-Richtlinien 5.1.1(i) und 5.1.2(i) abgelehnt – beide betreffen das Teilen von Nutzerdaten mit KI-Diensten. Die Einwilligung für diese Verarbeitung war bereits in den AGB der App abgedeckt, aber das App Review akzeptierte das nicht. Der Entwickler verlagerte die Einwilligung auf einen expliziten Screen in der App, der als Erstes erscheint, bevor ein Modell auch nur einen einzigen Eintrag liest. Anschließend wurde jeder code Pfad erfasst, über den Einträge ein Modell erreichen, und jeder einzelne an diese Einwilligung gekoppelt, sodass keine Anfrage ohne ein „Ja“ erstellt wird. Background Jobs überspringen nun Konten, die nicht zugestimmt haben, und warten, statt zu fehlschlagen. Zudem schlägt ein Release-Check fehl, wenn die App einen KI-Host aufruft, der nicht auf dem Einwilligungs-Screen genannt wird.

    Lösung

    Behoben und neu eingereicht. Apples Urteil war zum Zeitpunkt der Veröffentlichung noch offen.

    Lektion

    Eine Zeile in deinen AGB ist keine Einwilligung für das Teilen von Daten mit KI. Frage in der App vor der ersten Anfrage nach, nenne den Provider und die Daten und stelle sicher, dass jeder code Pfad, der Nutzerinhalte sendet, diese Antwort prüft.

71. 

    Abschnitt 3.2(f) (Developer Program License Agreement) nach wiederholten Metadata-Ablehnungen iOS Account-Kündigung Metadaten und IAP

    Eine neue Library, acht Ablehnungen, eine umbenannte App und dann die Kündigungsmitteilung

    Was passiert ist

    Ein Indie-Entwickler hatte eine iOS-App, die fast drei Jahre alt war, sechsstellige Umsätze erzielt und viele Updates mit einer niedrigen Rückerstattungsquote veröffentlicht hatte. Vor über sechs Monaten reichte er ein kleines Update ein, dessen einzige Änderung eine neue Library war. App Review lehnte es mehr als acht Mal ab, jedes Mal wegen Metadaten: Keywords, die seit über einem Jahr live waren, ein Untertitel in einer Lokalisierung, dann die Screenshots, dann dieselben Punkte erneut und schließlich der App-Name selbst, von dem der Großteil des Suchtraffics kam. Er bat um ein Gespräch mit App Review, und der Reviewer sagte ihm, der Name sei das letzte verbleibende Problem. Er benannte die gesamte App um und reichte sie erneut ein. Drei Tage später kam eine generische Ablehnung zurück, in der die Probleme mit dem Untertitel und den Screenshots erneut genannt wurden. Er beschloss, dass er das Update nicht brauche, und verwarf es. Monate später traf in genau diesem alten Review-Thread eine ausstehende Kündigungsmitteilung ein. Darin hieß es, das Konto habe wiederholt gegen die Richtlinien verstoßen, um den Review-Prozess zu umgehen, und die Probleme aus früheren Nachrichten seien weiterhin ungelöst. Die App wurde aus dem Store entfernt und das gesamte Konto für die Entfernung markiert.

    Lösung

    Einspruch beim App Review Board eingereicht, zum Zeitpunkt der Veröffentlichung ausstehend.

    Lektion

    Eine aufgegebenen Einreichung kann sich weiterhin negativ auf dein Konto auswirken. Wenn sich eine Review-Schleife hinzieht, lass dir alle verbleibenden Probleme schriftlich im Review-Thread bestätigen, nicht nur telefonisch. Und wenn du dich entscheidest, ein Update zurückzuziehen, antworte im Thread entsprechend und entferne den Build aus der Prüfung, statt die Ablehnung ungelöst zu lassen.

72. 

    Guideline 1.1 Safety: Objectionable Content, dann Section 3.2(f) iOS Anstößige Inhalte Account-Kündigung

    Zwei Ablehnungen wegen 1.1, eine Frage zu einem bestimmten Bild, dann eine Kündigung

    Was passiert ist

    Die iOS-App eines Entwicklers, die KI-Paarfotos generierte, wurde wegen „unangemessener Inhalte“ gemäß Richtlinie 1.1 abgelehnt. Die Ablehnung nannte nicht, welches Bild das Problem war. Der Entwickler entschärfte die Beispielbilder – ohne Berührungen oder Zuneigung – und reichte die App etwa fünf Tage später erneut ein. Vier Tage später kam die Ablehnung aus demselben Grund. Statt einen weiteren Build zu senden, schrieb er an Apple und fragte, welches Bild konkret das Problem sei. Etwa zehn Tage vergingen ohne Antwort, dann wurde die App aus dem Store entfernt und der Entwickler erhielt eine Androhung der Kontosperrung. Seiner Auffassung nach wertete Apple den wiederholten Zyklus aus Korrektur und erneuter Einreichung als Versuch, die Prüfung zu umgehen. Auszahlungen wurden ausgesetzt und jede App auf dem Konto war in Gefahr, mit 30 Tagen Frist zur Berufung. In Forenbeiträgen anderer Entwickler mit derselben Androhung stellte er fest, dass die meisten Berufungen wochenlang unbeantwortet blieben. Die einzige Wiedereinsetzung, die er fand, erfolgte nach einer zweiten Berufung, die die tatsächliche Ursache benannte und alles Weitere offenlegte.

    Lösung

    Berufungsvorbereitung zum Zeitpunkt der Veröffentlichung.

    Lektion

    Zwei Ablehnungen unter derselben Richtlinie können inzwischen ausreichen, um ein Konto in Gefahr zu bringen. Wenn eine Inhaltsablehnung vage ist, bitten Sie App Review, den genauen Screen oder das Asset zu benennen, bevor Sie erneut einreichen. Führen Sie ein Protokoll über jede Änderung und behandeln Sie die zweite Ablehnung als Signal, innezuhalten, statt es erneut zu versuchen.

73. 

    Richtlinien 2.3.7, 5.2.5 und 4.8 iOS Richtlinie 2.3.7 Metadaten und IAP Login-Pflicht

    Auf dem Mac freigegeben, dann auf dem iPhone unter 2.3.7, 5.2.5 und 4.8 abgelehnt – dieselbe App

    Was passiert ist

    Ein Entwickler, der einen Kalender-Client für einen großen Drittanbieter-Kalenderdienst baut, hat zuerst die Mac-Version veröffentlicht. Für die Mac-Version war bereits ein formaler Einspruch nötig, nur um im Store-Eintrag zu erwähnen, dass sie mit diesem Kalenderdienst funktioniert, und sie hatten App Review bereits erklärt, warum es kein Sign in with Apple braucht. Als sie die iPhone-Version unter demselben Bundle und derselben App ID wie die Mac-App hinzufügten, wurde sie wegen drei Richtlinien gleichzeitig abgelehnt: 2.3.7 wegen Preisen, die in einem In-App-Event angezeigt wurden, 5.2.5 wegen einer Zeile, die besagte, die App sei für iPhone, iPad und Mac, und 4.8, weil Sign in with Apple nicht neben dem Login des Kalenderdienstes angeboten wurde. Richtlinie 4.8 hat eine Ausnahme für Apps, die Clients eines bestimmten Drittanbieter-Dienstes sind – genau das ist diese App –, aber die Erklärung für die Mac-Version wurde nicht übernommen. Jedes Plattform-Target wurde von Null an neu geprüft.

    Lösung

    Zum Zeitpunkt des Beitrags nicht angegeben.

    Lektion

    Eine neue Plattform bedeutet einen neuen Review, selbst innerhalb derselben App ID. Kopiere jede Erklärung und Ausnahme, die du bereits erfolgreich durchgesetzt hast, in die Review-Notizen für jede Plattform, und prüfe In-App-Events und Beschreibungen vor dem Einreichen auf Preise und Apple-Gerätenamen.

74. 

    Guideline 3.1.2(c), dann Apple-Markenzeichen im Siri-Text (Richtliniennummer nicht genannt) iOS Richtlinie 3.1.2 Endlose Reviews

    Neun Tage Wartezeit, eine 3.1.2(c)-Paywall-Ablehnung, dann ein Binary, in 42 Sekunden wegen Siri-Text abgelehnt

    Was passiert ist

    Ein Entwickler mit einem neuen Account reichte die erste Version einer App für Schreibgewohnheiten ein und wartete etwa neun Tage, bis sie in den Status „In Review“ wechselte. Fünfzig Minuten später wurde sie unter Guideline 3.1.2(c) abgelehnt: Beim Jahresabo wurde der berechnete Monatspreis in größerer Schrift angezeigt als der tatsächlich abgerechnete Jahrespreis. Sie korrigierten die Schriftgrößen der Paywall und luden einen neuen Build hoch. Dieser Build wurde automatisch in 42 Sekunden abgelehnt, weil der Hilfetext eines Siri-Shortcuts eine Apple-App mit ihrem Markennamen nannte – und Texte in Siri-Intents das Wort „Apple“ nicht enthalten dürfen. Sie formulierten es so um, dass es allgemein auf die Notizen-App verweist, und luden den Build erneut hoch.

    Lösung

    Erneut eingereicht, Ergebnis zum Zeitpunkt des Beitrags unbekannt.

    Lektion

    Bevor Sie das erste Mal einreichen, sollte der abgerechnete Betrag bei jedem Plan die prominenteste Preisangabe sein. Durchsuchen Sie alle nutzerseitigen Strings – inklusive Siri, Shortcuts und Widget-Text – nach Apple-Trademarks. Automatisierte Checks finden diese in Sekunden, aber jede Runde kostet Sie trotzdem einen Platz in der Warteschlange.

75. 

    Abschnitt 3.2(f) (Developer Program License Agreement) mit Verweis auf eine frühere Namensablehnung iOS Account-Kündigung Metadaten und IAP

    Eine Namensablehnung wurde behoben und die App genehmigt, dann fast ein Jahr später eine Kündigungsmitteilung wegen Betrugs

    Was passiert ist

    Ein Solo-Entwickler mit einem kleinen Firmenkonto hatte in etwa anderthalb Jahren acht Live-Apps gebaut. Fast ein Jahr zuvor war eine dieser Apps abgelehnt worden, weil Apple Einwände gegen ein Wort im Namen erhoben hatte. Der Entwickler änderte den Namen, die App wurde erneut geprüft und freigegeben, und auch ein späteres Update wurde genehmigt. Die geteilte Review-Historie zeigt, dass Version 1.0 an zwei aufeinanderfolgenden Tagen abgelehnt und am Tag darauf freigegeben wurde; ein Update etwa zwei Monate später wurde beim ersten Versuch genehmigt. Danach blieb die App etwa neun Monate lang unangetastet. Dann wurde eine neue App desselben Kontos abgelehnt, und eine Mitteilung über die bevorstehende Kündigung traf ein, die unehrliche oder betrügerische Aktivitäten gemäß Abschnitt 3.2(f) anführte: Einreichungen hätten wiederholt gegen die Richtlinien verstoßen, um die Prüfung zu umgehen, und Probleme aus früheren Nachrichten seien ungelöst geblieben. Sie nannte kein neues Problem und kam ohne vorherige Warnung oder Rückfrage. Die Einnahmen aller Apps wurden ausgesetzt, auch bei Apps, die nie ein Problem hatten, und die Mitteilung warnte, dass auch ein neues Konto gekündigt werden könnte. Die einzige Antwortmöglichkeit war ein Webformular, das auf 2.000 Zeichen begrenzt war und lediglich eine automatisierte Bestätigung lieferte, gefolgt von Schweigen. Der Entwickler akzeptierte die Entfernung der markierten Apps, schaltete noch am selben Tag seine Server ab, setzte alle Einreichungen aus und reichte am ersten Tag einen vollständigen Einspruch ein.

    Lösung

    Einspruch am ersten Tag eingereicht; zum Zeitpunkt der Veröffentlichung nur eine automatisierte Bestätigung.

    Lektion

    Eine Ablehnung, die du behoben und genehmigt bekommen hast, kann Monate später noch als Teil eines Musters herangezogen werden. Bewahre jede Ablehnungsnachricht, die genaue Änderung und die anschließende Genehmigung auf, damit du die komplette Historie in einem kurzen Einspruchsformular zeigen kannst – und rechne nach dem Absenden nicht mit einem Zeitplan.

76. 

    Guidelines 4.3 Spam und 4.2.6 iOS Richtlinie 4.3 Richtlinie 4.2.6

    Ein allein entwickeltes Spiel zweimal als Spam und als Template abgelehnt, neun Antworten geschickt, keine Reaktion

    Was passiert ist

    Ein Entwickler, der abends alleine Spiele entwickelt, reichte ein Originalspiel ein und wurde Anfang Oktober zweimal im Abstand von vier Tagen abgelehnt: unter Guideline 4.3 (Spam) und unter 4.2.6 (Apps, die auf kommerzialisierten Templates oder App-Generatoren basieren). Dabei war kein Template im Spiel, jede Zeile Code stammte vom Entwickler selbst. Beide Ablehnungen kamen mit demselben vorgefertigten Text zurück, und keine nannte die App, der das Spiel angeblich ähneln sollte. Apple schickte dann neun Fragen dazu, wie das Spiel gemacht wurde, und der Entwickler beantwortete alle einen Tag nach der zweiten Ablehnung ausführlich. Es kam keine Antwort. Etwa neun Tage später legte er Einspruch beim App Review Board ein, und eine Woche danach wartete er immer noch. Seine eigene Vermutung: Wenn eine Person innerhalb weniger Monate mehrere Spiele veröffentlicht, wirkt das aus Sicht der Reviewer wie eine App-Fabrik. In der Zwischenzeit hat er das Spiel kostenlos im Browser spielbar gemacht.

    Lösung

    Einspruch beim App Review Board, zum Zeitpunkt der Veröffentlichung noch anhängig, etwa drei Wochen nach der ersten Ablehnung.

    Lektion

    4.3 und 4.2.6 können über deinen gesamten Account beurteilt werden, nicht anhand einer einzelnen Binary. Wenn du in kurzer Zeit mehrere Apps veröffentlichst, zeige ab der ersten Einreichung, was jede einzelne originell macht – mit Review-Notizen zum Build und einem kurzen Gameplay-Video, denn sobald der Ablehnungstext aus der Vorlage kommt, bleiben detaillierte Antworten wochenlang ungelesen.

77. 

    Guideline 2.1 App Completeness, dann Guideline 5 Legal (Verfügbarkeit in China) iOS Richtlinie 2.1 Richtlinie 5 Rechtliches Endlose Reviews

    Eine Gratis-Lizenz für den Reviewer verdeckte die Paywall, dann sechs Tage in der Queue und eine Ablehnung durch die China-KI

    Was passiert ist

    Ein Entwickler reichte seine erste iOS-App ein – ein persönliches Finanztool zum Verfolgen wiederkehrender Zahlungen – und sie wurde unter Richtlinie 2.1 (App-Vollständigkeit) abgelehnt. Die Ursache war eine gut gemeinte Geste, die nach hinten losging: Der Reviewer hatte per E-Mail eine bezahlte Lizenz erhalten, sodass er die Paywall übersprang und den Kaufprozess nie sah. Der Entwickler erstellte einen detaillierten PDF-Leitfaden mit Screenshots für den Reviewer und reichte die App erneut ein, diesmal die iOS- und die Mac-Version zusammen. Die neue Einreichung wartete sechs Tage, bis sie den Status „In Review“ erhielt, und wurde dann erneut abgelehnt – diesmal wegen einer Erwähnung von ChatGPT, während die App in Festlandchina verfügbar war.

    Lösung

    Zum Zeitpunkt des Beitrags weiterhin abgelehnt, während ein neuerer Build über TestFlight an Tester angeboten wurde.

    Lektion

    Sorge dafür, dass App Review genau sieht, was ein neuer Nutzer sieht – inklusive Paywall. Gib dem Reviewer ein funktionierendes Demo- oder Sandbox-Konto und klare Hinweise statt einer kostenlosen Lizenz, die den Kaufprozess verbirgt. Wenn die App oder ihr Listing einen KI-Anbieter wie ChatGPT nennt, prüfe vor der Einreichung, ob Festlandchina in deiner Verfügbarkeit enthalten ist, da jede neue Runde Tage in der Warteschlange kosten kann.

78. 

    Richtlinie 2.3.10 (Korrekte Metadaten) iOS Richtlinie 2.3.10 Metadaten und IAP Endlose Reviews

    Zehn Tage bis zum ersten Review, eine Google-Play-Erwähnung, dann zwei weitere Wochen Warten

    Was passiert ist

    Ein Entwickler mit einem brandneuen Entwickleraccount hat Anfang Oktober eine brandneue App eingereicht. Da Nutzer dort eigene Bilder öffentlich hochladen können, rechnete der Entwickler mit strengerer Content-Moderation. Das erste Review kam zehn Tage später, auf einem iPad, und endete mit einer Ablehnung gemäß Guideline 2.3.10 Accurate Metadata: Die App oder ihre Metadaten erwähnten eine Drittanbieter-Plattform, der nächste Schritt war, die Google-Play-Referenzen zu entfernen. Der Entwickler fand die Erwähnung im Text zu einem In-App-Kauf. Nach der Korrektur ging die App zurück in die Warteschlange, und zwei Wochen später wartete sie noch immer auf das Review – 24 Tage nach der ersten Einreichung und noch immer nicht live.

    Lösung

    Zum Zeitpunkt des Beitrags noch immer im Review, 24 Tage nach der ersten Einreichung.

    Lektion

    Durchsuche vor der ersten Einreichung jedes Textfeld, das du einreichst, inklusive der Beschreibungen für In-App-Käufe, nach Namen anderer Stores und Plattformen. Bei einem neuen Account kann jeder Durchlauf eine Woche oder mehr in der Queue kosten – da kann schon ein einziges Wort den Launch um Wochen verzögern.

79. 

    Guideline 2.1 App-Vollständigkeit (Informationen erforderlich) iOS Richtlinie 2.1 Endlose Reviews

    24 Tage in der Warteschlange, dann eine 2.1-Ablehnung mit der Forderung nach einem Full-Screen-Recording

    Was passiert ist

    Ein Entwickler reichte Version 1.0.0 einer neuen iOS-App zusammen mit einer Subscription-Gruppe und zwei Abonnements (jährlich und monatlich) ein. Nach 24 Tagen Wartezeit prüfte Apple die App und lehnte sie gemäß Guideline 2.1 (App Completeness) ab, was den Entwickler laut eigener Aussage ratlos zurückließ. Da die App-Version abgelehnt wurde, konnten auch die zusammen mit ihr eingereichten Abonnements nicht genehmigt werden; sie verblieben im Status „Ready for Review“. Die Ablehnung erfolgte als „2.1 Information Needed“-Anfrage – das erste Mal, dass der Entwickler eine solche erhielt. Gefordert wurde ein Screen-Recording auf einem physischen Gerät mit dem neuesten Betriebssystem, das den typischen User Flow zeigt: vom App-Start über Registrierung, Login und Kontolöschung bis hin zu nutzergenerierten Inhalten inklusive Melde- und Blockierfunktionen sowie dem Zugriff auf kostenpflichtige Inhalte. Zudem wurden eine Beschreibung von Zweck und Zielgruppe, Setup-Anweisungen inklusive Login-Daten, eine Liste der genutzten externen Dienste (einschließlich KI-Dienste), etwaige regionale Unterschiede sowie Dokumentation für regulierte Branchen oder geschütztes Material Dritter angefordert. Die Antworten mussten zudem in den Review-Notizen in App Store Connect für zukünftige Einreichungen hinterlegt werden.

    Lösung

    Zum Zeitpunkt des Beitrags machte sich der Entwickler wieder an die Vorbereitung der Aufnahme und der Antworten. Ergebnis unbekannt.

    Lektion

    Eine „Information Needed“-Anfrage nach Wochen in der Warteschlange kostet eine weitere komplette Runde. Nimm den Walkthrough auf einem echten Gerät auf und schreibe die Antworten in die Review-Notizen, bevor du eine neue App einreichst – besonders bei Apps mit Abos, Accounts oder nutzergenerierten Inhalten, da eine abgelehnte Version auch alles blockiert, was damit eingereicht wurde.

80. 

    Abschnitt 3.2(f) (Developer Program License Agreement) Apple Developer Program Account-Kündigung Endlose Reviews

    Sechs genehmigte Updates in Folge, dann ein Routine-Update und eine Sperrung nach 3.2(f)

    Was passiert ist

    Ein Indie-Entwickler hatte sechs Updates in Folge genehmigt bekommen. Der geteilte Review-Verlauf zeigt die aktuellste Einreichung „In Review“ und alle vorherigen als „Review Completed“. Mitte Oktober reichte er dann ein Routine-Update ein, das im Review stecken blieb. Statt eines Review-Ergebnisses wurde der gesamte Developer-Account unter Abschnitt 3.2(f) gesperrt. In App Store Connect war am Tag dieser Einreichung eine Nachricht an mehrere Versionen angehängt und als ungelöste Probleme markiert. Der Entwickler beschrieb seine Apps als nativ, mit einer sauberen Bilanz genehmigter Updates, und gab an, dass der Apple Support seinen Einspruch prüft.

    Lösung

    Einspruch zum Zeitpunkt des Beitrags in Prüfung.

    Lektion

    Eine lückenlose Approval-Serie schützt nicht vor einer Kündigung nach 3.2(f). Führe ein datiertes Protokoll über jede Einreichung, jede Review-Nachricht und jede Genehmigung, und prüfe nach jedem Review den Messages-Bereich in App Store Connect, damit du die vollständige Historie vorlegen kannst, sobald ein Widerspruch möglich ist.

81. 

    Anfrage zu App-Review-Informationen (Demo-Account und Screen-Recording) iOS Anmelden

    Das Demo-Konto wurde fünf Minuten nach der Einreichung gelöscht, gefolgt von einer Anfrage zur Aufnahme, die eine zweite Ablehnung verhinderte

    Was passiert ist

    Eine Agentur reichte eine Kunden-App mit einem Demo-Account für App Review ein. Fünf Minuten nach der Einreichung hatte App Review diesen Demo-Account bereits gelöscht. Apple forderte daraufhin ein Screen Recording der App an. Während der Aufnahme entdeckte das Team Verkaufstexte in der App, die ihnen entgangen waren und die zu einer erneuten Ablehnung geführt hätten.

    Lösung

    Endstand zum Zeitpunkt der Veröffentlichung nicht bekannt.

    Lektion

    Ein Reviewer löscht eventuell das von dir bereitgestellte Demo-Konto – zum Beispiel, um zu prüfen, ob die Kontolöschung funktioniert. Sorge also dafür, dass du es neu erstellen kannst, oder stelle mehr als eines bereit. Nimm deinen eigenen Review-Durchlauf auf, bevor du einreichst: Die App so anzuschauen, wie ein Reviewer es tut, ist ein einfacher Weg, um Formulierungen zu finden, die die nächste Ablehnung auslösen würden.

82. 

    Abschnitt 3.2(f) (Developer Program License Agreement) Apple Developer Program Account-Kündigung Metadaten und IAP

    Fünf frühe Ablehnungen, vier genehmigte Updates, dann eine 3.2(f)-Benachrichtigung über ein Jahr später

    Was passiert ist

    Ein unabhängiger iOS-Entwickler mit fast zehn Jahren Erfahrung und zahlreichen Apps im Rücken reichte im April 2025 eine neue KI-App zur Umwandlung von Bildern in Videos ein. Nutzer konnten eigene Fotos hochladen, die erste Generierung war kostenlos, danach konnten Credits als Einmalkäufe im App Store erworben werden – ohne Abo. Die erste Einreichung wurde fünfmal abgelehnt, hauptsächlich wegen Screenshots und Metadaten: Screenshots wurden als zu werbeorientiert eingestuft, und ein Screenshot mit einem küssenden Paar, dann sein Ersatz mit einem Heiratsantrag, wurden unter der Richtlinie für anstößige Inhalte markiert. Nach Änderungen an den Screenshots, dem Text und dem Build wurde die App freigegeben, und vier Updates folgten ohne eine einzige Ablehnung, das letzte im August 2025. Danach wurde kein Update mehr eingereicht. Mehr als vierzehn Monate später traf eine Benachrichtigung über eine bevorstehende Kündigung ein, die besagte, dass Einreichungen vom Konto wiederholt gegen die Richtlinien verstoßen hätten, um die Prüfung zu umgehen, wobei Verstöße nach mehreren erneuten Einreichungen weiterhin ungelöst seien, und sie war an allen fünf Versionen angeheftet. Der Entwickler sagte, App Store Connect zeige nicht mehr genügend Details, um die alten Ablehnungen nachzuvollziehen. Er legte etwa 30 Minuten nach dem Eingang der Benachrichtigung gegen Mitternacht Berufung ein, innerhalb eines Limits von 2.000 Zeichen, und wünschte sich später, er hätte gewartet, um sie klarer zu formulieren.

    Lösung

    Appeal pending at time of posting.

    Lektion

    Eine Freigabe schließt den Vorgang nicht ab. Bewahre eine eigene Kopie jeder Ablehnungsnachricht, der zitierten Richtlinie, deiner Änderungen und des Freigabedatums auf, da App Store Connect ältere Details später möglicherweise nicht mehr anzeigt. Wenn eine Benachrichtigung eingeht, nimm dir Zeit, um eine klare Berufung zu verfassen, die in das Zeichenlimit passt, statt sie in der ersten Stunde abzuschicken.

83. 

    Abschnitt 3.2(f) (Developer Program License Agreement) Apple Developer Program Account-Kündigung Metadaten und IAP

    Ein Titel-Keyword, eine Kündigung nach 3.2(f) und eine Berufungsantwort, die auf Streaming-Verweise verwies

    Was passiert ist

    Ein Indie-Entwickler hatte sein gesamtes Entwickler-Konto gemäß Abschnitt 3.2(f) gekündigt bekommen. Laut seinen Angaben geschah dies ohne Vorwarnung und ohne frühere Ablehnung von Metadaten; er glaubte, die Ursache sei ein Keyword-Fehler im App-Titel gewesen. Er legte Berufung ein. Das App Review Board antwortete, dass seine Untersuchung Richtlinienverstöße bestätigt habe: Eine der Apps des Entwicklers enthielt irreführende Verweise, die Nutzer dazu brachten, zu glauben, es handle sich um einen Streaming-Dienst – was Apple als schwerwiegend bezeichnete. Der Brief beschrieb ein Muster manipulativen oder irreführenden Verhaltens, hielt die Auszahlung der Einnahmen an und erklärte, dass der Entwickler nach formeller Kündigung beim App Review Board um Wiedereinsetzung bitten könne, indem er die Gründe und die geplanten Verbesserungen darlegt.

    Lösung

    Einspruch abgelehnt. Ein Wiedereingliederungsantrag ist nach formeller Kündigung möglich.

    Lektion

    Wörter im Titel oder in den Keywords, die auf einen Dienst hinweisen, den die App nicht bietet (z. B. Streaming), können als irreführend statt als einfacher Metadatenfehler gewertet werden. Das kann direkt zur Kündigung führen, ohne dass es vorher eine Ablehnung gibt. Prüfe vor dem Einreichen jeden Titel, jede Untertitel und jedes Keyword daraufhin, was die App tatsächlich tut.

84. 

    Richtlinie 4.1(a) Copycats iOS Endlose Reviews

    15 Tage in der Prüfung, dann 4.1(a) Copycats für Filmplakate aus einer öffentlichen API

    Was passiert ist

    Ein Entwickler baute eine iOS-App, die Menschen bei der Auswahl eines Films hilft. Sie zeigt Titel und Plakate, die aus einer öffentlichen Filmdatenbank API stammen und in der App genannt werden. Der Watch-Button öffnet die offizielle Streaming-App, statt selbst etwas zu streamen. Nach 15 Tagen in der Prüfung lehnte Apple die App unter der Richtlinie 4.1(a) Copycats ab, behandelte die Plakate als Inhalte Dritter und verlangte den Nachweis der Nutzungsrechte oder deren Entfernung. Dieselbe App mit denselben Plakaten war auf Android und im App-Store eines TV-Geräts genehmigt worden.

    Lösung

    Zum Zeitpunkt der Veröffentlichung ungelöst. Der Entwickler fragte andere Entwickler, ob die API-Bedingungen als Nachweis akzeptiert wurden oder ob die Poster entfernt werden mussten.

    Lektion

    Credits in der App und Genehmigungen in anderen Stores gelten nicht als Rechte für die App-Review. Wenn deine App Poster, Kunstwerke oder Logos von einem API anzeigt, bereite vor der Einreichung schriftliche Nachweise vor, dass du sie anzeigen darfst, oder plane eine Version ohne diese Inhalte.

85. 

    Metadaten-Ablehnung (lokalisiertes Keyword) iOS Metadaten und IAP

    KI übersetzte die App in fünf Sprachen und schmuggelte ein Keyword ein, das zur Ablehnung führte

    Was passiert ist

    Ein Entwickler nutzte ein KI-Modell, um seine App in fünf weitere Sprachen zu übersetzen. In einer dieser Sprachen fügte die Übersetzung ein Keyword hinzu, das missverstanden werden konnte, woraufhin die Einreichung abgelehnt wurde. Eine Woche später wartete der Entwickler immer noch auf eine Antwort und machte sich Sorgen, dass selbst eine genehmigte Korrektur später gegen das Konto verwendet werden könnte, nachdem er eine Woche lang von 3.2(f)-Kündigungen durch andere Entwickler gehört hatte.

    Lösung

    Zum Zeitpunkt der Veröffentlichung wartet man noch auf eine Antwort von Apple.

    Lektion

    Lass jemanden, der jede Sprache liest, alle lokalisierten Keywords, Titel und Untertitel prüfen, bevor du einreichst. Maschinelle Übersetzung ist schnell, aber App Review bewertet die Wörter in jeder Region so, als hättest du sie selbst gewählt.

86. 

    App-Preview-Metadaten (Preisreferenz) iOS Metadaten und IAP

    Eine App-Preview bewarb ein kostenloses Testangebot, und das Update wurde abgelehnt

    Was passiert ist

    Ein Indie-Entwickler reichte ein Update ein, dessen App-Preview-Video die Wörter „kostenloses Testangebot verfügbar“ enthielt. Apple lehnte das Update ab und behandelte jede Erwähnung von „kostenlos“ in der Preview als Preisreferenz. Der Entwickler schnitt das Video neu und reichte es erneut ein.

    Lösung

    Video re-cut and resubmitted. Final outcome not shared at time of posting.

    Lektion

    Halte Preise und das Wort „kostenlos“ aus App-Vorschauen heraus, selbst wenn die Testphase echt ist. Zeige die Testbedingungen stattdessen in der App auf der Paywall an.

87. 

    Richtlinie 2.5.1 Softwareanforderungen (HealthKit) iOS Endlose Reviews

    Sechs Tage Wartezeit, dann 2.5.1, weil der Health-Sync kein Apple-Health-Badge hatte

    Was passiert ist

    Ein Indie-Entwickler reichte ein umfangreiches Update ein, das erstmals Apple-Health-Sync hinzufügte. Es lag sechs Tage im Status „Wartet auf Prüfung“. Erst dann bemerkte er, dass in seinem Konto eine neue Entwicklervereinbarung zur Unterschrift wartete. Er unterschrieb, und das Update ging noch am selben Nachmittag in die Prüfung, obwohl er nicht sagen konnte, ob beides zusammenhing. Das Update wurde dann wegen Richtlinie 2.5.1 abgelehnt, weil die Health-Funktion in der App-Oberfläche nicht klar gekennzeichnet war. Vom Apple-Health-Badge hatte der Entwickler nichts gewusst.

    Lösung

    Das „Works with Apple Health“-Badge neben dem Sync-Schalter hinzugefügt, dazu eine Review-Notiz und ein Screen Recording von einem echten Gerät. Bei der nächsten Einreichung genehmigt.

    Lektion

    Wenn deine App Health-Daten liest oder schreibt, zeige das ab der allerersten Einreichung klar in der Oberfläche mit dem Apple-Health-Badge. Und wenn eine Review tagelang stillsteht, prüfe zuerst in App Store Connect, ob eine Vereinbarung noch nicht unterschrieben ist.

88. 

    Richtlinie 1.1: Unangemessene Inhalte iOS Anstößige Inhalte

    Über ein Jahr live ohne Ablehnungen, dann ohne Vorwarnung unter 1.1 entfernt

    Was passiert ist

    Ein Indie-Entwickler hatte seine App seit über einem Jahr im App Store. Sie war nie abgelehnt worden und brachte ein bescheidenes monatliches Abo-Einkommen ein. Ohne Vorwarnung schickte Apple eine Nachricht, dass die App wegen Verstoßes gegen Guideline 1.1 Objectionable Content aus dem Store entfernt wurde.

    Lösung

    Der Entwickler teilte Apple mit, dass er die App nicht erneut einreichen würde, und gab die App sowie die gesamte Nische auf, um seinen Developer-Account nicht zu gefährden.

    Lektion

    Eine saubere Review-Historie schützt eine App nicht davor, später entfernt zu werden, und Content-Regeln lassen sich auch auf eine App anwenden, die lange freigegeben war. Wenn deine App in einer sensiblen Nische steckt, prüfe Inhalte und Screenshots jetzt gegen Guideline 1.1 – nicht erst nach einer Entfernungsmitteilung.

89. 

    Bug-Ablehnung (Guideline nicht angegeben) iOS Endlose Reviews

    Ein 100-Sekunden-Matchmaking-Timeout wurde als Bug gemeldet, dann sechs Tage lang auf eine Antwort gewartet

    Was passiert ist

    Ein Entwickler reichte ein Multiplayer-Spiel ein. Der Reviewer lehnte es wegen eines Bugs ab, doch es war kein Crash: Das Spiel stoppt die Suche nach 100 Sekunden Wartezeit auf einen Gegner, und der Reviewer wertete diesen Timeout als fehlerhaftes Verhalten. Der Entwickler erklärte dem Reviewer, wie das Matchmaking funktioniert, und entfernte den Timeout zusätzlich aus dem Spiel. Sechs Tage später wartete er noch immer auf eine einzige Antwort.

    Lösung

    In einer Antwort erklärt und den Timeout entfernt. Zum Zeitpunkt des Posts wartete ich noch auf eine Antwort.

    Lektion

    Ein Reviewer spielt oft allein und zu ungewöhnlichen Zeiten, daher ist eine leere Matchmaking-Warteschlange wahrscheinlich. Gib dem Review-Team eine Möglichkeit, ein echtes Spiel zu erreichen, z. B. einen Bot-Gegner oder einen Demo-Modus, und erkläre dies in den Review-Notizen vor der Einreichung.

90. 

    Metadaten-Ablehnung (Links zu Nutzungsbedingungen und Datenschutz) iOS Metadaten und IAP

    Code aus einer anderen App wiederverwendet, und die Links zu Nutzungsbedingungen und Datenschutz zeigten noch auf die alte App

    Was passiert ist

    Ein Entwickler baute eine neue App zum Teil, indem er Teile aus einer seiner früheren Apps wiederverwendete. Die Links zu den Nutzungsbedingungen und der Datenschutzerklärung darin zeigten noch auf die alte App, und App Review lehnte die Einreichung deshalb ab. Der Entwickler sagte, die Ablehnungsnachricht habe genau beschrieben, was geändert werden musste.

    Lösung

    Links korrigiert und erneut eingereicht. Laut Entwickler kam ein beschleunigtes Review meist nach etwa einem Tag zurück, sollte aber sparsam genutzt werden.

    Lektion

    Bevor du eine App aus einem älteren Projekt einreichst, prüfe alle Links, Bundle-Namen und rechtlichen Seiten, die übernommen wurden. Lies die Ablehnungsnachricht genau, da sie oft exakt sagt, was zu korrigieren ist.

91. 

    Richtlinie 2.1: Informationen erforderlich iOS Richtlinie 2.1

    Keine Bugs im Report, nur 2.1 Information Needed, beantwortet mit einer 89-Sekunden-Aufnahme

    Was passiert ist

    Ein Entwickler hat seine zweite App eingereicht, die jedoch unter Guideline 2.1 Information Needed zurückkam, ohne dass ein Bug gelistet war. App Review wollte ein Screen-Recording plus Antworten dazu, für wen die App ist, wie sie genutzt wird, auf welche externen Services sie angewiesen ist und welche Regionen sie targetet. Der Entwickler nahm 89 Sekunden auf dem Simulator auf – vom Start über eine vollständige Nutzung des Hauptfeatures bis zur Paywall –, beantwortete alle Fragen in den Notizen und reichte noch am selben Tag erneut ein.

    Lösung

    Aufnahme und Antworten wurden am selben Tag gesendet. Das Endergebnis wurde zum Zeitpunkt des Posts nicht mitgeteilt.

    Lektion

    Bei einer neuen App ist mit einer 2.1-Informationsanfrage zu rechnen – bereite dich darauf vor. Halte eine kurze Aufnahme des Haupt-Flows sowie schriftliche Antworten zu Zielgruppe, Nutzung, externen Diensten und Regionen in den Review-Notizen bereit, bevor du einreichst, damit der erste Review nicht wegen Rückfragen stoppt.

92. 

    Guideline 2.5.4 Software-Anforderungen (Background Modes) iOS Endlose Reviews

    Abgelehnt wegen einer einzigen übrig gebliebenen Checkbox, dem Audio Background Mode, danach zehn Tage Wartezeit auf das nächste Update

    Was passiert ist

    Ein kleines Team reichte ein Update für eine App ein, die bereits live war. Der App Review lehnte es unter Guideline 2.5.4 wegen einer einzigen Einstellung ab: Der Audio Background Mode war aktiviert, obwohl die App ihn nicht brauchte. Das Team entfernte den Background Mode und reichte am selben Tag erneut ein, was sie etwa einen Tag kostete. Das darauffolgende Update hing dann rund zehn Tage im Review fest.

    Lösung

    Audio-Background-Modus entfernt und noch am selben Tag erneut eingereicht. Das folgende Update wartete etwa zehn Tage in der Prüfung.

    Lektion

    Background-Modes sind nur für ihren vorgesehenen Zweck erlaubt. Vor jeder Einreichung die Background-Modes-Funktion öffnen und alles entfernen, was die App nicht tatsächlich nutzt, denn ein vergessenes Häkchen reicht für eine Ablehnung, und man kann nicht vorhersagen, wie lange die nächste Prüfung dauert.

93. 

    Richtlinie 4.3(a) Spam iOS Richtlinie 4.3

    Eine Web-App in einem Wrapper bekam 4.3(a) spam, also baute der Entwickler sie als native App neu auf

    Was passiert ist

    Ein Entwickler reichte die erste Version seiner App als Web-App in einem nativen Wrapper ein. App Review lehnte sie wegen Guideline 4.3(a), der Spam-Regel, ab. Der Entwickler räumte ein, dass Apple recht hatte. Er baute die App als echte native App neu auf, verlegte das Backend auf einen Relay-Server, den er selbst betreibt, und veröffentlichte den Quellcode auf code.

    Lösung

    Neu als native App mit einem selbst gehosteten Relay-Server aufgebaut. Das Ergebnis der neu gebauten Version wurde im Beitrag nicht geteilt.

    Lektion

    Ein dünner Wrapper um eine Website wird von der App-Review leicht als Spam interpretiert. Wenn du in den App Store gehst, gib der App von der ersten Einreichung an echten nativen Mehrwert, statt zu hoffen, dass eine eingepackte Seite durchkommt.

94. 

    Ablehnung wegen anstößiger Inhalte (Screenshots, dann Untertitel) iOS Anstößige Inhalte Metadaten und IAP

    Screenshots als anstößig markiert, dann der Untertitel, für ein Spiel ohne adulte Inhalte

    Was passiert ist

    Ein kleines Studio erstellt einfache Story-Games für iOS, ohne adulte Themen, Glücksspiel oder Krypto. Ein Spiel, in dem der Spieler ein Promi ist, der es in Hollywood schaffen will, wurde wegen anstößiger Inhalte in den Screenshots abgelehnt. Die Screenshots zeigten nur vollständig bekleidete Charaktere aus dem Spiel. Das Studio ersetzte jeden Screenshot und reichte erneut ein. Die nächste Ablehnung betraf anstößige Inhalte im Untertitel, der das Spiel lediglich als Promi-Leben- und Drama-Spiel beschrieb. Jede Prüfung dauerte Wochen.

    Lösung

    Die App wurde erstmals im September eingereicht und war Ende Oktober immer noch nicht freigegeben.

    Lektion

    Wenn App Review Metadaten als anstößig markiert, ohne den Grund zu nennen, frage in App Store Connect nach, welches genaue Element das Problem ist und warum, bevor du alles neu machst. Prüfe Screenshots, Untertitel und Keywords gemeinsam, bevor du erneut einreichst, denn das Beheben des einen Problems deckt oft schon das nächste auf.

95. 

    Richtlinie 5.2.5 Rechtliches, geistiges Eigentum iOS Richtlinie 5 Rechtliches Metadaten und IAP

    Abgelehnt unter 5.2.5, weil die Screenshots ein Gerät zeigten, das wie ein iPhone aussah

    Was passiert ist

    Ein Entwickler wurde nach Richtlinie 5.2.5 abgelehnt. App Review erklärte, die Metadaten enthielten in den Screenshots Abbildungen, die einem iPhone ähnelten und bei Nutzern zu Verwechslungen mit Apple-Produkten führen könnten. Die gezeigten Geräte waren keine Apple-Geräte, sondern nur Apple-ähnliche. Der Entwickler war überrascht, weil eine andere seiner Apps bereits mit derselben Art von Gerätedarstellung genehmigt worden war.

    Lösung

    Das Endergebnis wurde zum Zeitpunkt des Beitrags nicht genannt. Ein anderer Entwickler antwortete, dass App Review auch Geräterahmen beanstanden kann, die nicht zur Plattform passen, oder Renders, die von echten iPhones abweichen.

    Lektion

    Die Freigabe einer App begründet keinen Präzedenzfall für die nächste. Gerätemockups, die fast wie ein iPhone aussehen, können als verwechselbar ähnlich mit Apple-Produkten gelten. Verwende einfache Screenshots oder nur Geräterahmen, die Apple für Marketing bereitstellt, und achte darauf, dass sie zur Plattform passen.

96. 

    Richtlinie 2.1: Informationen erforderlich iOS Richtlinie 2.1

    Erste iOS-App erhielt eine 2.1-Informationsanfrage; die Lösung war, alles auffindbar zu machen

    Was passiert ist

    Ein Solo-Entwickler, dessen Android-Version bereits auf Google Play live war, reichte seine erste iOS-App ein. Sie enthielt drei In-App-Käufe und nutzergenerierte Inhalte. Die App-Prüfung lehnte sie nicht sofort ab, sondern sandte eine Informationsanfrage gemäß Richtlinie 2.1. Der Entwickler las Richtlinie 2.1 erneut, die verlangt, dass jeder In-App-Kauf für den Prüfer sichtbar und funktionsfähig ist, und prüfte auch die Regeln für nutzergenerierte Inhalte (1.2) und die Kontolöschung (5.1.1(v)). Am nächsten Tag reichte er einen neuen Build ein, bei dem für jeden Inhalt eine sichtbare Melde- und Sperrfunktion vorhanden war, Community-Regeln, die Nutzer vor dem Posten akzeptieren, die Möglichkeit zum Abmelden und Kontowechsel sowie eine Bildschirmaufnahme, die zeigt, wo sich Käufe, Sicherheitstools und Konto-Steuerungselemente befinden.

    Lösung

    Neuer Build am Tag nach der Anfrage eingereicht. Ergebnis zum Zeitpunkt der Veröffentlichung unbekannt.

    Lektion

    Behandle die Prüfung wie einen Usability-Test mit einem Fremden unter Zeitdruck. Jeder Kauf, jede Melde- und Sperrfunktion sowie jede Konto-Steuerung muss in Sekunden auffindbar sein, und eine Aufnahme in den Prüfungshinweisen sollte auf jedes Element verweisen. Dass die App auf Google Play live ist, sagt nichts darüber aus, ob sie die App-Prüfung besteht.

97. 

    Richtlinie 4.3(a) Design, Spam iOS Richtlinie 4.3 Endlose Reviews

    Siebenundzwanzig Tage in der Warteschlange für eine neue App, dann eine 4.3(a)-Spam-Ablehnung

    Was passiert ist

    Ein Entwickler hat eine brandneue App eingereicht und 27 Tage auf die App Review gewartet. Als das Ergebnis endlich in App Store Connect auftauchte, war es eine Ablehnung nach Guideline 4.3(a), Design, Spam. Der Entwickler fragte daraufhin andere Entwickler, ob jemand schon einmal eine 4.3(a)-Ablehnung überwinden konnte.

    Lösung

    Zum Zeitpunkt des Posts wurde keine Lösung geteilt. Der Entwickler suchte nach Ratschlägen von anderen, die bereits eine 4.3(a)-Ablehnung erlebt hatten.

    Lektion

    Eine lange Wartezeit ist kein Zeichen dafür, dass die App sicher ist. Bei so langsamen Review-Queues kostet eine 4.3(a)-Ablehnung nach Wochen einen ganzen Monat. Bevor du eine neue App einreichst, sei ehrlich darüber, was sie von den Apps in ihrer Kategorie unterscheidet, und formuliere das klar in den Review-Notes und den Metadaten.

98. 

    Richtlinie 4.3(a) Design, Spam macOS Richtlinie 4.3

    Die iPhone-App war bereits live, dann wurde ihre Mac-Version als Spam abgelehnt

    Was passiert ist

    Ein Entwickler hatte eine iPhone-App bereits im App Store veröffentlicht und baute eine native Desktop-Version derselben App für den Mac. Die App-Prüfung lehnte die Mac-App gemäß Richtlinie 4.3(a) ab. Die Nachricht besagte, die App teile ein ähnliches Binary, Metadaten oder Konzept mit Apps anderer Entwickler, mit nur geringfügigen Unterschieden, und empfahl die Einreichung einer einzigartigen App mit eigenständigem Inhalt und Funktionalität. Der Entwickler fragte die Community, was anderen bei 4.3 geholfen hatte.

    Lösung

    Zum Zeitpunkt der Veröffentlichung wurde keine Lösung geteilt.

    Lektion

    Jede Plattform erhält ihre eigene Prüfung, und eine genehmigte iPhone-App wird nicht auf den Mac übertragen. Eine 4.3(a)-Nachricht vergleicht deine App mit Apps anderer Entwickler. Erkläre bei deiner Antwort daher konkret, was deine App leistet, was ähnliche Apps nicht können, und weise auf die Funktionen hin, die nur in deiner App existieren.

99. 

    Endlose Reviews iOS Endlose Reviews

    Mehr als vierzehn Tage in der Prüfung endeten in einer Ablehnung, und die erneute Einreichung wartete weitere zwei Wochen

    Was passiert ist

    Ein Entwickler berichtete, dass seine vorherige Prüfung mehr als vierzehn Tage dauerte und in einer Ablehnung endete. Er reichte die App am 21. Oktober erneut ein, und fast zwei Wochen später war die Einreichung immer noch im Status „Warten auf Prüfung“, obwohl Apple angibt, dass die meisten Prüfungen 24 bis 48 Stunden dauern.

    Lösung

    Zum Zeitpunkt des Beitrags noch im Status „Warten auf Prüfung“.

    Lektion

    Durchschnittliche Review-Zeiten sagen nichts über den Worst Case aus, und eine Ablehnung schickt dich ans Ende einer langsamen Warteschlange. Plane für Launches mehrere Wochen Puffer ein und mache die erste Einreichung so vollständig wie möglich, damit eine Ablehnung die Wartezeit nicht verdoppelt.

100. 

     Kontolöschungsanforderung (Richtlinie 5.1.1(v)) iOS Richtlinie 5.1.1

     Abgelehnt wegen fehlender Kontolöschung, nachdem der erste Prüfer bereits mehrere Konten gelöscht hatte

     Was passiert ist

     Eine App, die auf öffentlichem, von Nutzern generierten Content basiert, wurde bei der zweiten Prüfung wegen fehlender Kontolöschung abgelehnt. Die Logs zeigten, dass der Reviewer während der ersten Prüfung problemlos mehrere Konten erstellt und gelöscht hatte. Der Entwickler hatte das Gefühl, die Ablehnung hing mehr mit der strengen Kategorie zusammen als mit der tatsächlich fehlenden Funktion.

     Lösung

     Zum Zeitpunkt der Veröffentlichung wurde keine Lösung geteilt.

     Lektion

     Selbst wenn eine Funktion funktioniert, muss der Reviewer sie schnell finden. Beschreibe den Pfad zur Kontolöschung in den Review-Notizen mit den exakten Screens, die getippt werden müssen, und füge eine kurze Aufnahme bei. Zeige bei Apps mit User Generated Content auch Reporting, Blocking und Moderation, da diese Kategorien besonders genau geprüft werden.

101. 

     Richtlinie 2.1(a) Vollständigkeit der App macOS Richtlinie 2.1

     Eine Mac-App, die wegen des Lesens des Login-Keychains unter 2.1(a) abgelehnt wurde, und die alten Ablehnungsnotizen verschwanden

     Was passiert ist

     Ein Entwickler hat eine Mac-App eingereicht, die App Review wies sie gemäß Richtlinie 2.1(a) ab, weil die App aus dem Login-Keychain las. Die Behebung erforderte nur ein einziges Update. Was den Entwickler überraschte, war App Store Connect selbst: Es zeigt nur die letzten zehn Einreichungen an, sodass ältere Ablehnungsnachrichten stillschweigend aus dem Verlauf verschwinden.

     Lösung

     In einem Update behoben. Der Entwickler kopiert nun jede Ablehnungsnachricht in den Commit, der das Problem behebt.

     Lektion

     Verlasse dich nicht auf App Store Connect als Aufzeichnung vergangener Ablehnungen, da ältere Einreichungen aus der Ansicht verschwinden. Speichere den vollständigen Ablehnungstext neben der Behebung, im Commit, im Ticket oder in deinen Release Notes, damit du die genaue Formulierung noch hast, falls das gleiche Problem wieder auftritt.

102. 

     Richtlinie 1.4.1 Körperliche Schädigung (Gesundheit und Medizin) iOS Endlose Reviews

     Zehn Tage in der Prüfung für eine Gesundheits-App, dann eine Ablehnung nach 1.4.1, die mit einer Quellen-Seite an einem Nachmittag behoben wurde

     Was passiert ist

     Ein Indie-Entwickler, der eine Gesundheits-App baute, wartete über zehn Tage auf die App Store-Prüfung. Das Ergebnis: Ablehnung nach Richtlinie 1.4.1, die Gesundheits- und Medizin-Apps betrifft. Die Lösung war klein: Der Entwickler fügte eine Quellen-Seite hinzu, die angibt, woher die Gesundheitsinformationen in der App stammen. Das Build dauerte nur einen Nachmittag.

     Lösung

     Eine Quellen-Seite mit Zitaten hinzugefügt, was einen Nachmittag dauerte. Ob die erneute Einreichung genehmigt wurde, wurde im Beitrag nicht mitgeteilt.

     Lektion

     An Gesundheits-Apps werden höhere Anforderungen gestellt, und eine lange Wartezeit kann mit einer Anforderung enden, die man vor der Einreichung hätte erfüllen können. Wenn deine App Gesundheits- oder Medizininformationen anzeigt, füge vor der ersten Einreichung klare Zitate in der App hinzu. Ein Entwickler, der antwortete, merkte an, dass ein sichtbarer Hinweis, ärztlichen Rat einzuholen, eine weitere häufige Anforderung ist.

103. 

     In-App-Kauf für den Prüfer schwer erreichbar (Richtliniennummer nicht angegeben) iOS Metadaten und IAP

     Ein Game-Update wurde abgelehnt, weil der Paywall zu tief lag, und nach 26 Stunden genehmigt, nachdem der Unlock auf den Titelscreen verlegt wurde.

     Was passiert ist

     Ein Indie-Entwickler brauchte 33 Tage und zwei Ablehnungen, um Version 1.0 seines iOS-Spiels freizuschalten. Auch das erste Update, 1.0.1, wurde abgelehnt, weil der Paywall zu tief im Spiel versteckt war, als dass der Reviewer ihn hätte erreichen können. Der Entwickler fügte einen Unlock-Button auf den Titelscreen hinzu und reichte das Spiel erneut ein. Diesmal dauerte der gesamte Prozess etwa 26 Stunden, wobei nur rund 12 Minuten tatsächlich in der Prüfung verbracht wurden.

     Lösung

     Fügte einen Unlock-Button auf den Titelscreen hinzu. Das Update wurde etwa 26 Stunden nach der erneuten Einreichung freigegeben.

     Lektion

     Ein Reviewer wird nicht zwanzig Minuten in deinem Spiel verbringen, um herauszufinden, was du verkaufst. Platziere jeden Kauf so, dass er in Sekunden erreichbar ist, oder beschreibe den genauen Pfad in den Review-Notizen, damit der Reviewer ihn ohne Suchen testen kann.

104. 

     Unstimmige Metadaten für In-App-Käufe (Richtliniennummer nicht angegeben) iOS Metadaten und IAP

     Abgelehnt, weil der Paywall 1 Monat kostenlos anbot, während Apple die jährliche Gebühr anzeigte

     Was passiert ist

     Ein Entwickler wechselte von wochenlangen TestFlight-Zyklen zu einem öffentlichen App Store-Launch und hatte eine abgelehnte Build wegen des Paywalls. Der Paywall bewarb 1 Monat kostenlos, aber der Apple-Kaufbildschirm zeigte die jährliche Gebühr ab demselben Tag an. Der Reviewer konnte auch den wöchentlichen Plan nicht finden. Der Entwickler korrigierte die Paywall-Texte und die Plan-Sichtbarkeit, reichte eine weitere Build ein und wartete erneut auf die Prüfung.

     Lösung

     Der Paywall wurde so angepasst, dass die Formulierung des kostenlosen Testzeitraums mit dem Kaufbildschirm übereinstimmte und der wöchentliche Plan erreichbar war. Die App ging später im App Store live.

     Lektion

     Was dein Paywall verspricht, muss mit dem übereinstimmen, was der Apple-Kaufbildschirm anzeigt, einschließlich Testzeitraum und Rechnungsbeginn. Platziere jeden Plan, den der Reviewer testen muss, so, dass er ihn mit wenigen Taps erreichen kann, und prüfe diesen Pfad vor dem Einreichen auf einer frischen Installation.

105. 

     Guideline 2.1 App Completeness (Crash beim Start) iOS Richtlinie 2.1

     Eine erneute Einreichung mit zusätzlichen Performance-Fixes crashte beim Start und kostete einen vollen Tag

     Was passiert ist

     Nach einer ersten Ablehnung im App Store, die lediglich um weitere Informationen bat, entschied sich der Entwickler, Performance-Fixes in dieselbe erneute Einreichung zu bündeln. Er war so zuversichtlich, dass er sogar einen Hardware-Gate für Gaming-Tier-Geräte entfernte. Die App Review lehnte den Build erneut ab, da er beim Start abstürzte – ohne Crash-Log, nur mit einer automatisierten Nachricht. Der Entwickler ging von einem Memory-Kill aus, stellte den Gate wieder her und verbrachte den Tag damit, Assets zu verkleinern, Loads zu verschieben und Ressourcen freizugeben, ohne an Performance zu verlieren.

     Lösung

     Der Hardware-Gate wurde wiederhergestellt, der Memory-Footprint reduziert und eine dritte Einreichung für den nächsten Tag vorbereitet. Das Endergebnis nach Runde drei wurde im Post nicht geteilt.

     Lektion

     Häufen Sie keine unverwandten Fixes in eine erneute Einreichung, die nur auf eine Review-Frage antworten soll. Shippen Sie die kleinste Änderung, die die Ablehnung beantwortet, halten Sie Stabilitäts-Gates für das niedrigste unterstützte Gerät bei und testen Sie den Cold Start auf diesem Gerät, bevor Sie erneut uploaden.

106. 

     Richtlinie 4.3(a) Design-Spam iOS Richtlinie 4.3

     Mehrere kleine Spiele, die gemeinsam eingereicht wurden, stießen alle auf 4.3(a); zwei Berufungen wurden später aufgehoben

     Was passiert ist

     Eine:n Entwickler:in hat mehrere kleine Spiele gleichzeitig beim App Store eingereicht. Alle wurden wegen Spam gemäß Richtlinie 4.3(a) abgelehnt. Danach wurde der Prozess geändert: Jetzt wird nur noch ein Spiel zur gleichen Zeit eingereicht. Zwei dieser Ablehnungen wurden nach einer Beschwerde beim App Review Board aufgehoben.

     Lösung

     Umgestellt auf Einzel-Einreichungen. Zwei der Ablehnungen nach 4.3(a) wurden nach Beschwerde beim App Review Board aufgehoben.

     Lektion

     Ähnliche Apps im selben Review-Fenster einzureichen, lockt eine Spam-Bewertung für die gesamte Gruppe an. Einreichen Sie nacheinander, und wenn eine Ablehnung nach 4.3(a) ungerechtfertigt erscheint, legen Sie beim App Review Board Beschwerde ein und begründen Sie klar, worin sich jede App unterscheidet.

107. 

     Richtlinie 1.1 Sicherheit, anstößige Inhalte (App-Metadaten) iOS Anstößige Inhalte Metadaten und IAP

     Eine Recovery-App wurde wegen 1.1 abgelehnt, weil das Marketing den Namen der Gewohnheit nannte, die sie abstellen hilft

     Was passiert ist

     Eine App, die Menschen dabei helfen sollte, Pornografie und Lust zu überwinden, wurde wegen Richtlinie 1.1 abgelehnt. App Review gab an, dass das App-Marketing in den Metadaten – einschließlich Beschreibung, Screenshots und Keywords – auf anstößige Inhalte verwies. Als der Entwickler nach Details fragte, nannte App Review ein einzelnes Keyword (porn), erklärte, dass diese Liste nicht abschließend sei, warnte vor einer vollständigen Prüfung bei erneuter Einreichung und stellte klar, dass eine erneute Einreichung mit demselben Marketing oder als neue App mit demselben Konzept zu denselben oder weiteren Verstößen führen würde. Der Entwickler wies darauf hin, dass ähnliche Apps im Store bereits offen Hilfe bei sexueller Versuchung bewarben.

     Lösung

     Zum Zeitpunkt des Posts nicht gelöst. App Review forderte die Entfernung aller Verweise auf anstößige Inhalte aus den Metadaten vor einer vollständigen erneuten Prüfung. Der Entwickler fragte öffentlich, warum ähnliche Apps anders behandelt würden.

     Lektion

     Apps, die Menschen helfen, etwas Erwachsenenbezogenes aufzugeben, werden anhand der Wörter in ihrem eigenen Marketing beurteilt, nicht anhand ihrer Absicht. Beschreibe das Ziel, z. B. Recovery oder Selbstkontrolle, statt die Laster in Keywords, Beschreibung und Screenshots zu benennen. Frage App Review vor der erneuten Einreichung, welche genauen Begriffe die Ablehnung ausgelöst haben, da die nächste Einreichung einer vollständigen Prüfung unterzogen wird.

108. 

     App-Icon als anstößig markiert (Richtlinie nicht angegeben) iOS Anstößige Inhalte Metadaten und IAP

     Ein bereits genehmigtes App-Icon wurde abgelehnt, weil es zu viel Haut zeigte

     Was passiert ist

     Eine KI-App verwendete eine illustrierte Figur als App-Icon, die ein Crop Top trug, bei dem Brust und Bauch sichtbar waren. Dasselbe Icon hatte die App Review zuvor bestanden. Bei einer späteren Einreichung lehnte Apple es ab, weil Brust und Bauch zu offen waren. Die Entwickler zeichneten die Figur mit einem Oberteil neu, das beide Bereiche bedeckte, und reichten sie erneut ein.

     Lösung

     Das Icon wurde so neu gezeichnet, dass das Oberteil Brust und Bauch bedeckte. Der Beitrag gab nicht an, wie lange die neue Prüfung dauerte.

     Lektion

     Eine frühere Genehmigung sichert dein Icon oder deine Screenshots nicht, da jede Einreichung erneut bewertet werden kann. Wenn eine Figur in deiner Grafik Haut zeigt, gehe davon aus, dass ein strengerer Prüfer sie markieren könnte, und halte eine bedecktere Variante bereit, damit die Korrektur ein Austausch und kein Redesign ist.

109. 

     Abonnement-Stornierungs-Flow (Richtliniennummer nicht angegeben) iOS Metadaten und IAP

     Abgelehnt wegen eines zusätzlichen „Sind Sie sicher?“-Schritts bei der Stornierung, eine Woche bevor Apple Retention-Messaging einführte

     Was passiert ist

     Eine Abonnement-App zeigte beim Stornieren ein eigenes „Sind Sie sicher?“-Screen an. App Review lehnte die App dafür ab. Weniger als eine Woche später kündigte App Store Connect Retention-Messaging an, mit dem Entwickler Abonnenten beim Stornieren eine Nachricht mit optionalem Bild oder Retention-Angebot anzeigen können.

     Lösung

     Der Beitrag erwähnte nicht, wie die Ablehnung behoben wurde. Die neue App Store Connect-Funktion bietet nun einen von Apple genehmigten Weg, beim Stornieren eine Nachricht anzuzeigen.

     Lektion

     Legen Sie keine eigenen Hürden vor die Abonnement-Stornierung. Lassen Sie Nutzer direkt in den Stornierungs-Flow gelangen und nutzen Sie für eine letzte Chance, sie zu halten, Apples Retention-Messaging und -Angebote statt eines eigenen Screens.

110. 

     Guidelines 5.6 Developer Code of Conduct und 2.5.19 Hidden Features iOS Richtlinie 5.6 Developer Code of Conduct Guideline 2.5.19 Versteckte Funktionen

     Abgelehnt nach 5.6 wegen versteckter Funktionen, die sich als Checkout code in einem Abo-SDK herausstellten

     Was passiert ist

     Ein Solo-Entwickler hatte seine iOS-Zielverfolgungs-App sieben Mal abgelehnt bekommen, bevor sie live ging. Eine frühere Ablehnung betraf echte Geldwetten. Die letzte kam unter der Entwickler Code of Conduct: Die App-Prüfung sagte, die App habe versteckte oder irreführende Funktionen, und forderte die Entfernung aller versteckten Features, ohne zu sagen, welches. Die App hatte keine Remote-Feature-Flags, kein heruntergeladenes code und kein Sonderverhalten für Prüfer. Statt zu raten, scannte der Entwickler sein eigenes Release-Binary und fand Web-Checkout code von einem Zahlungsanbieter, den er nie geschrieben hatte. Es war in seinem Abo-SDK für diese SDK Web-Plattform gebündelt, und die iOS-App nutzte es nie. Angesichts der früheren Ablehnung wegen Geldwetten vermutete der Entwickler, dass es wie ein versteckter Zahlungsweg aussah.

     Lösung

     Ohne code zu ändern, antwortete der Entwickler auf App Review mit nüchternen Fakten: was die App kann und was nicht, dass es keine echten Geldbeträge betrifft, woher der Checkout-code stammt, dass der ungenutzte SDK Web-code und eine ungenutzte Foto-Bibliothek-Berechtigung im nächsten Build entfernt werden, sowie die Bitte, den beanstandeten Screen zu benennen. Etwa neun Stunden später teilte App Review mit, dass die Prüfung fortgesetzt wird, und die App ging live.

     Lektion

     Wissen Sie, was Ihr Binary mitbringt, einschließlich code, die Ihre SDKs für andere Plattformen einbinden, denn App Review bewertet, was im Build steckt, nicht wie Sie es bezeichnen. Nach einer Ablehnung wegen 5.6 nicht raten und neu einreichen. Antworten Sie ruhig mit konkreten Details und fragen Sie, welcher Screen oder welches Verhalten beanstandet wurde.

111. 

     Richtlinie 2.3.4: Korrekte Metadaten (App-Vorschauen) iOS Metadaten und IAP

     Eine App-Vorschau, die im Oktober die Prüfung bestand, wurde einen Monat später wegen ihrer Rahmung unter 2.3.4 abgelehnt

     Was passiert ist

     Ein Entwickler reichte ein Update für seine iOS-App ein, das unter Richtlinie 2.3.4 abgelehnt wurde. App Review gab an, dass das App-Preview-Video eine Rahmung um die Bildschirmaufnahme hatte. Dasselbe Video hatte den Monat zuvor die Prüfung bestanden. Der Entwickler wies darauf hin, dass andere Apps im Store, darunter eine bekannte, deren Vorschau eine Person statt der App zeigt, App-Vorschauen mit wenig oder gar keinem Material der App selbst verwenden.

     Lösung

     Die Entwickler:in hat das App-Preview-Video komplett entfernt und das Update erneut eingereicht. Der Beitrag sagt nicht, wie die neue Prüfung ausgegangen ist.

     Lektion

     Ein App-Preview, das einmal bestanden hat, kann bei einem späteren Update trotzdem abgelehnt werden, da jede Einreichung erneut geprüft wird. Halte Previews auf einfache Screen-Captures der App ohne dekorative Rahmen beschränkt. Falls eines markiert wird, ist das Entfernen der schnellste Weg, das Update freizuschalten, während du es überarbeitest.

112. 

     Abschnitt 3.2(f) (Developer Program License Agreement) macOS Account-Kündigung Endlose Reviews

     Ein macOS-Update, das ein Icon-Problem behob, lag etwa 45 Tage in der Prüfung, bevor eine 3.2(f)-Meldung eintraf

     Was passiert ist

     Eine unabhängige Entwickler:in hatte eine macOS-App, die App Review wegen Branding-Bedenken markiert hatte. Am 15. September 2026 reichte sie ein Update ein, das das Feedback adressierte, einschließlich eines komplett neu gestalteten App-Icons. Das Update blieb dann etwa 45 Tage ohne Entscheidung in der Prüfung, und die Entwickler:in sandte zwei Express-Prüfanfragen über die offiziellen Kanäle. Am 30. Oktober 2026, während das korrigierte Update noch wartete, traf eine Meldung über die bevorstehende Kündigung des Entwicklerkontos gemäß Abschnitt 3.2(f) ein.

     Lösung

     Einspruch zum Zeitpunkt der Veröffentlichung noch ausstehend. Die Entwicklerin hat einen formellen Einspruch eingelegt und den Developer Support separat kontaktiert, ohne eine inhaltliche Antwort erhalten zu haben.

     Lektion

     Ein Fix, der in der Warteschlange steht, pausiert die Durchsetzung bei älteren Einreichungen nicht. Führe ein datiertes Protokoll über jede Ablehnung, jede daraufhin vorgenommene Änderung und jeden Expedite-Antrag, damit die Berufung genau zeigen kann, was und wann korrigiert wurde.

Diese Seite ist keine Rechtsberatung und sagt nicht voraus, wie Apple bei deiner nächsten Einreichung vorgehen wird.