App Store Rejection: die häufigsten Gründe 2026 und die Lösung für jeden

Die meisten Ablehnungen im App Store haben mit unvollständigen oder fehlerhaften Einreichungen zu tun, nicht mit Regeln zu Inhalten. Laut Apples Seite zu App Review betreffen im Schnitt über 40 % der ungelösten Probleme Guideline 2.1, App Completeness, also Abstürze, Platzhalter und fehlende Angaben. Im Transparenzbericht 2025 taucht der Abschnitt Performance, zu dem 2.1 gehört, in 1.354.418 Ablehnungen auf. Das ist mehr als bei den anderen vier Abschnitten zusammen.

Nach der Vollständigkeit verteilen sich die übrigen Gründe auf vier Gruppen. Legal umfasst Datenschutzerklärungen, Berechtigungsabfragen, Kontolöschung und geistiges Eigentum. Design umfasst Spam, Nachahmer und Apps mit zu wenig Funktionen. Business regelt In App Käufe und Abos. Safety betrifft anstößige Inhalte und Inhalte, die Nutzer selbst hochladen. Jede Gruppe entspricht einem nummerierten Abschnitt der App Review Guidelines, und jede Ablehnung nennt die Richtlinie, auf die sie sich stützt.

Diese Seite folgt deshalb den Nummern der Richtlinien, denn genau die siehst du in der Nachricht von Apple: „Guideline 2.1 Performance: App Completeness“, „Guideline 4.3(a) Design: Spam“, „Guideline 5.1.1(v) Data Collection and Storage“. Zu jeder Nummer bekommst du Apples Wortlaut, die üblichen Ursachen und eine Lösung. Apple hat die Richtlinien zuletzt am 16. Oktober 2026 geändert. Alles hier haben wir am 4. November 2026 mit den App Review Guidelines und Apples Hilfeseiten abgeglichen. Es gibt auch eine deutsche Übersetzung der Richtlinien. Sie trägt aber den Stand vom 8. Juni 2026, die Änderungen vom 16. Oktober fehlen ihr noch, darunter die neuen Regeln 2.3.14 und 2.5.19 und die Ergänzungen in 1.2. Wo diese Seite neuere Regeln wiedergibt, haben wir den englischen Text deshalb selbst übersetzt.

Eine Ablehnung ist selten das Ende. 2025 hat Apple 387.087 Einreichungen nach einer vorherigen Ablehnung doch noch freigegeben, und die meisten übrigen wurden korrigiert und in einer neuen Prüfung eingereicht. Ob du einen Tag verlierst oder zwei Wochen, hängt meist davon ab, wie du reagierst. Darum geht es in der zweiten Hälfte dieser Seite: die Nachricht lesen, antworten, neu einreichen, eine Bug Fix Submission nutzen und beim App Review Board Einspruch einlegen.

„Unable to Add for Review“ ist keine Ablehnung. App Store Connect zeigt die Meldung, wenn du auf Add for Review klickst und der Einreichung noch etwas fehlt. Die Version kommt dann gar nicht erst bei App Review an. Unter dem Titel steht „The items below are required to start the review process:“ und darunter eine Zeile pro fehlendem Punkt. Apples Hilfeseite zum Einreichen einer App beschreibt den normalen Ablauf: Build prüfen, auf Add for Review klicken, die Version zu einer Draft Submission hinzufügen und dann Submit for Review wählen. Sobald die Prüfung beginnt, wechselt der Status auf In Review. Ältere Beiträge in Apples Forum zeigen dieselbe Prüfung unter dem Titel Unable to Submit for Review.

Was ausgefüllt sein muss, listet Apples Übersicht der Pflichtangaben. Auf Ebene der App sind das Name, Bundle ID, SKU, Primärsprache, primäre Kategorie, Content Rights, Altersfreigabe und dein Status nach dem Digital Services Act. Bei der Version kommen Support URL, Versionsnummer, Copyright, App Review Information und die Einstellungen zur Veröffentlichung dazu, bei einem Update außerdem der Text unter What's New. Unter Preise und Verfügbarkeit brauchst du die Verfügbarkeit und einen Preis, auch Gratis zählt. Unter App Privacy brauchst du die URL deiner Datenschutzerklärung und deine Angaben zu den Datentypen. Apples Übersicht der Versionsangaben ergänzt Screenshots, Beschreibung und Keywords als Pflicht, und jede Version braucht einen Build, den du im Abschnitt Build auswählst.

Meist nennt die Meldung den fehlenden Punkt, und die Tabelle unten zeigt die Lösung für jede Meldung, die Entwickler bisher im Forum gepostet haben. Steht dort nur „This field is required.“ und nichts ist markiert, gehst du die Liste oben von vorn bis hinten durch. In Apples Forum lag es im April 2021 an einem leeren Feld Copyright und im Oktober 2021 an leeren URLs für die App Store Server Notifications. Eine Version zur Prüfung hinzufügen dürfen nur die Rollen Account Holder, Admin und App Manager.

Guideline 2.1 hat zwei Teile. Teil (a) verlangt, dass jede Einreichung eine finale Version ist, mit allen nötigen Metadaten und funktionierenden URLs, und dass Platzhaltertext, leere Websites und andere vorläufige Inhalte vorher entfernt sind. Du sollst die App auf einem Gerät auf Fehler und Stabilität testen und, wenn sie eine Anmeldung hat, die Daten eines Demokontos mitliefern und dein Backend einschalten. Am Ende steht der Satz, der die meisten Ablehnungen erklärt: Apple lehnt unvollständige App Bundles und Binaries ab, die abstürzen oder offensichtliche technische Probleme zeigen. Den vollen Text findest du in den App Review Guidelines, in der deutschen Übersetzung heißt die Regel „Vollständigkeit der App“.

Die Ursachen sind meist banal. Ein Absturz auf einem Gerät oder einer iOS Version, die du nicht getestet hast. Eine Anmeldung, die scheitert, weil das Demokonto abgelaufen ist oder einen Einmalcode braucht, den niemand notiert hat. Ein Server, der gerade nicht lief, als der Prüfer die App geöffnet hat. Ein Supportlink auf eine Seite, die es nicht mehr gibt. Eine Funktion mit dem Hinweis „coming soon“. Mit der Frage, ob Apple die App mag, hat keine davon zu tun.

Teil (b) betrifft In App Käufe. Sie müssen vollständig, aktuell, für den Prüfer sichtbar und funktionsfähig sein. Lässt sich ein eingerichtetes Produkt in der App nicht finden oder prüfen, erklärst du den Grund in den Hinweisen für die Prüfung. Eine häufige Variante dieser Ablehnung entsteht beim ersten Kauf. Laut Apples Hilfe zum Einreichen von In App Käufen muss der erste Kauf jedes Typs, also verbrauchbar, nicht verbrauchbar, Abo mit automatischer Verlängerung und Abo ohne Verlängerung, zusammen mit einer neuen Version der App eingereicht werden. Ist der erste eines Typs freigegeben, kannst du weitere Produkte dieses Typs ohne neue Version einreichen, solange die App mindestens eine freigegebene Version hat.

Die Lösung ist eine vollständige Einreichung. Apples Seite zu den Angaben für eine vollständige Prüfung verlangt bei einer neuen App das Konzept und das Geschäftsmodell, bei einem Update, was sich geändert hat und wo der Prüfer es findet. Dazu kommen die Geräte und Systemversionen, auf denen du getestet hast, die externen Dienste, auf die die App angewiesen ist, etwa Datenanbieter, Zahlungsdienste oder KI Dienste, ein Demokonto, das zu Beginn der Prüfung noch funktioniert, Zugangsdaten für jede Art von Konto, ein Konto mit abgelaufenem Abo, damit der Prüfer den ganzen Kaufablauf sieht, und jeder Einmalcode im Feld Notes. Kannst du aus rechtlichen oder Sicherheitsgründen kein Konto weitergeben, erlaubt Guideline 2.1(a) nach vorheriger Zustimmung von Apple einen eingebauten Demomodus.

„Guideline 2.1 Information Needed“ ist noch keine richtige Ablehnung. Der Prüfer kommt ohne etwas von dir nicht weiter: eine funktionierende Anmeldung, die Erklärung einer Funktion, ein Dokument, ein Video der App im Zusammenspiel mit ihrer Hardware oder eine Antwort darauf, woher Inhalte stammen. Die Prüfung ruht, bis du antwortest.

Antworte auf die Nachricht in App Store Connect und reiche nicht neu ein. Laut Apples Hilfe zum Prüfstatus kannst du direkt antworten, wenn App Review mehr Informationen angefordert hat und sonst nichts offen ist. Eine neue Einreichung startet dagegen eine neue Prüfung, und danach kann App Review auf deine frühere Nachricht nicht mehr antworten. Beantworte genau das, was gefragt wurde, häng Screenshots oder eine kurze Bildschirmaufnahme an, wenn es dadurch klarer wird, und aktualisiere die Felder unter App Review Information, damit der nächste Prüfer dieselben Angaben sieht.

Braucht die Anmeldung einen Code, den der Prüfer nicht hat, kann ein Telefonat nötig werden, und das dauert laut Apples Seite zur vollständigen Prüfung meist drei bis fünf Werktage. Steht der Code oder ein Demokonto ohne Code schon vorher im Feld Notes, fällt diese Wartezeit ganz weg.

Abschnitt 2.3 regelt alles auf der Produktseite. Guideline 2.3.1 verlangt, dass alle neuen Funktionen und Änderungen konkret in den Notes for Review beschrieben werden, allgemeine Beschreibungen werden abgelehnt. Irreführende Werbung für die App, ob im App Store oder anderswo, etwa mit Diensten, die sie nicht bietet, oder mit einem falschen Preis, ist ein Grund, sie zu entfernen. Guideline 2.3.2 verlangt, dass Beschreibung, Screenshots und Previews klar zeigen, welche Inhalte einen zusätzlichen Kauf brauchen. Guideline 2.3.12 verlangt, dass der Text unter What's New wichtige Änderungen nennt. Für einfache Bugfixes, Sicherheitsupdates und Leistungsverbesserungen reicht eine allgemeine Beschreibung. Beispiele für gute Texte findest du in unseren Beispielen für Release Notes.

Zu Screenshots erklärt Apple die Ablehnung am ausführlichsten. Die Hilfeseite zu Guideline 2.3.3 sagt, dass Screenshots die App im Einsatz zeigen sollen und nicht nur Titelgrafik, Anmeldeseite oder Startbildschirm. App Review gibt die Screenshots eines Geräts nur frei, wenn mehr als die Hälfte die App im Einsatz zeigt. Bei drei Screenshots müssen es zwei sein, bei vier drei. Overlays mit Text und Bildern sind erlaubt, solange sie die App nicht verdrängen oder ihre Hauptfunktion verdecken, und die Screenshots müssen zur aktuellen Oberfläche passen. Welche Größen Apple verlangt, steht in unserem Ratgeber zu den Größen für Screenshots im App Store, Vorbilder zeigen unsere Beispiele für App Store Screenshots.

Guideline 2.3.7 begrenzt den Namen der App auf 30 Zeichen und verbietet, Metadaten mit Markennamen, Namen bekannter Apps, Preisen oder Begriffen ohne Bezug zu füllen. Die Länge prüfst du mit unserem Zeichenzähler für den App Store. Guideline 2.3.8 verlangt, dass Icons, Screenshots und Previews zu einer Altersfreigabe von 4+ passen, auch wenn die App höher eingestuft ist, und reserviert Begriffe wie „For Kids“ für die Kategorie Kids. Guideline 2.3.10 verbietet Namen, Icons oder Bilder anderer mobiler Plattformen in der App und ihren Metadaten. Die neueste Regel, 2.3.14 vom 16. Oktober 2026, legt dieselben Maßstäbe an die neuen Creative Assets an, die im Kopf der Produktseite und in den Suchergebnissen erscheinen: keine irreführenden Verweise auf andere Apps, keine Behauptungen, die sich nicht belegen lassen, und keine konkreten oder reduzierten Preise.

Der Status Metadata Rejected heißt, dass nur die Produktseite nachgebessert werden muss. Apples Liste der Statusangaben sagt: Nachricht lesen, Metadaten so ändern, dass das Problem gelöst ist, und App Review antworten. Einen neuen Build brauchst du nicht, und nach deiner Antwort geht die Prüfung meist schnell weiter.

Guideline 2.5.1 sagt, dass Apps nur öffentliche APIs nutzen dürfen, auf dem aktuellen Betriebssystem laufen müssen und veraltete Frameworks auslaufen lassen sollen. Guideline 2.5.2 verlangt, dass Apps in sich geschlossen sind und keinen Code herunterladen, installieren oder ausführen, der Funktionen hinzufügt oder verändert. Deshalb wird eine App abgelehnt oder entfernt, die nach der Prüfung neue Funktionen von einem Server lädt. Und deshalb behandelt Apple Mini Apps in HTML5, Chatbots und Plugins getrennt unter Guideline 4.7.

Am 16. Oktober 2026 kam Guideline 2.5.19 dazu. Sie verbietet versteckte, ruhende oder nicht dokumentierte Funktionen. Wer sie im Binary versteckt, etwa durch verschleierten Code, riskiert die Entfernung aus dem App Store und die Kündigung des Entwicklerkontos. Laut Apple fasst die Regel eine lange bestehende Vorgabe klarer, die bisher unter 2.3.1 stand. In der deutschen Übersetzung steht sie deshalb noch am Anfang von 2.3.1(a): „Ihre App darf keine versteckten oder nicht dokumentierten Features enthalten.“ Apples Mitteilung zu der Änderung beschreibt das Ziel als „bait and switch“: Apps, die in der Prüfung einen anderen Zweck vortäuschen und erst nach der Freigabe schädliche Fähigkeiten zeigen. Schaltest du per Fernkonfiguration später Funktionen frei, muss jede Funktion, die der Prüfer nach dem Start erreichen kann, schon in der eingereichten Version enthalten und beschrieben sein.

Auch die Vorgaben für den Build gehören zu den Softwareanforderungen, sie greifen aber schon beim Upload und nicht erst in der Prüfung. Seit dem 28. April 2026 müssen Apps, die zu App Store Connect hochgeladen werden, mit dem iOS 26 SDK oder neuer gebaut sein, laut Apples Mitteilung zu den Mindestanforderungen an das SDK, ab April 2027 mit dem iOS 27 SDK. Ein Build, der die aktuellen Anforderungen nicht erfüllt, zeigt den Status Invalid Binary und braucht einen neuen Upload.

Datenschutz ist die zweitgrößte Gruppe von Ablehnungen und die mit den genauesten Regeln. Guideline 5.1.1(i) verlangt von jeder App einen Link zur Datenschutzerklärung, und zwar im Feld dafür in App Store Connect und in der App selbst, an einer leicht auffindbaren Stelle. Die Erklärung muss sagen, welche Daten die App erhebt, wie und wofür. Sie muss bestätigen, dass jeder Dritte, der die Daten erhält, sie gleich gut schützt, und sie muss Aufbewahrung, Löschung und den Widerruf der Einwilligung erklären.

Guideline 5.1.1(ii) verlangt eine Einwilligung, bevor die App Nutzer oder Nutzungsdaten erhebt, auch wenn die Daten als anonym gelten. Bezahlte Funktionen dürfen nicht davon abhängen, dass jemand diesen Zugriff erlaubt. Außerdem müssen die Nutzungsbeschreibungen, also der Satz, den iOS in jeder Berechtigungsabfrage zeigt, den Zweck klar und vollständig beschreiben. Apples Hilfeseite zu Nutzungsbeschreibungen zeigt den Unterschied, auf den es ankommt. „To use location.“ reicht nicht. Klar ist sinngemäß: Die App nutzt deinen Standort, um die empfohlene Route zu deinem Ziel zu berechnen und dich Abbiegung für Abbiegung zu führen. Schreib pro geschützter Ressource einen konkreten Satz, übersetze ihn in jede Sprache, die die App unterstützt, und entferne Code aus SDKs, der eine Berechtigung anfordert, die du gar nicht brauchst. Für die Nutzungsbeschreibungen eines SDK bist laut Apple ebenfalls du verantwortlich.

Guideline 5.1.1(iv) verlangt, dass Apps die Einstellungen zu Berechtigungen respektieren und niemanden zu unnötigem Zugriff drängen oder verleiten. Apples Beispiel ist eine App, die Fotos in einem sozialen Netzwerk teilt, aber vorher Zugriff auf das Mikrofon verlangt. Lehnt jemand den Standort ab, biete an, eine Adresse von Hand einzugeben. Guideline 5.1.2(i) ergänzt, dass du klar offenlegen musst, wo persönliche Daten an Dritte gehen, ausdrücklich auch an KI von Drittanbietern, und dass du vorher eine ausdrückliche Erlaubnis brauchst. Eine App, die Texte oder Fotos ihrer Nutzer an ein externes KI Modell schickt, braucht diese Offenlegung und Einwilligung in der App, nicht nur in der Datenschutzerklärung.

Zwei technische Vorgaben führen schon beim Upload zu Ablehnungen wegen Datenschutz. Seit dem 1. Mai 2024 müssen Apps, die APIs von Apples Liste mit Begründungspflicht nutzen, in einem Datenschutzmanifest einen zugelassenen Grund angeben, laut Apples Mitteilung zum Datenschutz bei Einreichungen. Und wenn du ein SDK aus Apples Liste häufig genutzter SDKs von Drittanbietern neu einbaust, mit 86 Einträgen, darunter Firebase, Alamofire, Flutter, OneSignal und Lottie, musst du eine Version verwenden, die ihr eigenes Datenschutzmanifest mitbringt, und bei einer Binärabhängigkeit eine signierte.

Eine Ablehnung nach Guideline 4.3 gilt als die schwerste, weil es um die Idee geht und nicht um einen Bug. Sie hat zwei Teile. Guideline 4.3(a) sagt, dass du nicht mehrere Bundle IDs für dieselbe App anlegen sollst. Apples Beispiel ist eine eigene Karten App für jede Stadt der Welt statt einer Karte, in der man jede Stadt suchen kann. Der Rat dazu: eine einzige App einreichen und Varianten für Orte, Sportteams oder Universitäten per In App Kauf anbieten.

Guideline 4.3(b) sagt, dass du keine Apps einreichen sollst, die sich von dem, was es schon reichlich gibt, nicht unterscheiden. Sie nennt Kategorien, die im App Store gut besetzt sind, darunter Dating, Taschenlampen, Soundeffekte, Hintergrundbilder, einfache Timer und Wahrsagerei, und sagt, dass Apple neue Apps dort nur annimmt, wenn sie ein spürbar anderes oder besseres Erlebnis bieten. Solche Apps kann Apple künftig auch entfernen, wenn sie nicht aktualisiert werden, sich nicht verbessern oder keine Kunden finden. Trinkspiele, Kamasutra Apps und Apps, die Furzgeräusche oder Rülpser abspielen, nennt die Regel ausdrücklich minderwertig, und wiederholtes Einreichen solcher Apps kann zum Ausschluss aus dem Apple Developer Program führen. Für Apps aus kommerziellen Vorlagen oder Baukästen gilt eine eigene Regel, Guideline 4.2.6: Sie werden abgelehnt, wenn sie nicht direkt vom Anbieter der Inhalte eingereicht werden.

Apple hat beide Teile am 8. Juni 2026 überarbeitet, die Grundlage der Regel klarer gefasst und Beispiele ergänzt. Die von Michael Tsai gesammelten Berichte bringen die Welle an Einreichungen 2025 und 2026 zum Teil mit Apps in Verbindung, die schnell mit KI Werkzeugen gebaut wurden. Vor diesem Hintergrund wird 4.3 heute angewendet.

Was in den Fällen, die Entwickler beschreiben, geholfen hat: die App ändern, nicht die Argumentation. Fast gleiche Apps zu einer zusammenlegen. Bildschirme aus Vorlagen und Archivgrafiken entfernen. Die Funktion einbauen, die den Unterschied macht, und dann in zwei oder drei schlichten Sätzen in den Hinweisen für die Prüfung sagen, was diese App kann, was die naheliegenden Alternativen nicht können. Eine Antwort, die nur betont, wie einzigartig die App ist, ohne dass sich am Build etwas ändert, bewegt bei 4.3 selten etwas. Wurden mehrere deiner Apps unter 4.3(a) abgelehnt, nimm das ernst: Wiederholter Spam kann zum Ausschluss aus dem Apple Developer Program führen. Was an dieser Mitgliedschaft hängt, steht in unserem Überblick zum Apple Developer Program.

Guideline 4.2, auf Deutsch Mindestfunktionalität, beginnt mit einem Satz, der die meisten dieser Ablehnungen erklärt. In Apples deutscher Fassung lautet er: „Ihre App muss Features, Inhalte und eine Benutzeroberfläche umfassen, die sie von einer neu aufbereiteten Website abhebt.“ Weiter heißt es, dass eine App, die nicht besonders nützlich, einzigartig oder wie eine App ist, nicht in den App Store gehört. Guideline 4.2.2 ergänzt, dass Apps, abgesehen von Katalogen, nicht in erster Linie Marketingmaterial, Werbung, Web Clippings, Sammlungen von Inhalten oder eine Linkliste sein sollen. Guideline 4.2.3 verlangt, dass eine App für sich allein funktioniert, ohne eine andere App zu brauchen, und dass sie die Größe zusätzlicher Downloads nennt, bevor sie starten.

Webview Apps sind der klassische Fall. Eine Website in eine native Hülle zu packen, ist erlaubt, aber eine App, die dieselbe Seite ohne jeden Mehrwert zeigt, bekommt meist eine Ablehnung nach 4.2. Dasselbe gilt für Werkzeuge mit einem Bildschirm, die eine Kleinigkeit erledigen, die iOS schon von Haus aus kann, und für Apps, deren Inhalt ein Buch oder ein Spieleguide ist. Die gehören laut Apple in den Apple Books Store.

Die Lösung: Gib dem Prüfer einen Grund, warum es die App gibt. Nutze Fähigkeiten des Geräts, die eine Website nicht hat: Nutzung ohne Verbindung, Widgets, Mitteilungen, denen die Leute zustimmen, die Kamera, Apple Pay, Sign in with Apple, Teilen in andere Apps oder Daten, die auf dem Gerät bleiben. Mach die App nach Möglichkeit ohne Anmeldung nutzbar. Und schreib in die Hinweise für die Prüfung, was die App kann, was die Website nicht kann. Diese Vorschläge sind unsere Lesart der Richtlinie und der veröffentlichten Erfahrungen von Entwicklern, keine Liste von Apple.

Guideline 4.1 bittet Entwickler, nicht einfach die neueste beliebte App zu kopieren oder Namen und Oberfläche einer anderen App leicht zu ändern und als eigene auszugeben. Nach 4.1(b) verstößt es gegen den Verhaltenskodex für Entwickler, andere Apps oder Dienste nachzuahmen, und 4.1(c) verbietet, ohne Zustimmung das Icon, die Marke oder den Produktnamen eines anderen Entwicklers in Icon oder Namen der eigenen App zu verwenden. Apples Hilfeseite zu Nachahmern nennt die üblichen Auslöser: kopierte Funktionen oder ein kopierter Look, ein Name oder Icon nah an einer bestehenden App, fremde Marken in Titel, Untertitel oder Keywords, Screenshots, die nicht deine echte App zeigen, und ein veralteter Entwicklername oder eine veraltete Support URL. Die Lösung ist jedes Mal dieselbe: die App klar zu deiner eigenen machen oder eine schriftliche Erlaubnis einholen und anhängen.

Guideline 4.8 gilt für Apps, die eine Anmeldung über Drittanbieter oder soziale Netzwerke nutzen, etwa Google Sign In, Facebook Login, Sign In with LinkedIn oder Log in with X, um das Hauptkonto des Nutzers einzurichten. Solche Apps müssen als gleichwertige Option einen weiteren Anmeldedienst anbieten, der die Datenerhebung auf Name und Mailadresse beschränkt, es erlaubt, die Mailadresse privat zu halten, und ohne Einwilligung keine Interaktionen für Werbung sammelt. Sign in with Apple erfüllt alle drei Punkte, deshalb bauen die meisten Entwickler es ein, wenn diese Ablehnung kommt. Die Richtlinie beschreibt aber die Eigenschaften und nennt keinen bestimmten Dienst.

Die Pflicht greift nur, wenn eine Anmeldung über Drittanbieter oder soziale Netzwerke das Hauptkonto einrichtet. Eine App, die ausschließlich ihre eigene Anmeldung mit E-Mail und Passwort nutzt, fällt nicht darunter. Ausnahmen nennt die Richtlinie auch für Apps für Bildung und Unternehmen mit bestehendem Konto der Schule oder Firma und für Apps, die Nutzer über ein staatliches oder von der Branche getragenes Identitätssystem oder eine elektronische ID anmelden. Bietet deine App Sign in with Apple an, denk an die Regel zur Kontolöschung: Wer ein Konto löscht, muss auch die Tokens von Sign in with Apple widerrufen.

Guideline 3.1.1 verlangt In App Käufe, sobald du in der App Funktionen freischaltest, etwa Abos, Spielwährungen, Level, Premiuminhalte oder eine Vollversion. Eigene Mechanismen zum Freischalten wie Lizenzschlüssel, QR Codes oder Krypto Wallets sind nicht erlaubt. Die Regel ist der Kern des Abschnitts Business, der 2025 in 283.820 Ablehnungen genannt wurde.

Abos haben eigene Regeln. Guideline 3.1.2(a) verlangt, dass ein Abo mit automatischer Verlängerung fortlaufend Nutzen bietet, mindestens sieben Tage läuft und auf allen Geräten des Nutzers verfügbar ist. Guideline 3.1.2(c) verlangt, dass du vor der Bitte um ein Abo klar beschreibst, was die Leute für den Preis bekommen, und die Angaben aus Schedule 2 der Entwicklervereinbarung klar vermittelst. Paywalls, die Preis, Laufzeit oder Leistung verstecken, sind eine häufige Ablehnung im Bereich Business.

Es gibt Ausnahmen, die oft übersehen werden. Reader Apps nach 3.1.3(a), etwa für Zeitschriften, Zeitungen, Bücher, Audio, Musik und Video, dürfen Zugriff auf Inhalte geben, die anderswo gekauft wurden. Dienste auf mehreren Plattformen nach 3.1.3(b) dürfen Käufe von anderen Plattformen freischalten, solange dieselben Inhalte auch als In App Kauf angeboten werden. Und laut Guideline 3.1.1(a) brauchen Entwickler im Storefront der USA keine Berechtigung, um Buttons, externe Links oder andere Aufforderungen zum Kauf einzubauen. Für andere Storefronts beschreibt dieselbe Regel Berechtigungen, die Entwickler beantragen können, um auf ein zulässiges Ziel für Käufe zu verlinken.

Die meisten Ablehnungen bei In App Käufen sind handwerklich, nicht grundsätzlich: ein Produkt, das der Prüfer nicht findet, ein Button zum Wiederherstellen von Käufen, der nichts tut, ein Kauf, der in der Sandbox scheitert, oder ein erstes Abo ohne zugehörige Version. Teste vor dem Einreichen jedes Produkt in der Sandbox mit einem frischen Konto und hinterlege für den Prüfer ein Konto mit abgelaufenem Abo.

Ablehnungen wegen Sicherheit waren 2025 die kleinste Gruppe mit 151.159 Nennungen, aber sie sind streng. Guideline 1.2 verlangt von Apps mit Inhalten der Nutzer einen Filter gegen anstößiges Material, eine Möglichkeit, beleidigende Inhalte zu melden, mit zeitnaher Reaktion, die Möglichkeit, missbräuchliche Nutzer zu blockieren, und veröffentlichte Kontaktdaten. Hat deine App Kommentare, Chat, Profile, Uploads oder Rezensionen, müssen alle vier im Build stecken, den der Prüfer sieht. Ausdrücklich genannt werden inzwischen auch soziale Medien, Plattformen für Inhalte der Nutzer und Apps, die Inhalte mit KI erzeugen.

Apple hat 1.2 im Jahr 2026 mehrfach verschärft. Am 6. Februar 2026 stellte Apple klar, dass Apps mit zufälligem oder anonymem Chat unter die Regeln für Inhalte der Nutzer fallen. Im Juni kam ein Absatz zu den Pflichten der Entwickler bei Inhalten dazu, die gegen die Regel verstoßen. Am 16. Oktober 2026 ergänzte Apple, dass die Moderation ausdrücklich auch intime Bilder ohne Einwilligung umfasst, auch solche, die mit KI Werkzeugen erzeugt wurden, und dass Entwickler, die keine Schutzmaßnahmen einbauen oder Verstöße nach einem Hinweis nicht beheben, die Entfernung riskieren. Apps, die mit KI Bilder von Menschen erzeugen oder bearbeiten, sollten Moderation als Voraussetzung für den Start behandeln.

Der Rest des Abschnitts Safety betrifft anstößige Inhalte, Apps für Kinder in der Kategorie Kids, körperliche Schäden und medizinische Aussagen. Apps zur Gesundheit, die diagnostizieren oder behandeln, brauchen eine behördliche Zulassung für jedes Land, in dem sie erhältlich sind. Wenn die App mit medizinischer Hardware arbeitet, verlangt Apple eine Kopie dieser Zulassung. Sie gehört schon vor dem Einreichen in die Hinweise für die Prüfung.

Inzwischen sucht man nach „apple rejected vibe coded apps“, und das Muster gibt es wirklich, auch wenn Apple keine Regel dazu hat, wie eine App geschrieben wird. Apps, die schnell mit KI Werkzeugen entstehen, stoßen oft an dieselben vier Richtlinien. Sie ähneln vielen anderen Apps in einer vollen Kategorie, das ist 4.3(b). Sie verpacken eine einfache Idee oder eine Website, das ist 4.2. Sie kommen mit Platzhaltern, ungetesteten Abläufen oder einem Backend, das nicht läuft, das ist 2.1. Und manchmal schicken sie Daten der Nutzer an ein KI Modell, ohne die Offenlegung und Einwilligung, die 5.1.2(i) verlangt.

Die Menge dahinter ist groß. Die von Michael Tsai gesammelten Berichte zitieren Daten von Appfigures, nach denen die Einreichungen im App Store 2025 bis November um 24 % gestiegen sind, und einen Bericht von The Information, nach dem die Zahl neuer Apps 2025 um rund 30 % gewachsen ist. Apple hat seine Entscheidungen nicht daran geknüpft, wie eine App gebaut wurde, und die neueste Regel, 2.5.19 gegen versteckte oder nicht dokumentierte Funktionen, gilt für jede App gleich.

Wenn du mit KI Werkzeugen baust, betrachte die Einreichung als den Teil, den sie dir nicht abnehmen: auf einem Gerät testen, Inhalte aus Vorlagen entfernen, Datenschutzerklärung und Berechtigungsabfragen schreiben, bei Konten eine Kontolöschung einbauen und die Hinweise für die Prüfung in deinen eigenen Worten verfassen, mit dem, was die App von anderen unterscheidet.

Besteht eine Einreichung die Prüfung nicht, wechselt der Status der Version auf Rejected, oder auf Metadata Rejected, wenn nur die Produktseite das Problem ist, und die Einreichung zeigt Unresolved Issues. Laut Apples Liste der Statusangaben benachrichtigt App Review die Nutzer von App Store Connect mit den Rollen Admin, App Manager oder Developer. Apples Seite zum Kontakt mit App Review sagt, dass die Nachricht in App Store Connect die Probleme beschreibt, die du lösen musst, mit der Richtlinie und meist mit einem Screenshot oder den Schritten.

Viele Entwickler nennen diesen Bereich noch Resolution Center. In Apples aktuellen Hilfeseiten heißt er Bereich App Review in App Store Connect, und der Button für deine Antwort heißt Reply to App Review. Dort antwortet ein Spezialist, der deine App kennt. Apple bittet darum, genau zu sagen, welche Funktion, Richtlinie oder welchen Schritt du erklärt haben willst, und das Feld nicht für Einsprüche oder die Bitte um eine beschleunigte Prüfung zu nutzen. Dafür gibt es eigene Formulare.

Eine Ablehnung betrifft nicht die Version, die schon im App Store ist. Deine Live App bleibt erhältlich, während du die neue korrigierst. Zurückgehalten wird nur die eingereichte Version, zusammen mit In App Käufen oder anderen Elementen derselben Einreichung. Wurden einige Elemente angenommen und andere abgelehnt, rät Apple, die abgelehnten zu entfernen und neu einzureichen, damit die angenommenen weiterkommen.

Wie viel Zeit das kostet, hängt vom Weg ab, den du wählst. Laut Apples Seite zu App Review prüft App Review meist mindestens 50 % der Einreichungen in weniger als 24 Stunden und 90 % in weniger als 48 Stunden. Die Wege stehen in der Tabelle unten, die Wartezeiten in unserem Ratgeber, wie lange die Prüfung im App Store dauert.

Hältst du die App für regelkonform, kannst du beim App Review Board Einspruch einlegen. Laut Apples Hilfeseite zum Einspruch passt ein Einspruch, wenn eine App abgelehnt oder entfernt wurde, du sie aber für vereinbar mit den App Review Guidelines und der Entwicklervereinbarung hältst, wenn deinem Konto die Kündigung droht oder wenn du dich in der Prüfung unfair oder voreingenommen behandelt fühlst. Für eine Statusabfrage oder eine beschleunigte Prüfung ist er nicht gedacht.

Der Ablauf ist festgelegt. Zuerst antwortest du in App Store Connect auf die Ablehnung und klärst das Problem, Einspruch legst du nur ein, wenn das nicht reicht. Dann nutzt du Apples Formular Submit an appeal, nennst die konkreten Anforderungen und erklärst, wie deine App jede davon erfüllt. Das Board meldet sich in App Store Connect, wenn seine Untersuchung abgeschlossen ist, und kann vorher weitere Informationen anfordern oder ein Telefonat vereinbaren. Pro abgelehnter App gibt es einen Einspruch, und darin behandelst du jede genannte Richtlinie. Über das Formular kannst du Einsprüche für bis zu fünf Apps gleichzeitig einreichen. Reichst du die App neu ein, wird der Einspruch geschlossen.

Apple zeigt auch, wie ein guter Einspruch aussieht. Das vollständige Beispiel sagt sinngemäß: Die App wurde unter 2.1 wegen unvollständiger Angaben abgelehnt, Demokonto und Schritte zur Einrichtung stehen unter App Review Information, und Screenshots zeigen die Funktion im Einsatz. Das unvollständige Beispiel sagt nur, die App sei wichtig für das Geschäft und hätte nicht abgelehnt werden sollen. Apple ergänzt, dass ein vollständiger Einspruch dem Board hilft, schnell zu arbeiten, aber nicht garantiert, dass die Entscheidung kippt.

Wie viele Einsprüche gegen Ablehnungen Erfolg haben, veröffentlicht Apple nicht. Der Transparenzbericht 2025 nennt stattdessen Einsprüche gegen die Entfernung von Apps: 26.305 Einsprüche und 423 wiederhergestellte Apps, nach unserer Rechnung rund 1,6 %. Im Vereinigten Königreich hat Apple in seinen Zusagen an die CMA vom 30. März 2026 versprochen, dass Entwickler gegen eine Erstentscheidung als Recht beim App Review Board Einspruch einlegen können, dass jede Ablehnung erklärt, wie die Einreichung gegen die Richtlinien verstößt, und dass Apple jährlich Zahlen für Entwickler aus dem Vereinigten Königreich veröffentlicht: Einsprüche gegen Ablehnungen, nach Einspruch freigegebene Apps und den Anteil der Einsprüche, die innerhalb von 60 Tagen abgeschlossen sind. Der erste Bericht ist bis zum 31. März 2027 fällig.

Wird ein Update zu einer App, die schon im App Store ist, wegen eines Problems ohne rechtliche oder Sicherheitsbedenken abgelehnt, lässt Apple es dich unter Umständen trotzdem veröffentlichen und das Problem beim nächsten Mal beheben. Apples Seite zu Bug Fix Submissions sagt, dass das Angebot oben in der Nachricht erscheint, mit dem Satz „Bug Fix Submissions: The issues we've identified below are eligible to be resolved on your next update.“ Das gilt nur für Updates von Apps, die schon einmal freigegeben wurden.

Zum Annehmen antwortest du auf die Nachricht, sagst, dass du die aktuelle Einreichung freigegeben haben möchtest und die Probleme im nächsten Update löst, und reichst nicht neu ein, denn das startet eine neue Prüfung. App Review bestätigt per Antwort und gibt die Einreichung frei. Im nächsten Update musst du jedes zurückgestellte Problem lösen, App Review prüft das, und ein einmal zurückgestelltes Problem lässt sich nicht noch einmal zurückstellen. Steht der Hinweis nicht in der Nachricht, ist die Einreichung nicht berechtigt, und die Probleme müssen zuerst gelöst werden. Wie du das Update danach ankündigst, zeigen unsere Beispiele für Ankündigungen von Updates.

Google Play prüft nach seinen Developer Program Policies, und die Seite zur Durchsetzung nennt die möglichen Folgen: Ablehnung, Entfernung, Sperrung, eingeschränkte Sichtbarkeit oder Regionen, eingeschränkte Konten und Kündigung. Die Nachricht zur Ablehnung nennt die Richtlinie, und Google schickt per E-Mail eine Anleitung zum Einspruch, wenn du einen Fehler vermutest. Stand der Angaben zu Google Play in diesem Abschnitt: 2. November 2026.

Eine Ablehnung bei Google Play ohne Gegenstück im App Store hängt am Formular Data safety. Laut Googles Hilfe zu Data safety muss jede App auf Google Play es ausfüllen, auch eine, die keine Daten erhebt. Für vollständige und korrekte Angaben sind allein die Entwickler verantwortlich, und auf die Frage, ob eine App wegen ihrer Angaben gesperrt werden kann, antwortet Google mit „In short, yes.“ Falsche Angaben müssen korrigiert werden, und bei Apps, die sich nicht daran halten, kann Google Updates blockieren oder sie entfernen.

Zwei weitere Unterschiede sind für die Planung wichtig. Neue private Entwicklerkonten, die nach dem 13. November 2023 angelegt wurden, müssen einen geschlossenen Test mit mindestens 12 Testern über mindestens 14 Tage durchführen, bevor sie Zugang zur Produktion beantragen, laut Googles Anforderungen an Tests. Und Googles Hilfe zu Entfernung und Einspruch erlaubt einen Einspruch pro Maßnahme, beantwortet auf Chinesisch, Englisch, Japanisch oder Koreanisch. Veröffentlichst du in beiden Stores, halte Datenschutzerklärung, Apples Angaben zum Datenschutz und Googles Formular Data safety auf demselben Stand, denn ein Widerspruch ist auf beiden Seiten die einfachste Art, eine Ablehnung zu kassieren.

Einige derselben Regeln gelten auch dafür, wie du die App bewirbst. Guideline 2.3.1 warnt, dass irreführende Werbung für eine App, im App Store oder außerhalb, etwa mit Funktionen, die sie nicht hat, oder einem falschen Preis, ein Grund für die Entfernung ist. Apples eigene Marketing Richtlinien regeln, wie du das App Store Badge, Geräte von Apple und deine Bewertung in Anzeigen und Posts zeigst.

Unser Überblick zu den App Store Marketing Guidelines erklärt diese Regeln in einfachen Worten, und unsere App Store Statistik verfolgt die jährlichen Zahlen zu Ablehnungen und Entfernungen, sobald Apple sie veröffentlicht. Wie du nach der Freigabe die Produktseite und die Ankündigung zum Start angehst, zeigen die Beispiele für Ankündigungen zum App Launch.

Durch App Review zu kommen, ist der schwere Teil eines Updates. Den Leuten davon zu erzählen, sollte es nicht sein. Spreadcast prüft deinen öffentlichen Eintrag im App Store jeden Tag, sieht jede freigegebene Version, sobald sie live ist, und macht daraus einen gestalteten Post mit deinem eigenen Icon und deinen Screenshots in einem iPhone Rahmen, mit einem Beitragstext für jedes Netzwerk. Es veröffentlicht auf Instagram, Facebook, LinkedIn, Pinterest und deinen anderen verbundenen Konten nach dem Zeitplan, den du festlegst. Die Oberfläche von Spreadcast ist auf Englisch.

Die Posts halten sich an Apples Marketing Regeln: echte Screenshots der aktuellen App, keine erfundenen Funktionen und keine Preise, die sich ändern könnten. Dieselbe tägliche Prüfung macht aus neuen Rezensionen mit 5 Sternen und Meilensteinen bei der Bewertung Posts. Füge deinen App Store Link auf der Einstiegsseite ein, um einen Post aus deinem Eintrag zu sehen, und schau dir die Pläne für das automatische Veröffentlichen an.