App-Review: Ablehnungsgründe

Die App ist fertig, getestet, die Screenshots sind hochgeladen, der Button heißt „Zur Prüfung einreichen“. Und dann kommt, zwei Tage später, eine Mail mit einer Nummer darin: Guideline 2.1, Guideline 5.1.1, oder bei Google ein Hinweis auf eine Richtlinie zu Berechtigungen. Die App ist abgelehnt. Nicht, weil sie schlecht wäre. Sondern weil eine Zeile in der Datenschutzerklärung fehlt, ein Demo-Zugang nicht hinterlegt war oder eine Berechtigung angefordert wird, deren Grund niemand erklärt hat.

Das passiert nicht selten. Apple hat 2025 nach eigenem Transparenzbericht gut 9,1 Millionen Einreichungen geprüft und knapp 2,1 Millionen davon abgelehnt, also ungefähr jede vierte. Die Zahl zählt Einreichungen, nicht Apps, und viele Apps werden mehrfach eingereicht, bis sie durch sind. Google veröffentlicht keine vergleichbaren Zahlen, prüft aber seit 2024 bei neuen Konten und Berechtigungen deutlich strenger. Dieser Beitrag beschreibt, was beide Stores wirklich prüfen, woran Apps in meiner Praxis am häufigsten scheitern, was eine Ablehnung kostet und was Sie als Auftraggeber vor der Einreichung erledigen können. Ich habe in diesem Herbst selbst wieder eine App durch beide Prüfungen gebracht, die Liste ist also frisch.

Für Entscheider: Worum es geht

Eine Ablehnung kostet selten Geld, aber meist einige Tage bis zwei Wochen und einmal die Konzentration des ganzen Teams. Die meisten Gründe sind vorhersehbar und lassen sich vor der ersten Einreichung abarbeiten: ein funktionierender Demo-Zugang, vollständige Datenschutzangaben, Kontolöschung in der App, erklärte Berechtigungen, ein aktuelles Android-Ziel und bei Google ein Konto, das überhaupt veröffentlichen darf. Was Sie als Auftraggeber beitragen, ist überschaubar und steht am Ende des Beitrags.

Wie die Prüfung abläuft

Bei Apple sitzt am Ende ein Mensch. Automatische Prüfungen laufen schon beim Upload, und Apple beschreibt den Prozess selbst als Kombination aus menschlicher Prüfung und maschineller Unterstützung. Aber jede Einreichung landet in App Review. Die meisten Einreichungen werden innerhalb eines Tages geprüft, komplexere oder neue Einreichungen können länger dauern. Der Prüfer installiert die App, meldet sich an, klickt durch die Funktionen, liest die Store-Texte und die Datenschutzangaben und vergleicht das Gesehene mit den App Review Guidelines. Jede Ablehnung nennt die Nummer der Richtlinie und meist einen Screenshot. Man kann antworten, nachbessern, neu einreichen oder Einspruch einlegen.

Bei Google prüfen zuerst Automaten, dann bei Bedarf Menschen. Die Prüfung dauert bei etablierten Konten oft nur Stunden, bei neuen Konten und bei Apps mit sensiblen Berechtigungen Tage. Ablehnungen kommen als Richtlinienverstoß mit Verweis auf die Programmrichtlinien, bei Berechtigungen oft als Aufforderung, ein Erklärungsformular nachzureichen. Und bei Google gibt es eine Hürde vor der eigentlichen Prüfung, die viele überrascht: Bei persönlichen Entwicklerkonten, die nach dem 13. November 2023 angelegt wurden, verlangt Google vor dem Produktionszugang einen geschlossenen Test mit mindestens zwölf Testern, die vierzehn Tage durchgehend angemeldet bleiben. Organisationskonten sind davon ausgenommen, was einer der Gründe ist, warum die App eines Betriebs in einem Organisationskonto liegen sollte und nicht im Privatkonto des Entwicklers.

Die häufigsten Gründe bei Apple

Apple ordnet Ablehnungen den Abschnitten seiner Richtlinien zu. Im Bericht für 2025 entfielen mit Abstand die meisten auf den Abschnitt „Performance“, in dem die Richtlinie 2.1 steht, danach „Legal“ mit den Datenschutzregeln, dann „Design“. Das deckt sich mit dem, was ich sehe:

2.1 App Completeness: Die App ist nicht fertig, oder der Prüfer kommt nicht hinein

Die Richtlinie verlangt eine fertige App mit funktionierenden Links, ohne Platzhaltertexte, und wenn die App einen Login hat, einen Demo-Zugang für den Prüfer, mit eingeschaltetem Backend. Der häufigste Fall in meiner Praxis ist nicht die unfertige App, sondern der Prüfer, der nicht hineinkommt: Der Demo-Zugang fehlt, das Testkonto wurde zwischenzeitlich gesperrt, das Backend läuft auf einer Staging-Umgebung, die nachts heruntergefahren wird, oder die App verlangt eine Firmen-E-Mail, die der Prüfer nicht hat. Apple erlaubt statt eines Demo-Zugangs einen eingebauten Demo-Modus, aber nur mit vorheriger Genehmigung. Zweiter Klassiker: In-App-Käufe sind konfiguriert, aber in der eingereichten Version nicht erreichbar. Dann muss das in den Prüfhinweisen erklärt sein.

5.1.1 Datenschutz: Die Erklärung fehlt, oder das Konto lässt sich nicht löschen

Jede App braucht einen erreichbaren Link zur Datenschutzerklärung, in der App und im Store, und die Datenschutzangaben im Store müssen zu dem passen, was die App tatsächlich tut. Dazu kommt die Regel, an der seit 2022 viele Business-Apps hängen bleiben: Wer in der App ein Konto anlegen lässt, muss in der App auch die Löschung anbieten. Ein Link auf eine Support-Mail reicht nicht. Und eine App darf keine persönlichen Daten verlangen, die für ihre Funktion nicht nötig sind. Die Registrierung mit Telefonnummer, Geburtsdatum und Adresse für eine App, die Arbeitszeiten erfasst, ist ein sicherer Ablehnungsgrund.

5.1.2 Datenweitergabe, seit Ende 2025 ausdrücklich auch an KI

Personenbezogene Daten dürfen ohne Erlaubnis nicht weitergegeben werden, und die Richtlinie nennt seit November 2025 ausdrücklich die Weitergabe an KI-Dienste von Dritten: Sie muss klar offengelegt und vorher ausdrücklich erlaubt werden. Eine App, die Fotos oder Texte an ein externes Modell schickt und das nur in der Datenschutzerklärung erwähnt, läuft in diese Regel.

4.2 Minimum Functionality: Die verpackte Webseite

Eine App, die im Kern eine Webseite in einem Rahmen zeigt, gehört nach Apples Lesart nicht in den Store. Das trifft Betriebe, die aus ihrem Kundenportal schnell eine App machen wollen, und es trifft sie zu Recht, denn die Nutzer merken den Unterschied auch. Nicht die Zahl nativer Funktionen entscheidet, sondern ob die App gegenüber der Webseite einen echten, eigenständigen Nutzen bietet. Push, Kamera, Offline-Daten oder Biometrie können dazu beitragen, sind aber kein Freifahrtschein.

2.3 Metadaten: Screenshots und Texte, die nicht zur App passen

Screenshots aus einer anderen Version, Beschreibungen, die Funktionen versprechen, die es noch nicht gibt, eine Kategorie, die nicht passt. Weniger dramatisch, aber ein ganzer Prüfdurchlauf verloren.

3.1.1 Bezahlung: Freischaltung am Store vorbei

Wer digitale Inhalte oder Funktionen in der App freischaltet, muss grundsätzlich Apples In-App-Kauf benutzen, keine Lizenzschlüssel, keine eigenen Mechanismen. Die Regel hat inzwischen Ausnahmen, die je nach Land und App-Typ verschieden sind: In den USA sind Links zu externen Kaufwegen erlaubt, in der EU gelten eigene Bedingungen, und Unternehmensdienste, die direkt an Organisationen verkauft werden, dürfen außerhalb der App erworbene Inhalte und Abos freischalten. Für Business-Apps ist der letzte Weg der übliche. Er muss aber so gebaut sein, dass die App die Ausnahme auch erfüllt, und genau das ist eine Architekturentscheidung, keine Textkorrektur.

Die technische Vorprüfung: Privacy Manifest

Seit Mai 2024 muss eine hochgeladene Version für bestimmte Systemschnittstellen, die Apple als Required Reason APIs führt, etwa Dateizeitstempel oder Nutzereinstellungen, in einer Manifestdatei einen zugelassenen Grund angeben. Fehlt er, weist der Upload die Version ab, bevor ein Prüfer sie sieht, mit einer Fehlernummer, die ITMS-91053 lautet. Dazu kommen Manifest- und Signaturpflichten für eine Liste häufig genutzter Drittanbieter-SDKs. Der Haken: Die Schnittstellen benutzt oft nicht die App selbst, sondern eine eingebundene Bibliothek, und die muss ihr eigenes Manifest mitbringen. Veraltete Bibliotheken sind hier die häufigste Ursache.

Die häufigsten Gründe bei Google Play

Google prüft weniger die App als Produkt und mehr die Angaben und Berechtigungen. Die Ablehnungen, die ich sehe, verteilen sich auf fünf Themen:

• Datensicherheit. Der Abschnitt „Datensicherheit“ in der Play Console muss ausgefüllt sein und zu dem passen, was die App und ihre Bibliotheken tatsächlich tun. Eine Analytics-Bibliothek, die Geräte-IDs sammelt, während im Formular „keine Daten erhoben“ steht, ist ein Verstoß, auch wenn niemand im Team davon wusste.
• Anmeldedaten für die Prüfung. Wenn Teile der App hinter einem Login liegen, müssen die Zugangsdaten in der Play Console unter „Anmeldedaten“ hinterlegt sein, mit Hinweisen zu Besonderheiten wie Einmalpasswörtern oder zweitem Faktor. Fehlen sie, wird die App abgelehnt, weil der Prüfer nicht sehen kann, was sie tut.
• Berechtigungen ohne zulässigen Grund. Für sensible Berechtigungen verlangt Google ein Erklärungsformular und akzeptiert nur bestimmte Anwendungsfälle. Das bekannteste Beispiel seit 2025: Der breite Zugriff auf Fotos und Videos ist nur noch für Apps erlaubt, deren Kernfunktion einen dauerhaften oder häufigen Zugriff auf Fotos oder Videos wirklich benötigt. Alle anderen müssen den Systemdialog zur Bildauswahl verwenden und die Berechtigung aus der App entfernen. Dasselbe Prinzip gilt für Standort im Hintergrund, SMS, Anrufliste und die Liste der installierten Apps.
• Veraltetes Android-Ziel. Neue Apps und Updates müssen seit dem 31. August 2026 Android 16 als Ziel haben, bestehende Apps mindestens Android 15, sonst werden sie für neue Nutzer auf neueren Geräten unsichtbar. Eine App, die zwei Jahre nicht angefasst wurde, scheitert daran beim nächsten Update, und die Anhebung des Ziels zieht regelmäßig Änderungen an Berechtigungen und Hintergrunddiensten nach sich.
• Das Konto selbst. Der Zwölf-Tester-Test für neue Privatkonten, eine nicht abgeschlossene Identitätsprüfung des Kontoinhabers, eine fehlende D-U-N-S-Nummer beim Organisationskonto. Nichts davon hat mit der App zu tun, alles davon hält sie auf.

Was eine Ablehnung kostet

Geld kostet sie fast nie. Zeit schon: Nachbessern, neu bauen, neu hochladen, neue Prüfung, und bei Apple nach der zweiten Ablehnung zum selben Punkt oft eine längere Wartezeit. Realistisch verschiebt jede Ablehnung die Veröffentlichung um drei bis zehn Tage. Bei einem Einspruch, den man braucht, wenn man die Richtlinie anders liest als der Prüfer, auch um Wochen. Teurer als die Zeit ist, was dranhängt: eine Schulung, die auf die App wartet, ein Messetermin, ein Rollout an fünfzig Mitarbeiter, der verschoben wird. Ganz umgehen lässt sich die Prüfung übrigens auch bei internen Apps selten, wie der Beitrag über Apps außerhalb des App Stores zeigt; einplanen ist der bessere Weg. Und manchmal die Erkenntnis, dass die Ablehnung eine Architekturfrage betrifft, Bezahlung, Berechtigungen, Datenweitergabe, die man nicht in zwei Tagen umbaut.

Deshalb plane ich die Prüfung ein, statt sie als Formalität ans Ende zu hängen: erste Einreichung mindestens zwei Wochen vor dem Termin, an dem die App gebraucht wird, und bei Apps mit sensiblen Berechtigungen oder Bezahlung vier.

Was ich vor jeder Einreichung prüfe

• Demo-Zugang angelegt, getestet, im Store hinterlegt, Backend läuft dauerhaft, Konto läuft nicht ab.
• Prüfhinweise geschrieben: was die App ist, für wen, warum sie welche Berechtigung braucht, was im Testkonto zu sehen ist, was nicht erreichbar ist und warum.
• Datenschutzerklärung erreichbar, in der App und im Store, inhaltlich passend zu Bibliotheken und Diensten.
• Datenschutzangaben bei Apple und Datensicherheit bei Google ausgefüllt, gegen die tatsächlich eingebundenen Bibliotheken abgeglichen.
• Kontolöschung in der App vorhanden, wenn es eine Registrierung gibt.
• Jede Berechtigung hat einen Grund im Text, der dem Nutzer beim Anfordern angezeigt wird, und die sensiblen haben ihr Formular.
• Android-Ziel aktuell, Privacy Manifest vollständig, Bibliotheken auf einem Stand, der beides unterstützt.
• Screenshots aus der eingereichten Version, Beschreibung ohne Versprechen, Kategorie passend.
• Bezahlung: nichts in der App, was Apple als Umgehung lesen könnte, oder sauber über In-App-Kauf.
• Konto: Organisationskonto des Kunden, Identität bestätigt, D-U-N-S vorhanden, Rollen vergeben.

Was Sie als Auftraggeber beitragen

Die meisten Punkte erledigt die Entwicklung. Vier Dinge kann nur der Betrieb liefern, und sie sind regelmäßig das, was eine Einreichung aufhält:

1. Die Store-Konten in Ihrem Namen. Apple Developer Program und Google Play Console als Organisationskonto Ihres Unternehmens, mit D-U-N-S-Nummer und bestätigter Identität. Das dauert bei Neuanlage Tage bis Wochen und gehört an den Anfang des Projekts, nicht ans Ende. Warum das auch jenseits der Prüfung wichtig ist, steht im Beitrag zur App-Übergabe.
2. Die Datenschutzerklärung. Sie muss von Ihnen kommen oder von Ihrer Kanzlei, und sie muss die App, ihre Bibliotheken und ihre Dienste nennen. Ich liefere die Liste, was die App technisch tut. Den Text liefere ich nicht.
3. Ein Demo-Konto mit echten Testdaten, das die Prüfer benutzen dürfen, ohne dass dahinter ein echter Kunde liegt.
4. Die Entscheidung bei den Architekturfragen: Wird in der App etwas verkauft? Werden Daten an externe Dienste, auch KI, geschickt? Braucht die App wirklich den Standort im Hintergrund? Jede dieser Fragen hat eine Antwort, die den Review leicht macht, und eine, die ihn schwer macht. Beide sind legitim. Aber die schwere kostet Zeit, und die muss im Plan stehen.

Häufige Fragen

Fazit: Der Review ist planbar

Die Stores prüfen keine Qualität im Sinne von gutem Design oder stabilem Code, das merken die Nutzer später. Sie prüfen Vollständigkeit, Ehrlichkeit der Angaben und Einhaltung einiger weniger harter Regeln. Genau deshalb ist der Review planbar: Die Gründe wiederholen sich, die Liste oben deckt den Großteil ab, und fast alles davon lässt sich erledigen, bevor der Button gedrückt wird. Und eine Ablehnung ist kein Urteil, sondern eine Schleife: Rund 18,5 Prozent der abgelehnten Einreichungen hat Apple 2025 nach einer vorherigen Ablehnung doch noch freigegeben. Was übrig bleibt, sind die Architekturfragen, und die gehören an den Anfang des Projekts, nicht in die Woche vor dem Rollout.