Ablehnungsgründe im App Store und Google Play: Top 6 und wie du sie vermeidest

Wer prüft die App vor der Veröffentlichung und wie

Stell dir vor, du vermietest eine Wohnung, und vor dem Einzug kommt ein pingeliger Inspektor. Monatelang darin wohnen will er nicht. Fünf Minuten - und er ist durch alle Zimmer gegangen, hat an jeder Klinke gerüttelt, geprüft, ob der Hahn tropft, unter die Spüle geschaut. Eine Kakerlake - und das Protokoll wird nicht unterschrieben.

Das Review Review - die Prüfung der App durch Menschen und Automatik seitens des Stores vor der Veröffentlichung. Sie entscheiden, ob du in den Store darfst oder zur Nachbesserung zurückgeschickt wirst. im App Store und in Google Play funktioniert genauso. Auf der anderen Seite sitzt ein echter Mensch mit Checkliste, der ein paar Minuten für deinen Build hat. Er sucht nicht, wofür er dich loben kann. Er sucht, was er beanstanden kann. Und findet in der Regel immer dasselbe: abgestürzt, halbfertig, Link kaputt, Screenshot lügt, fordert zu viel.

Warum eine einzige Ablehnung dich eine Woche kostet

Jeder Reject bedeutet verlorene Tage. Build abgeschickt. In der Warteschlange gestanden. Ein trockenes „rejected“ kassiert. Die Formulierung der Regel nachgelesen. Repariert. Wieder abgeschickt. Und wieder wartest du. Ein dummes Versäumnis - und da ist sie, die Woche Stillstand aus dem Nichts.

• Du sparst Tage und Nerven: vorab reparieren ist um ein Vielfaches billiger als nach der Ablehnung.
• Du hörst auf, einen Reject als persönliche Kränkung zu sehen - es ist nur ein Punkt auf der Checkliste, den du übersehen hast.
• Du fängst an, wie ein Reviewer zu denken - schon in der Entwicklung, statt dich erst am letzten Tag an die Regeln zu erinnern.
• Vibe Coding liebt es, Halbfertiges zu produzieren: Die KI hat einen hübschen Screen gemalt, aber der Button darunter ist eine Attrappe. Die Stores merken das sofort.

Die meisten Ablehnungen fallen in fünf Schubladen: unvollständige Informationen, kaputte Funktionalität, Datenschutzverstöße, Designprobleme und Regelverstöße. Merk dir diese fünf - und du bist der Reject-Warteschlange schon einen Schritt voraus.

Top 6 Ablehnungsgründe im App Store und Google Play

Gehen wir die häufigsten Fallen durch. Zu jeder: worum es geht und welche Medizin hilft.

1. Crashes und Bugs: Die App stürzt beim Review ab

Todesurteil Nummer eins. Die App stürzt ab oder hat offensichtliche Glitches auf irgendeinem Bildschirm, den der Reviewer geöffnet hat - das war’s, Gespräch beendet. Der Store muss nicht herausfinden, dass bei dir „eigentlich fast alles läuft“. Beim Review abgestürzt - also Ablehnung. Punkt.

Medizin: Geh den kompletten Ablauf von Hand durch, bevor du abschickst - so, als würdest du die App zum ersten Mal sehen. Teste extra den ersten Start, den Login, leere Zustände (wenn noch keine Daten da sind) und das Verhalten bei schlechter Verbindung. Genau da fliegt meistens alles auseinander.

2. Halbfertige Funktionen und Platzhalter im Release

Bildschirme mit der Aufschrift „Kommt bald“, Blindtext Lorem Ipsum Lorem Ipsum - der Standard-Platzhaltertext in Pseudolatein, den man während des Layoutens statt echtem Inhalt einsetzt. In einer fertigen App hat er nichts zu suchen. , Buttons ins Nichts - einer der häufigsten Gründe, einen Neuling abzulehnen. Der Store will ein fertiges Produkt. Kein Demo mit Löchern, kein „fast final“ - fertig.

Medizin: Die Regel ist geradezu peinlich einfach - jeder Button, den du vom ersten Bildschirm aus erreichen kannst, muss etwas Echtes tun. Das Feature gibt’s noch nicht? Entferne den Button, statt eine Attrappe hinzuklatschen. Keine „TODOs“, keine Platzhalter und keine „temporären“ Bildschirme im Release-Build.

3. Tote Links: Eine kaputte URL kostet die Ablehnung

Ein kaputter Link wirkt wie eine Kleinigkeit, kostet aber eine ganze Ablehnung. Am häufigsten stolpert man über den Link zur Datenschutzerklärung: Er führt auf eine leere Seite, auf einen 404 oder fehlt komplett. Der Reviewer kann deine Versprechen zu den Daten nicht prüfen - also lässt er dich nicht durch.

Medizin: Öffne jeden Link von Hand, bevor du abschickst. In der App, im Store-Eintrag, im Support. Alle müssen sich öffnen lassen und dorthin führen, wo angegeben. Kein „localhost“ und keine Entwürfe, die du zu ersetzen vergessen hast.

4. Keine Datenschutzerklärung (Guideline 5.1.1)

Fast jede App braucht heute eine Datenschutzerklärung Datenschutzerklärung (privacy policy) - ein Dokument, das verständlich beschreibt, welche Daten die App erhebt, wie und wozu, und an wen sie weitergegeben werden. Für fast alle Apps in beiden Stores erforderlich. . Verstöße gegen die Datenschutzregeln (bei Apple ist das der Abschnitt Guideline 5.1.1) sind einer der häufigsten Ablehnungsgründe, besonders bei Neulingen.

Was verlangt wird:

5. Irreführende Screenshots im Eintrag

Die Screenshots im Eintrag sind das Schaufenster. Und zeigen müssen sie genau das, was im Build steckt, den du abgeschickt hast. Hübsche Bilder mit Features „aus der Zukunft“, ein fremdes Interface, Bildschirme, die es in der App gar nicht gibt - der direkte Weg zur Ablehnung wegen Täuschung.

Medizin: Mach Screenshots vom aktuellen Build, nicht aus den Mockups des Designers. Kein Photoshop drüber, keine Funktionen, die es noch nicht gibt. Zeig genau das, was ein Mensch sieht, wenn er die App lädt - kein Bild mehr.

6. Die App fordert überflüssige Berechtigungen an

Berechtigungen Berechtigung (permission) - der Zugriff, den eine App vom Nutzer erbittet: Kamera, Mikrofon, Standort, Kontakte, Benachrichtigungen. Jede muss durch das gerechtfertigt sein, was die App tut. wie Standort im Hintergrund, Zugriff auf Kontakte, Kamera oder SMS prüfen die Stores besonders streng. Forderst du einen Zugriff an, der nichts mit dem zu tun hat, was die App tut, ist das ein Warnsignal, und der Build wird abgelehnt.

Medizin: Fordere nur das an, was du gerade wirklich nutzt, und gib zu jeder Berechtigung eine verständliche Erklärung - wozu sie da ist. Du bist dir unsicher, ob ein Feature in diesem Release sein muss? Raus damit - und die Berechtigung gleich mit.

Checkliste vor dem Abschicken der App zum Review

Bevor du auf „Zum Review einreichen“ drückst, geh die Liste durch - laut. Auf jeden Punkt ein ehrliches „Ja“, ohne dir selbst etwas durchgehen zu lassen.

Ich bin die ganze App von Hand durchgegangen, auf einer frischen Installation ohne meine Daten - nichts ist abgestürzt.
Ich habe leere Bildschirme, den Login und das Verhalten bei schlechter Verbindung geprüft - nichts ist kaputtgegangen.
Jeder Button vom ersten Bildschirm aus tut etwas Echtes. Keine Attrappen, kein „Kommt bald“ und kein Blindtext.
Ich habe jeden Link geöffnet - in der App und im Eintrag. Alle funktionieren und führen dorthin, wo sie sollen.
Es gibt eine Datenschutzerklärung, der Link ist an zwei Stellen lebendig, der Text stimmt mit dem überein, was die App tatsächlich erhebt.
Die Screenshots sind vom aktuellen Build, ohne Photoshop und ohne Features aus der Zukunft.
Ich bin die Liste der Berechtigungen durchgegangen - nur die nötigen übrig gelassen, zu jeder eine verständliche Erklärung, wozu sie da ist.
Die Beschreibung und die Datenschutz-Labels im Eintrag versprechen nichts, was es in der App nicht gibt.

Die App hat eine KI geschrieben? Füttere sie mit diesem Prompt - sie soll selbst die Minen aufspüren, die sie so gern legt. Lies die Antwort nur mit eigenen Augen und glaub ihr nicht aufs Wort: Die KI kann sich Probleme ausdenken und echte verstecken.

Prüfe meine App, bevor ich sie zum Review im App Store und Google Play einreiche. Finde und liste alles auf, wofür sie abgelehnt werden könnte:

Bildschirme oder Buttons, die abstürzen, nichts tun oder ins Nichts führen.
Platzhalter: „Kommt bald“, Blindtext, graue Kästchen statt Bildern, TODO-Markierungen.
Kaputte oder temporäre Links (localhost, Entwürfe), besonders zur Datenschutzerklärung.
Berechtigungen, die angefordert werden, aber im Code gar nicht genutzt werden.
Sag zu jedem Fund: wo er im Code steckt und wie ich ihn entferne. Erfinde keine nicht existierenden Probleme - nur das, was wirklich da ist.

Häufige Fehler, wegen denen der Build abgelehnt wird

• Nur auf dem eigenen Gerät testen. Du hast schon Daten und alle Berechtigungen erteilt. Der Reviewer sieht eine saubere Installation, wo alles anders ist. Teste von null an.
• „Temporäre“ Platzhalter drinlassen. Ein Attrappen-Button oder ein „Kommt bald“-Bildschirm sind ein fertiger Ablehnungsgrund. In den Release geht nur, was funktioniert.
• Links nicht von Hand öffnen. Besonders die zur Datenschutzerklärung: ein einziger 404 - und der Build kommt zurück. Klick jeden vor dem Abschicken an.
• Screenshots in Photoshop malen. Das Schaufenster muss zum Build passen. Hübsche Features aus der Zukunft lesen sich wie Täuschung.
• Berechtigungen „auf Vorrat“ anfordern. Ein Zugriff, der nicht genutzt wird, ist ein Warnsignal. Nimm nur das Nötige und erklär wozu.
• Eine Ablehnung als Katastrophe sehen. Ein Reject ist ein Punkt auf der Checkliste, den du übersehen hast. Formulierung gelesen, repariert, wieder abgeschickt - und weiter geht’s.