Fallbeispiele für App-Store-/Google-Play-Ablehnungen und eine praktische Checkliste für die Freigabe

Man will die App veröffentlichen, und dann wird sie im Review zurückgewiesen. Das ist eine Hürde, die viele Entwickler mindestens einmal erleben.

Außerdem sind Abstürze oder fehlerhafte Builds längst nicht die einzigen Gründe, warum ein Review stoppt. Berechtigungsbeschreibungen, Datenschutzrichtlinien, Zahlungswege, Store-Metadaten oder fehlende Review-Kommentare können genauso zum Problem werden. Es ist nicht ungewöhnlich, dass operative Themen außerhalb der eigentlichen Implementierung die Ursache sind.

In diesem Artikel ordne ich häufige Ablehnungsfälle im App Store und bei Google Play nach Kategorien und fasse aus praktischer Sicht zusammen, was man vor der Einreichung prüfen sollte.

Zielgruppe

• Entwickler, die zum ersten Mal eine App im App Store / bei Google Play einreichen
• Entwickler, die schon einmal abgelehnt wurden und die Ursachen systematisch ordnen möchten
• Entwickler, die mit Cross-Platform-Stacks wie React Native oder Flutter arbeiten
• Teams, die eine Checkliste vor dem Release etablieren möchten

Begriffe, die man zuerst kennen sollte

Ein paar Begriffe, die im weiteren Verlauf auftauchen, ordnen wir zuerst kurz ein. Wenn man diese Grundlagen einmal sauber im Kopf hat, lassen sich die Ablehnungsfälle im zweiten Teil deutlich leichter lesen.

• reviewer: Die prüfende Person bei Apple oder Google. Geprüft wird nicht nur die App selbst, sondern auch die Store-Beschreibung, Screenshots, Angaben im Formular und die Review-Notizen.
• IAP (In-App Purchase): Apples In-App-Kaufsystem für digitale Inhalte oder Funktionen innerhalb der App.
• ATT (App Tracking Transparency): Der iOS-Mechanismus, der vor Tracking über andere Apps oder Websites hinweg eine Zustimmung vom Nutzer verlangt.
• IDFA: Eine Kennung für Werbemessung. Wenn sie in der App verwendet wird, müssen häufig ATT und App Privacy mitgeprüft werden.
• Data safety / App Privacy: Die Selbstauskunft zur Datenerhebung bei Google Play / im App Store. Wird ein SDK ergänzt, aber die Angabe nicht aktualisiert, entsteht schnell ein Widerspruch.
• target SDK: Der Wert, der zeigt, auf welches Android API level die App ausgerichtet ist. minSdkVersion bezeichnet dagegen die minimale unterstützte OS-Version und meint etwas anderes.
• Store-Metadaten: Alle Informationen, die im Store angezeigt oder eingereicht werden, etwa Screenshots, Beschreibungstext, Untertitel, Kategorie, Altersfreigabe und Formularangaben.
• WebView: Eine Komponente, die Webseiten innerhalb der App anzeigt. Praktisch, aber wenn der Großteil des Bildschirms davon abhängt, wirkt der native Mehrwert oft schwach.
• UGC (User Generated Content): Von Nutzern erstellte Inhalte wie Kommentare, Bilder, Profile oder Reviews.
• restore purchases: Der Pfad zum Wiederherstellen früherer Käufe. Für Abo- und Einmalkauf-Szenarien ist das wichtig.
• entitlement: Eine Berechtigungskonfiguration für Apple Capabilities oder bestimmte Funktionen. Vieles ist für normale Apps nutzbar, einige spezielle entitlements erfordern aber Apple-Freigaben oder Zusatzbedingungen.

Die Perspektive der Reviewer zuerst verstehen

Wer Ablehnungen reduzieren will, kommt mit dem bloßen Lesen der Guidelines nicht weit genug. Hilfreicher ist zu verstehen, was Reviewer in kurzer Zeit tatsächlich prüfen, weil sich daraus Prioritäten deutlich besser ableiten lassen.

Besonders häufig bleibt eine App in folgenden Zuständen hängen:

• Die Funktion ist vorhanden, aber die Erklärung ist unzureichend.
• Es wird eine Berechtigung angefordert, aber der Bezug zur Funktion ist unklar.
• Es gibt eine Bezahlfunktion, aber Preis oder Kündigungsweg sind nicht eindeutig.
• Screenshots oder Beschreibung stimmen nicht mit der tatsächlichen App überein.
• Der reviewer kann sich nicht einloggen und die Hauptfunktionen nicht prüfen.

Vor visueller Schönheit zählen im Review vor allem Sicherheit, Konsistenz und Vollständigkeit.

Unterschiede zwischen App Store und Google Play zuerst ordnen

Beide Plattformen achten darauf, dass die App sicher ist, nicht irreführt und nicht unfertig wirkt. Die Punkte, an denen Reviews häufig hängen bleiben, unterscheiden sich aber leicht.

Grob gesagt bleibt der App Store eher an der Strenge bei App-Erlebnis, Zahlungen und Datenschutz-Erklärungen hängen, während Google Play eher an technischen Anforderungen und der Konsistenz der Selbstauskunft scheitert.

Deshalb ändert sich selbst bei derselben App die Reihenfolge der Vorbereitung leicht.

• App Store: Erst Verhalten auf echten Geräten, Paywall, Berechtigungstexte und Review-Kommentare schärfen.
• Google Play: Erst target SDK, permissions, Data safety und Anzeigen-Angaben bereinigen.

Fallstudien anhand typischer Rückweisungs- und Publishing-Block-Texte

Hier werden typische Formulierungen aus dem App-Store-Review und aus Google-Play-Publishing-Blocks zitiert, um zu klären, was die jeweilige Aussage praktisch bedeutet und was man zuerst korrigieren sollte. Die Kategorien im weiteren Verlauf lassen sich gut als Detailerläuterungen zu diesen Fällen lesen.

Case 1: App Store Absturz direkt nach dem Start

"Wir haben beim Review Ihrer App auf einem iPhone mit iOS 17.0 über Wi-Fi einen oder mehrere bugs festgestellt. Konkret ist die App unmittelbar nach dem Start abgestürzt."

Das wird nicht als vorübergehender Fehler behandelt, sondern als schwerer Defekt, der sich auf dem Review-Gerät reproduzieren lässt. Der erste Schritt ist daher, das Verhalten im Flugmodus, nach einer frischen Installation, mit leerem Account und unter langsamer Verbindung zu prüfen und alle Vorgänge aufzulisten, die unmittelbar nach dem Start laufen.

Case 2: Fehlende Privacy Policy im App Store

"Ihre App sammelt Nutzer- oder Nutzungsdaten, hat aber keine privacy policy URL."

Das bedeutet, dass die App über SDKs oder eigene APIs Daten verarbeitet, aber die öffentliche Erklärung für Nutzer fehlt. Als Erstes sollte man eine öffentliche URL bereitstellen und dort gesammelte Daten, Zweck der Nutzung, mögliche Weitergabe an Dritte und Kontaktmöglichkeiten klar benennen und anschließend die Einstellungen in App Store Connect und App Privacy darauf abstimmen.

Case 3: Digitale Käufe nutzen im App Store kein IAP

"Ihre App bietet den Kauf digitaler Inhalte an, aber der Kaufmechanismus verwendet keine in-app purchase."

Das ist kein Problem der Preisdarstellung, sondern der Hinweis, dass die gewählte Zahlungsart nicht zur Art des verkauften Produkts passt. Zuerst sollte man auf Funktionsebene aufteilen, was genau verkauft wird, und alles, was als digitaler Wert in der App konsumiert wird, auf ein IAP-orientiertes Modell umstellen.

Case 4: Google Play erfüllt die target-API-Anforderung nicht

"Wenn Sie eine neue App veröffentlichen, müssen Sie Android 15 (API level 35) oder höher targeten."

Google Play arbeitet nicht nur mit klassischen rejection mails, sondern blockiert schon vor der Einreichung über Anforderungen in der Console. Wenn dieser Text erscheint, ist das Problem noch nicht die App-Qualität, sondern ein nicht erfülltes Publishing-Kriterium. Als Erstes sollte man nicht nur targetSdkVersion, sondern auch abhängige Bibliotheken, Berechtigungsunterschiede, Benachrichtigungen und Hintergrundverhalten in einen Update-Plan aufnehmen.

Case 5: Neues Google-Play-personal-account kommt nicht in production

"Sie müssen für Ihre App einen closed test mit mindestens 12 Testern durchführen, die in den letzten 14 Tagen durchgehend opted-in waren."

Beim ersten Release kann man unabhängig von der Qualität der App an einem production gate hängen, das vom account-Typ abhängt. Ein neues personal account kann nicht veröffentlichen, solange closed test und production access nicht erfüllt sind. Zusätzlich kann eine device verification auf einem Android-Gerät durch den account owner erforderlich sein.

Der erste Schritt ist, zu prüfen, ob das Zielkonto tatsächlich ein neues personal account ist, und die Bedingungen für 12 Tester / 14 Tage, kontinuierliches Opt-in und die device verification über die Play Console mobile app frühzeitig abzuschließen.

Im App Store kommen solche Themen oft als Review-Kommentare zurück, bei Google Play eher als Console-Blocker oder als Abweichungen in den Angaben. Inhaltlich laufen die meisten Fälle aber auf dasselbe hinaus: unfertige App, unzureichende Erklärung, inkonsistente Angaben oder nicht erfüllte Publishing-Voraussetzungen.

Kategorie 1: Vollständigkeit der App

1. Die App stürzt direkt nach dem Start ab

API-Fehler beim ersten Start, fehlgeschlagene Initialisierung einer lokalen DB oder nil-Zugriffe gehören zu den typischsten Gründen für eine Rückweisung. Mit nil-Zugriff ist hier gemeint, dass eine App auf ein Objekt zugreift, bevor dort überhaupt ein Wert vorhanden ist. Da die Geräteumgebung des reviewer nie exakt der eigenen entspricht, sollte man die Startphase lieber übervorsichtig absichern.

@main
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .onAppear {
                    setupApp()
                }
        }
    }

    private func setupApp() {
        do {
            try initializeDatabase()
        } catch {
            print("DB init failed: \(error)")
        }
    }
}

Zu prüfen ist:

• Die App crasht beim ersten Start nicht, auch wenn noch kein Account existiert.
• Die App lässt sich selbst ohne Netzverbindung starten.
• Wenn das Laden notwendiger Daten fehlschlägt, gibt es einen Fallback-Screen.

Eine wirksame Lösung ist, Startlogik in zwei Klassen aufzuteilen:

• Verarbeitung, die unbedingt erfolgreich sein muss, bevor etwas angezeigt werden kann
• Verarbeitung, die fehlschlagen und später erneut versucht werden kann

Es gibt zum Beispiel keinen Grund, die ganze App wegen Remote-Config oder vorab geladener Empfehlungen zu blockieren. Wenn zuerst der Home-Screen oder wenigstens ein minimales Grundgerüst erscheint und nur fehlgeschlagene Teile erneut versucht werden, fällt die App bei Unterschieden in der Review-Umgebung deutlich seltener aus.

In der Praxis ist man mit dieser Reihenfolge oft am schnellsten:

• Crash-Logs einsammeln
• Alle Initialisierungsschritte beim Start auflisten
• Synchronen Muss-Erfolgs-Code reduzieren
• Auf echten Geräten im Flugmodus, nach frischer Installation und mit leeren Daten testen

2. Funktionen sind unimplementiert oder Platzhalter sind noch sichtbar

Screens, auf denen nur "Coming Soon" steht, Buttons ohne Reaktion oder tote Links lassen die App schnell unfertig wirken.

Kurz vor der Einreichung ist es meist sicherer, diese Punkte vor neuen Features zu priorisieren:

• Unimplementierte Funktionen entfernen, die nur bereits im Menü auftauchen
• Dummy-Texte und Test-Strings löschen
• Error-Screens und Empty States wenigstens auf ein Mindestniveau bringen

3. Ohne Login lässt sich nichts verifizieren

Auch bei Apps mit Login-Pflicht steigt die Ablehnungswahrscheinlichkeit, wenn der reviewer die Hauptfunktionen nicht erreichen kann.

Benötigt wird nicht nur ein Account, sondern der kürzeste mögliche Verifikationspfad.

• Demo-Account bereitstellen
• Falls 2FA nötig ist, die Schritte notieren
• Falls bestimmte Funktionen nur für spezielle Rollen sichtbar sind, das erläutern
• Falls Sandbox-Daten nötig sind, den Ausgangszustand erklären

Die Grundidee ist, einen Zustand herzustellen, in dem der Reviewer den Wert der App auf dem kürzesten Weg erkennen kann. Idealerweise gibt es einen read-only Review-Account, mit dem Hauptscreens ohne Registrierung oder Support-Kontakt geprüft werden können.

Mit Sandbox-Daten sind hier Dummy-Daten für Review und Verifikation gemeint, die keine echten Nutzer beeinträchtigen. Bestellhistorien, Beiträge, Abo-Status oder Standortdaten auf einer Karte vermitteln den Wert der App deutlich besser, wenn sie nicht leer sind.

Wenn SMS-Verifizierung oder ein Einladungssystem im Spiel sind, sollte man das Problem nicht ungefiltert an den reviewer weiterreichen.

• Einen Review-Account mit langer Gültigkeit ausstellen
• Bei 2FA einen Backup-Code oder Alternativweg bereitstellen
• Wenn ein leerer Startzustand den Wert der App nicht zeigt, Testdaten vorbefüllen
• Mit der späteren Vorlage für Review-Kommentare auch die Erreichbarkeit der Funktionen beschreiben

Kategorie 2: Datenschutz und Berechtigungen

4. Es gibt keine Datenschutzrichtlinien-URL

Wenn die App Nutzer- oder Nutzungsdaten verarbeitet, aber keine Privacy Policy URL hat, ist das ein erhebliches Risiko. Das ist weniger ein Problem des Binaries als eines unvollständigen Einreichungssets.

Mindestens folgende Punkte sollten in der Datenschutzrichtlinie klar benannt sein:

• Welche Daten erhoben werden
• Wofür sie verwendet werden
• Ob sie an Dritte weitergegeben werden
• Wie lange sie gespeichert werden
• Wie Nutzer Löschung oder Korrektur verlangen können

Leicht zu verwechseln ist hier, dass Privacy Policy und App Privacy / Data safety verschiedene Dinge sind.

• Privacy Policy: Öffentlich lesbares Dokument für Nutzer
• App Privacy / Data safety: Selbstauskunft, die an den Store übermittelt wird

Nur eines von beiden reicht nicht. Beide müssen inhaltlich zusammenpassen.

Am schnellsten ist es meist, zuerst eine öffentliche Seite zu erstellen, auf der steht, was gesammelt wird, wofür es verwendet wird und wie man Kontakt aufnimmt. Danach gleicht man diese Informationen mit dem SDK-Inventar ab und aktualisiert die Angaben in App Store Connect / Play Console.

5. Die App fordert Berechtigungen an, die sie nicht nutzt

Berechtigungen wie Standort, Kontakte, Mikrofon oder Kamera erzeugen schnell Misstrauen, wenn sie nicht klar an eine Funktion gebunden sind. Häufig schleusen Bibliotheken unnötige Berechtigungen mit ein.

import { Alert } from 'react-native'
import * as Location from 'expo-location'

async function requestLocationForMap() {
  const { status } = await Location.requestForegroundPermissionsAsync()
  if (status !== 'granted') {
    Alert.alert('Für die Anzeige naher Filialen auf der Karte ist eine Standortfreigabe erforderlich')
    return
  }

  // Ablauf für die Kartenanzeige
}

Der Kernpunkt ist, nur die Berechtigungen anzufragen, die wirklich genutzt werden, und zwar genau dann, wenn sie gebraucht werden.

Der praktische Trick ist, nicht nur Berechtigungsaufrufe im Code zu suchen, sondern auch Deklarationen aus Abhängigkeiten zu kontrollieren. Unter Android gehört dazu AndroidManifest.xml, unter iOS Info.plist plus die tatsächlich eingebundenen SDKs. Andernfalls bleiben leicht unbeabsichtigte Berechtigungen übrig.

6. Der Berechtigungstext ist zu abstrakt

Formulierungen wie "für ein besseres Erlebnis" erklären nicht, wofür die Berechtigung konkret gebraucht wird. Der Text muss an eine reale Funktion gebunden sein.

Gute Beispiele:

• Um nahe Filialen auf der Karte anzuzeigen
• Um ein Profilbild aufzunehmen
• Um mit der Kamera Barcodes zu scannen

Schwache Beispiele:

• Zur Verbesserung des Erlebnisses
• Zur Steigerung der Bequemlichkeit
• Zur Verbesserung der Servicequalität

<key>NSLocationWhenInUseUsageDescription</key>
<string>Wird verwendet, um nahe Filialen auf der Karte anzuzeigen</string>

<key>NSCameraUsageDescription</key>
<string>Wird verwendet, um ein Profilfoto aufzunehmen</string>

7. App Tracking Transparency ist nicht sauber berücksichtigt

Wenn die App IDFA verwendet, müssen ATT-Dialog und App-Privacy-Angaben konsistent sein. Außerdem sollte die App auch ohne Tracking-Zustimmung sinnvoll funktionieren.

ATT ist hier der Mechanismus, der vor dem Zugriff auf IDFA eine Erlaubnis einholt. IDFA wird typischerweise für Werbemessung und Attribution verwendet. Praktisch reicht es, das so zu verstehen: Sobald ein Ad-SDK eingebunden ist, ein Analyse-SDK IDFA liest oder Nutzer über Drittdaten hinweg verfolgt werden, schaut das Review genauer hin.

import AppTrackingTransparency

func requestTrackingPermission() {
    ATTrackingManager.requestTrackingAuthorization { status in
        switch status {
        case .authorized:
            break
        case .denied, .restricted, .notDetermined:
            break
        @unknown default:
            break
        }
    }
}

In der Praxis ist folgende Reihenfolge oft sinnvoll:

• Erfassen, welche SDKs IDFA oder tracking nutzen
• Prüfen, ob tracking wirklich nötig ist
• Wenn nicht, SDK-Einstellungen oder Abhängigkeiten entfernen, sodass ATT überflüssig wird
• Wenn doch, ATT-Dialog, App Privacy und In-App-Erklärung aufeinander abstimmen
• Sicherstellen, dass die Hauptfunktionen auch ohne Zustimmung funktionieren

Kategorie 3: Bezahlung und Geschäftsmodell

8. Digitale Inhalte werden zu externer Zahlung gelenkt

Wenn die App digitale Güter oder Funktionsfreischaltungen innerhalb der App verkauft, erwartet der App Store grundsätzlich IAP. Nutzer zu Web-Zahlungen oder Käufen auf externen Seiten zu lenken, führt mit hoher Wahrscheinlichkeit zu Problemen.

Wichtig ist diese Einordnung:

• Physische Waren und persönliche Dienstleistungen dürfen oft extern bezahlt werden
• Digitale Inhalte und Premium-Funktionen sollten grundsätzlich IAP nutzen
• Wenn eine Reader App Links zur Account-Erstellung oder -Verwaltung auf externen Seiten anbietet, braucht sie das External Link Account Entitlement
• Selbst wenn eine Reader-App-Ausnahme greift, sind Kategorie und Implementierungsbedingungen stark eingeschränkt

Wenn unklar ist, ob IAP nötig ist, hilft die Frage, ob das verkaufte Gut als digitaler Wert innerhalb der App konsumiert wird.

• Typisch für IAP: Werbung entfernen, Premium-Funktionen, Spielwährung, unbegrenzte Artikel, unbegrenzter Videozugang
• Oft mit externer Zahlung möglich: physische Produkte, Fahrdienste, Unterricht vor Ort, Essenslieferung, Hotelbuchung

Wenn bereits zu externer Zahlung gelenkt wurde und genau daran das Review hängt, muss man sich meist in eine dieser Richtungen bewegen:

• Das Zahlungsdesign auf IAP umstellen
• Sorgfältig prüfen, ob die Reader-App-Bedingungen wirklich erfüllt sind
• Digitale Güter und physische Services trennen und den In-App-Fluss neu strukturieren

9. Die Abo-Erklärung ist zu schwach

Bei Abos wirken unklare Preise, Verlängerungszyklen, Auto-Renew-Mechanik oder Kündigungswege schnell unzureichend aus Sicht des Nutzerschutzes.

Auf Paywall oder in der Store-Beschreibung sollten mindestens folgende Punkte klar erkennbar sein:

• Name des Plans, Laufzeit und enthaltene Leistungen
• Der Gesamtbetrag ist eindeutig angegeben; bei Jahresplänen sollte der Jahrespreis am klarsten hervortreten
• Verlängerungsintervall und Auto-Renew sind verständlich
• Der reguläre Preis nach einem kostenlosen Test ist klar
• Es gibt Links zu Terms of Service und Privacy Policy
• Es gibt einen sign in- oder restore purchases-Weg für bestehende Abonnenten
• Der Kündigungsweg ist verständlich

Ein typischer Fehler ist, den umgerechneten Monatspreis groß herauszustellen, während echter Rechnungsbetrag und Verlängerungsbedingungen schwer zu erfassen sind. Bei Jahresplänen ist es sicherer, zuerst den Jahresgesamtpreis deutlich zu zeigen und den Monatswert nur ergänzend darunter zu nennen.

Zur Prüfung eines Abo-Screens hilft oft diese Struktur:

• Planname
• Abrechnungszeitpunkt
• Gesamtbetrag
• Regulärer Preis nach der Testphase
• Wiederherstellungspfad
• Nutzungsbedingungen und Datenschutzrichtlinie
• Verwaltungs- oder Kündigungsweg

Eine Formulierung wie "7 Tage kostenlos, danach automatische Verlängerung für 7.200 JPY pro Jahr" ist im Review weniger missverständlich, weil sie in einem Satz erklärt, was nach der Gratisphase passiert.

Damit ein Kauf-Screen im Review robuster wird, sollte er außerdem die Fragen beantworten, über die Nutzer typischerweise stolpern:

• Welcher Plan ist aktuell ausgewählt?
• Welcher Betrag wird jetzt berechnet?
• Wie viel kostet es nach Ablauf der Gratisphase?
• Bis wann muss gekündigt werden, um die nächste Belastung zu stoppen?
• Wo kann ein bestehender Abonnent den Kauf wiederherstellen?

// React Native kann allein StoreKits system-provided UI nicht direkt öffnen,
// daher ist dies ein Fallback-Beispiel, wenn keine native iOS-Bridge möglich ist.
import { Linking, Text, TouchableOpacity } from 'react-native'

function SubscriptionSettings() {
  return (
    <TouchableOpacity
      onPress={() => Linking.openURL('https://apps.apple.com/account/subscriptions')}
    >
      <Text>Abo verwalten</Text>
    </TouchableOpacity>
  )
}

Wenn eine native iOS-Implementierung möglich ist, wirkt es natürlicher, die von Apple dokumentierte showManageSubscriptions(in:)-Schnittstelle zu nutzen, um die system-provided management UI zu öffnen.

10. Die Reader-App-Ausnahme wird zu weit ausgelegt

Die Reader-App-Ausnahme wirkt bequem, ist aber auf einen engen Rahmen begrenzt. Die Hauptfunktion muss tatsächlich Zeitschriften, Zeitungen, Bücher, Audio, Musik oder Video betreffen, und die App soll Inhalte oder Abos zugänglich machen, die außerhalb der App erworben wurden.

Außerdem erfordert die Anzeige von Links zur Account-Erstellung oder -Verwaltung auf externen Seiten das External Link Account Entitlement. Apps, die auf iOS / iPadOS / tvOS IAP anbieten, kommen für dieses entitlement nicht in Betracht. Die Annahme "Wir sind eine Reader App, also dürfen wir frei zu externer Zahlung lenken" ist daher falsch.

Video-, Musik- oder Buchinhalte werden anders behandelt als App-Funktionen oder In-Game-Währung. Wenn man die eigene Kategorie vor der Einreichung nicht sauber klärt, wird die Bewertung leicht inkonsistent.

Wenn Unsicherheit besteht, ist es sicherer zu ordnen, ob Inhalt oder Funktion verkauft wird und wo der Kaufpfad liegt, und diese Logik zusätzlich in Store-Beschreibung und Review-Kommentar zu erläutern.

Praktisch helfen vor der Einreichung diese drei Yes/No-Fragen:

• Besteht die Hauptfunktion wirklich in der Bereitstellung von Zeitschriften, Zeitungen, Büchern, Audio, Musik oder Video?
• Dient die Struktur dazu, extern gekaufte Inhalte zugänglich zu machen?
• Bietet die iOS-Version kein IAP an?

Wenn eine dieser drei Fragen nicht klar mit Ja oder Nein beantwortet werden kann, ist es sicherer, nicht auf Grundlage der Reader-App-Ausnahme zu planen.

Kategorie 4: Design und Erlebnisqualität

11. Die UI weicht zu stark von Plattform-Erwartungen ab

Vollständig eigene Navigationssysteme, fehlende Rückwege oder schlecht lesbare Kontraste mindern die wahrgenommene Bedienbarkeit. Im Review ist es meist besser, Bedienlogik im Sinne der Plattform-Erwartungen zu priorisieren statt visuelle Eigenständigkeit um jeden Preis.

12. Es wirkt so, als sei nur eine WebView verpackt worden

Eine App, die im Wesentlichen nur eine Website anzeigt, kann als native Erfahrung mit geringem Mehrwert angesehen werden.

Risikomuster:

• Fast die gesamte Oberfläche besteht aus WebView
• Es gibt keine spezifischen nativen Funktionen
• Offline funktioniert nichts
• Es gibt keinen Mehrwert wie Geräteintegration oder Benachrichtigungen

Damit die App nicht wie ein bloßer Wrapper wirkt, hilft es, den Mehrwert über Teilen, Benachrichtigungen, Kamera, lokale Speicherung oder Offline-UX klar sichtbar zu machen.

WebView ist nicht das Problem an sich. Problematisch ist, wenn man eine native App einreicht, deren Inhalt praktisch wie die Website selbst aussieht. Wer WebView verwendet, sollte mindestens in einem dieser Punkte nativen Mehrwert schaffen:

• Native Navigation oder Settings-Screens
• Gerätefunktionen wie Teilen, Benachrichtigungen, Kamera oder Dateispeicherung
• Offline-Erklärungen oder Cache-Darstellung
• App-spezifische Interaktionen, die es im Web nicht gibt

13. Werbung oder Zahlungswege sind überzogen

Wenn Werbung auffälliger ist als der Inhalt, Layouts zu Fehl-Taps verleiten oder schwer zu schließende interstitials übermäßig eingesetzt werden, schadet das nicht nur dem Review, sondern auch den Bewertungen. Monetarisierung ist erlaubt, aber man muss auf echten Geräten prüfen, ob sie das Nutzungserlebnis nicht zerstört.

Kategorie 5: Store-Metadaten und Angaben

Im Review wird nicht nur die App selbst betrachtet, sondern auch die Store-Beschreibung und die gemachten Angaben. Wenn diese von der Realität abweichen, kann die App selbst bei korrekter Implementierung blockiert werden.

Punkte, die man erneut prüfen sollte:

• Screenshots
• App-Beschreibung
• Untertitel
• Altersfreigabe
• App Privacy / Data safety
• Angabe, ob Werbung enthalten ist

Besonders riskant ist es, nicht implementierte Funktionen in der Beschreibung zu erwähnen. Auch geplante künftige Funktionen sollte man besser nicht vorab bewerben.

Kategorie 6: UGC und Hochrisiko-Kategorien

14. Es gibt UGC, aber keinen Moderationspfad

Wenn eine App nutzergenerierte Inhalte verarbeitet, reicht eine Posting-Funktion allein nicht aus. Mindestens folgende Wege sollten vorhanden sein:

• Meldemechanismus
• Blockieren
• Nutzungsbedingungen
• Kontaktkanal
• Richtlinie zum Umgang mit Verstößen

Wenn es UGC gibt, aber keine sichtbaren Schutzmechanismen, sorgt sich das Review schnell um das operative Risiko.

15. Die Erklärungspflicht ist in Gesundheits-, Finanz- oder Kinder-Kategorien zu schwach

Medizin- und Gesundheits-Apps, Finanz- und Investment-Apps, Kinder-Apps und Apps mit dauerhafter Standortnutzung werden strenger geprüft als allgemeine Kategorien. Höhere Maßstäbe bei Genauigkeit, rechtlicher Konformität, missverständnisfreier Formulierung und klarer Kontaktmöglichkeit sind hier angemessen.

Gerade in diesen Kategorien kann gut gemeint wirkender Marketingtext nach hinten losgehen. Aussagen zu Gesundheit oder Investitionen sollten keine Erfolgsgarantie darstellen, keine Fehlvorstellungen fördern und keine überzogenen Erwartungen wecken.

Praktisch helfen folgende Prüffragen:

• Medizin / Gesundheit: Werden Diagnose oder Behandlung nicht zu eindeutig behauptet?
• Finanzen: Werden weder Gewinne garantiert noch übertriebene Erwartungen erzeugt?
• Kinder: Sind externe Links, Werbung oder Zahlungswege zu aggressiv?
• Dauerhafte Standortnutzung: Ist permanente Erfassung wirklich nötig oder gibt es Alternativen?

In dieser Kategorie ist es wichtiger zu prüfen, ob die App zu viel verspricht und ihrer Erklärungspflicht nachkommt, als weitere Funktionen hinzuzufügen.

Häufige Review-Formulierungen richtig lesen

Review-Nachrichten sind oft kurz und abstrakt. Liest man sie wortwörtlich, ist nur schwer erkennbar, was konkret behoben werden muss. Praktisch wird es leichter, wenn man sie in folgende Bedeutungen übersetzt.

Wichtig ist hier, Review-Texte wie eine Spezifikation zu lesen. So abstrakt sie wirken mögen, lassen sich die meisten Fälle auf unfertige App, unzureichende Erklärung oder inkonsistente Angaben zurückführen.

Punkte, die bei Google Play leicht übersehen werden

Anforderungen für das erste Release eines neuen personal account

Für Leser, die zum ersten Mal bei Google Play veröffentlichen, ist dieser Punkt besonders wichtig. Ein neu angelegtes personal developer account hat unabhängig vom App-Inhalt kontoabhängige Voraussetzungen für den Schritt in production.

Typischerweise sind das diese zwei Punkte:

• Am closed test müssen kontinuierlich mindestens 12 Tester teilnehmen
• Die Android-device verification über die Play Console mobile app muss abgeschlossen sein

Das wirkt weniger wie eine klassische Ablehnungs-Mail und mehr wie ein Block in der Play Console, der den Wechsel nach production verhindert. Selbst wenn die App fertig ist, kann sie also nicht veröffentlicht werden, solange die Konto-Voraussetzungen nicht erfüllt sind.

Typische Stolperstellen beim ersten Release:

• Genug Tester vorhanden, aber die 14 Tage durchgängiges Opt-in sind nicht erfüllt
• Tester sind zwar beigetreten, liefern aber kaum Nutzung oder Feedback
• Der account owner hat die device verification nicht abgeschlossen
• Man nimmt an, internal testing reiche aus und übersieht die closed-test-Bedingung

Beim ersten Release ist es sicherer, diese Punkte parallel zur Implementierungsprüfung frühzeitig zu erledigen.

Verspätete target-SDK-Anpassung

Die target API level-Anforderungen von Google Play ändern sich laufend. Erforderlich ist daher ein Prozess, der zum Zeitpunkt der Einreichung die aktuellen Play-Console-Anforderungen prüft, nicht nur den Wert, der zum Zeitpunkt des Schreibens dieses Artikels aktuell war.

Leicht verwechselt werden targetSdkVersion und minSdkVersion.

• targetSdkVersion: Wie weit neue Android-Verhaltensweisen aktiv unterstützt werden sollen
• minSdkVersion: Wie alte Android-Versionen noch unterstützt werden

Das heißt: Auch wenn minSdkVersion unverändert bleibt, kann Google Play die Veröffentlichung blockieren, wenn allein targetSdkVersion den aktuellen Anforderungen nicht genügt.

android {
    compileSdkVersion rootProject.ext.compileSdkVersion

    defaultConfig {
        targetSdkVersion rootProject.ext.targetSdkVersion
        minSdkVersion 24
    }
}

Wichtig ist, nicht bei einer Zahländerung stehen zu bleiben. Ein höheres target SDK kann das Berechtigungsmodell, Hintergrundbeschränkungen, Benachrichtigungsverhalten, foreground services, Dateizugriffe und mehr verändern. Bei einem Update sollten daher diese Punkte mitgeprüft werden:

• Kompatibilität von Android Gradle Plugin und Abhängigkeiten
• Unterschiede beim Verhalten von Berechtigungsdialogen
• Einschränkungen bei Benachrichtigungen und Hintergrundverarbeitung
• Tests auf den wichtigsten Zielgeräten

Gefährliche Berechtigungen stehen noch im Manifest

Bleiben ungenutzte gefährliche Berechtigungen im Manifest stehen, entsteht allein dadurch Erklärungsbedarf. Besonders CONTACTS, CALL_LOG, SMS und READ_PHONE_STATE sollten sorgfältig überprüft werden.

<!-- Nur tatsächlich genutzte Berechtigungen deklarieren -->
<!-- <uses-permission android:name="android.permission.READ_CONTACTS" /> -->
<!-- <uses-permission android:name="android.permission.READ_CALL_LOG" /> -->

Data safety passt nicht zur Implementierung

Es kommt häufiger vor, als man denkt: Ein Analytics-SDK oder Ad-SDK wird hinzugefügt, aber die Angaben in der Console bleiben veraltet. Immer wenn SDKs geändert werden, sollte Data safety als verpflichtender Aktualisierungspunkt mitlaufen.

Data safety ist der Bereich in Google Play, in dem angegeben wird, welche Daten die App sammelt oder teilt und wofür sie verwendet werden. App Privacy auf Apple-Seite beruht auf einer ähnlichen Idee. Wenn Implementierung und Angabe nicht zusammenpassen, sinkt das Vertrauen.

Am sichersten ist es, nicht aus dem Bauch heraus zu schreiben, sondern sauber zu inventarisieren:

• Eingebundene SDKs auflisten
• Für jedes SDK prüfen, welche Datentypen verarbeitet werden
• Auch die Daten der eigenen APIs erfassen
• Die Ergebnisse mit den Angaben in Play Console / App Store Connect abgleichen
• Bei Änderungen auch die Datenschutzrichtlinie aktualisieren

Berechtigungen genau dann anfragen, wenn sie gebraucht werden

Wenn direkt nach dem Start mehrere Berechtigungsdialoge gesammelt erscheinen, hinterlässt das bei Nutzern und reviewer schnell einen schlechten Eindruck.

Die bessere Strategie ist:

• Berechtigungen erst anfragen, wenn die Funktion erreicht wird
• Direkt davor eine kurze pre-permission-Erklärung anzeigen
• Für den deny-Fall einen Alternativpfad bereithalten

Das hilft nicht nur im Review, sondern verbessert häufig auch die Zustimmungsrate.

Was in die Review-Notizen gehört

Das Feld für Review-Kommentare wird leicht unterschätzt, ist aber ein wichtiger Ort, um Unsicherheit auf Seiten des reviewer zu reduzieren. Besonders wirksam ist es bei Apps mit Login-Pflicht, bei Apps mit Berechtigungen und bei Apps mit externer Geräteabhängigkeit.

Sinnvolle Inhalte sind:

• Demo-Account-Daten
• Schritte zu den Hauptfunktionen
• Erklärung, auf welchem Screen Berechtigungen verwendet werden
• Hinweise, wenn 2FA oder eine bestimmte Rolle notwendig ist
• Hinweise bei externer Server- oder Geräteabhängigkeit

Kurze Vorlagenbeispiel:

Review-Konto:
Email: reviewer-demo@example.com
Password: xxxxxxxx

Wichtiger Testablauf:
1. Mit dem Review-Konto anmelden
2. Die Registerkarte Map öffnen, um die Standortberechtigung zu testen
3. Settings > Subscription öffnen, um die Kündigungshinweise zu prüfen

Vorgehen nach einer Ablehnung

Entscheidend nach einer Ablehnung ist nicht, emotional zu widersprechen, sondern den Hinweis korrekt zu klassifizieren.

Die Grundreihenfolge lautet:

1. Den Hinweis noch einmal exakt lesen
2. Die Reproduktionsbedingungen prüfen
3. In Implementierungsfehler, Erklärungsdefizit oder Angabefehler einordnen
4. Falls nötig mit Screenshots oder Video ergänzen

Selbst wenn die Entscheidung wie eine Fehleinschätzung wirkt, ist es oft schneller, zuerst die Erklärungslücke zu schließen. Ein Einspruch ist in der Praxis meist das letzte Mittel.

In der Antwort funktioniert es in der Regel besser, kurz und klar zu schreiben, was konkret geändert wurde, statt eine lange Verteidigung zu formulieren.

Vielen Dank für das Review.

Wir haben das Problem als [implementation / metadata / clarification] eingeordnet.
Wir haben folgende Änderungen vorgenommen:
1. [issue] behoben
2. [metadata or review notes] aktualisiert
3. [account / explanation / screenshot] ergänzt

So lässt sich das prüfen:
1. Mit dem Review-Konto anmelden
2. [screen name] öffnen
3. [action] antippen

Falls nötig, können wir zusätzliche Screenshots oder eine Bildschirmaufnahme bereitstellen.

Auf das Wesentliche reduziert reichen drei Punkte: Ursache, Änderung und Prüfschritte. Je länger Teams mit Review-Themen ringen, desto eher vermischen sich genau diese drei Punkte und erschweren die Kommunikation.

Was in den 48 Stunden vor der Einreichung zu tun ist

Kurz vor dem Release ist die Versuchung groß, noch ein Feature einzubauen. Wer die Erfolgsquote im Review erhöhen will, fährt aber meist besser damit, die letzte Phase eher für Verifikation als für Implementierung zu nutzen.

48 Stunden vorher

• Store-Beschreibung, Screenshots, Altersfreigabe und Data safety / App Privacy erneut prüfen
• Die genutzten SDKs und Berechtigungen inventarisieren
• Reviewer-Account und Review-Kommentare vorbereiten

24 Stunden vorher

• Das Startverhalten auf dem aktuellen iPhone OS, einer vorherigen iOS-Version und mehreren Android-Geräten prüfen
• Flugmodus, langsame Verbindung und frische Installation testen
• Zahlungen, Login, Berechtigungsanfragen und Account-Löschpfade Ende-zu-Ende durchgehen

6 Stunden vorher

• Ein letztes Mal prüfen, ob Screenshots und reale App übereinstimmen
• Sicherstellen, dass Store-Angaben und SDK-Konfiguration nicht auseinanderlaufen
• Den Review-Kommentar mit Erreichbarkeit der Hauptfunktion und allen nötigen Hinweisen vollständig ausformulieren

Allein dieses 48-Stunden-Schema bei jedem Release durchzuziehen, senkt die Ablehnungsquote oft schon deutlich.

Operative Maßnahmen gegen Wiederholungsfehler

Auch nach einer erfolgreichen Freigabe tauchen dieselben Themen bei neuen Funktionen oder geänderten SDKs leicht wieder auf. Ob Einzelentwickler oder Team: Diese Maßnahmen reduzieren das Risiko spürbar.

• Wenn ein SDK hinzugefügt wird, Berechtigungen, Data safety und App Privacy als zusammengehöriges Update behandeln
• In der Store-Beschreibung nur bereits implementierte Funktionen nennen
• Bei neuen Berechtigungen den Zielscreen und den Erklärungstext gemeinsam im PR prüfen
• Die Release-Checkliste als Issue oder Vorlage wiederverwendbar machen
• Ablehnungsformulierungen und Reaktionen intern dokumentieren und bei künftigen Review-Notizen wiederverwenden

Der größte langfristige Gewinn liegt darin, Review-Antworten nicht jedes Mal neu erfinden zu müssen.

Checkliste vor der Einreichung

Lücken lassen sich leichter finden, wenn die Punkte in direkt nutzbare Formen für jede Plattform getrennt werden. Auch gemeinsame Punkte sind in beiden Tabellen enthalten.

App-Store-Checkliste vor der Einreichung

Google-Play-Checkliste vor der Einreichung

Zusammenfassung

Was App-Reviews am häufigsten stoppt, sind nicht einfache Bugs, sondern Abweichungen zwischen Implementierung und Erklärung sowie Lücken in der operativen Vorbereitung.

Besonders wichtig sind diese vier Punkte:

• Der reviewer kann die Hauptfunktionen ohne Verwirrung verifizieren.
• Die Gründe für Berechtigungen und Datenerhebung sind konkret erklärt.
• Zahlungsregeln und Store-Angaben sind sauber aufeinander abgestimmt.
• Store-Metadaten entsprechen der tatsächlichen Implementierung.

Je näher das Release rückt, desto größer wird die Versuchung, noch ein Feature zu ergänzen. Für eine bessere Review-Erfolgsquote ist es aber wirksamer, den letzten Tag in die Checkliste zu investieren.

Referenzlinks

• App Store Review Guidelines
• Auto-renewable subscriptions
• Google Play Policy Center
• Human Interface Guidelines
• In-App Purchase (Human Interface Guidelines)
• Distributing reader apps with a link to your website
• App testing requirements for new personal developer accounts
• Device verification requirements for new developer accounts
• Target API level requirements for Google Play apps
• App Tracking Transparency