Play Store Richtlinien: Häufige Ablehnungsgründe für React Native Apps

1. Warum Play Store Richtlinien laufend geprüft werden

Anders als bei Apple, wo der Review primär vor der Veröffentlichung stattfindet, prüft Google die Play Store Richtlinien kontinuierlich - auch nach dem Launch. Automatisierte Systeme analysieren Netzwerkverkehr, angeforderte Berechtigungen und App-Verhalten laufend gegen die deklarierten Angaben im Play Console Eintrag. Für React Native Apps bedeutet das: Ein Policy-Verstoß, der bei der Einreichung unbemerkt bleibt, kann Wochen oder Monate später trotzdem zu einer Entfernung führen, wenn Googles automatisierte Analyse eine Diskrepanz feststellt.

Ein zweiter Unterschied zu Apple: Bei den Play Store Richtlinien reicht schon eine einzelne eingebundene Drittanbieter-Bibliothek mit fragwürdigem Verhalten aus, um die gesamte App als Policy-Verstoß einzustufen - unabhängig davon, ob das Entwicklerteam sich dieses Verhaltens bewusst war. Die folgenden Abschnitte gehen die für React Native Teams wichtigsten Ablehnungsgründe im Detail durch, von Berechtigungen über Data Safety bis zum Umgang mit einer Sperrung.

2. Sensible Berechtigungen und die Permissions Declaration Form

Sensible Berechtigungen wie Standort, SMS und Anrufprotokolle gehören zu den am strengsten überwachten Bereichen der Play Store Richtlinien. Fordert eine React Native App eine dieser Berechtigungen an, verlangt Google zusätzlich zur technischen Deklaration im Manifest eine ausgefüllte Permissions Declaration Form im Play Console Eintrag, die den konkreten Nutzen der Berechtigung für den Kernfunktionsumfang der App begründet. Fehlt diese Begründung oder wirkt sie unplausibel, ist das einer der häufigsten Ablehnungsgründe für Apps mit erweiterten Zugriffsrechten.

Zusätzlich verlangen die Play Store Richtlinien, dass die App den Nutzern vor dem eigentlichen System-Berechtigungsdialog eine eigene, verständliche Erklärung zeigt, warum eine Berechtigung benötigt wird - ein sogenanntes "in-context permission priming". Für React Native Teams, die eine Bibliothek wie `react-native-permissions` einsetzen, reicht die reine technische Anfrage nicht aus; die UI muss den Kontext aktiv erklären, bevor der native Dialog erscheint.

{
  "permissions_declaration": {
    "permission": "ACCESS_FINE_LOCATION",
    "core_use_case": "Route optimization for delivery drivers - location is required continuously during an active delivery to calculate the fastest route.",
    "background_usage": true,
    "alternative_considered": "Foreground-only location was evaluated but does not support live route recalculation while the app is backgrounded."
  }
}

// Check a dangerous permission's grant status natively before
// triggering the system dialog, so the in-context explanation
// only appears when actually needed
fun hasLocationPermission(context: Context): Boolean {
    return ContextCompat.checkSelfPermission(
        context,
        Manifest.permission.ACCESS_FINE_LOCATION
    ) == PackageManager.PERMISSION_GRANTED
}

3. Data-Safety-Diskrepanz: Deklariertes vs. tatsächliches Verhalten

Der wohl häufigste Ablehnungsgrund unter den Play Store Richtlinien für React Native Apps entsteht durch eine Diskrepanz zwischen der deklarierten Data-Safety-Sektion und dem tatsächlichen App-Verhalten. React Native Projekte binden häufig mehrere Drittanbieter-SDKs für Analytics, Crash Reporting und Push Notifications ein, von denen jedes eigene Daten erfasst - ein Analytics-SDK sendet möglicherweise Geräte-IDs, ein Crash-Reporter überträgt Stacktraces, ein Push-Anbieter verarbeitet Push-Token, die potenziell mit Nutzerprofilen verknüpft werden können.

Google erkennt solche Diskrepanzen zunehmend über automatisierte Analyse des tatsächlichen Netzwerkverkehrs der App und vergleicht ihn mit den deklarierten Angaben. Wird eine Abweichung festgestellt, verlangen die Play Store Richtlinien zunächst eine Korrektur innerhalb einer gesetzten Frist - bei Ignorieren oder wiederholten Verstößen drohen härtere Konsequenzen bis zur Sperrung des gesamten Entwicklerkontos, nicht nur der einzelnen App.

{
  "declared_data_safety": {
    "device_identifiers": { "collected": true, "shared_with": ["analytics_provider"] },
    "crash_logs": { "collected": true, "shared_with": [] },
    "approximate_location": { "collected": false }
  },
  "note": "Every third-party SDK's actual network calls must match this declaration exactly"
}

4. Target API Level: Das rollierende Minimum

Google verlangt im Rahmen der Play Store Richtlinien, dass jede neue oder aktualisierte App ein Minimum-`targetSdkVersion` erfüllt, das jährlich angehoben wird - Apps, die dieses Minimum unterschreiten, werden weder neu veröffentlicht noch aktualisiert. Für React Native Projekte, die längere Zeit nicht auf eine neue Expo-SDK-Version oder React-Native-Version aktualisiert wurden, kann das rollierende Minimum unbemerkt zu einem Blocker werden, da das `targetSdkVersion` implizit von der zugrunde liegenden Android-Gradle-Konfiguration abhängt.

Ein häufiger Ablehnungsgrund entsteht, wenn ein Team ein React Native Projekt über Monate ohne größere Dependency-Updates pflegt und dann bei der nächsten Einreichung überrascht feststellt, dass das aktuelle `targetSdkVersion` bereits unter Googles neuem Minimum liegt. Regelmäßige Updates von Expo SDK beziehungsweise React Native selbst sind der zuverlässigste Weg, dieses Problem proaktiv zu vermeiden, statt kurz vor einer wichtigen Einreichung ein größeres Versions-Upgrade unter Zeitdruck durchführen zu müssen.

{
  "expo": {
    "android": {
      "targetSdkVersion": 35,
      "compileSdkVersion": 35
    }
  }
}

# Inspect an Android App Bundle's declared targetSdkVersion
# before uploading, to catch a rolling-minimum violation early
bundletool dump manifest --bundle=app-release.aab \
  | grep -A1 "targetSdkVersion"

# Cross-check against the current Play Store minimum
# published in the Play Console policy documentation

# Also confirm the compileSdkVersion is not lagging behind,
# since some native modules require a matching compile target
bundletool dump manifest --bundle=app-release.aab \
  | grep -A1 "compileSdkVersion"

5. Restricted Content und Families Policy

Die Play Store Richtlinien zu Restricted Content betreffen unter anderem Gewaltdarstellungen, illegale Aktivitäten und irreführende Gesundheitsversprechen - für die meisten React Native Business-Apps selten relevant, aber entscheidend für Apps mit nutzergenerierten Inhalten oder Community-Funktionen. Wird eine App zusätzlich für Kinder beworben oder richtet sich erkennbar an eine junge Zielgruppe, greifen die deutlich strengeren Families-Policy-Regeln, die bestimmte Werbe-SDKs, Tracking-Technologien und externe Links vollständig ausschließen.

Ein häufiger Fehler bei React Native Apps mit gemischter Zielgruppe: Ein generisches Analytics- oder Werbe-SDK wird unverändert für alle Nutzer eingebunden, obwohl ein Teil der Zielgruppe unter die Families-Policy fällt. Die Play Store Richtlinien verlangen in diesem Fall eine technische Trennung der SDK-Konfiguration nach Altersgruppe, was in der Praxis oft ein eigenes Build-Flag oder eine Remote-Config-Weiche erfordert.

6. Deceptive Behavior: Verschleierte Bundles und OTA-Updates

Deceptive Behavior ist einer der schärfer sanktionierten Bereiche der Play Store Richtlinien und betrifft App-Verhalten, das Nutzer oder das Play-Protect-System täuschen soll. Für React Native Apps mit OTA-Update-Mechanismen wie EAS Update ist hier besondere Sorgfalt gefragt: Lädt eine App nach der Installation dynamisch ausführbaren Code nach, kann das Play Protect als potenziell schädliches Verhalten einstufen, wenn der Mechanismus nicht transparent implementiert ist oder der nachgeladene Code stark verschleiert (obfuskiert) wird.

Legitime OTA-Update-Systeme wie EAS Update sind von den Play Store Richtlinien grundsätzlich toleriert, solange sie ausschließlich JavaScript-Bundle-Updates innerhalb der bereits genehmigten nativen Laufzeitumgebung ausliefern und keine neuen nativen Fähigkeiten oder Berechtigungen nachladen. Wird dieser Rahmen überschritten, etwa durch ein selbstgebautes Update-System, das komplette native Module nachlädt, steigt das Risiko einer Einstufung als Deceptive Behavior erheblich.

7. App Access: Test-Zugangsdaten und Video-Walkthroughs

Die Play Store Richtlinien zu App Access verlangen, dass Google-Reviewer jeden Teil einer App tatsächlich testen können - inklusive Bereichen hinter einem Login, einem Abo oder einer regionalen Sperre. Für React Native Apps mit Authentifizierung bedeutet das, im Play Console Eintrag ein funktionierendes Testkonto samt Zugangsdaten zu hinterlegen, ähnlich wie bei Apples App-Review-Notizen, aber mit eigenem, dediziertem Formular im Bereich "App-Zugriff" der Play Console.

Kann ein Teil der App nicht über ein Testkonto zugänglich gemacht werden, etwa weil eine Funktion an eine echte Zahlungstransaktion oder einen physischen Ort gebunden ist, verlangen die Play Store Richtlinien stattdessen ein Video, das den betreffenden Ablauf demonstriert. Ein häufiger Ablehnungsgrund entsteht, wenn das hinterlegte Testkonto zwar existiert, aber aufgrund einer abgelaufenen Testdaten-Umgebung oder eines geänderten Passworts beim Review nicht mehr funktioniert.

8. Appeal-Prozess und Policy-Status-Dashboard

Wird eine App wegen eines vermeintlichen Verstoßes gegen die Play Store Richtlinien abgelehnt oder entfernt, zeigt das Policy-Status-Dashboard in der Play Console den genauen Grund inklusive der betroffenen Richtlinie und, wo möglich, konkreter Beispiele aus dem geprüften Build. Dieses Dashboard ist der erste Anlaufpunkt, um zu verstehen, ob eine Ablehnung auf einem tatsächlichen Verstoß oder einem Missverständnis der App-Funktionalität beruht.

Für den Appeal-Prozess gilt: Je konkreter die Einreichung mit Screenshots, Code-Referenzen oder einer klaren Erklärung des betroffenen Verhaltens begründet wird, desto schneller fällt die erneute Prüfung aus. Bei wiederholten oder schwerwiegenden Verstößen gegen die Play Store Richtlinien - etwa bei Deceptive Behavior - ist die Erfolgsquote eines Appeals jedoch gering, weshalb eine gründliche Prävention deutlich wirtschaftlicher ist als ein nachträglicher Rechtsstreit mit Google.

9. Häufige Ablehnungsgründe im Überblick

Die folgende Übersicht fasst die in diesem Artikel behandelten Play Store Richtlinien und ihre typischen Auslöser zusammen, damit sie sich vor jeder Einreichung als Checkliste nutzen lässt.

Diese fünf Bereiche der Play Store Richtlinien decken den Großteil aller React-Native-spezifischen Ablehnungsgründe ab. Wer sie systematisch vor jeder Einreichung und regelmäßig auch nach der Veröffentlichung prüft, reduziert das Risiko einer nachträglichen Kontosperrung deutlich.

10. Zusammenfassung

Die Play Store Richtlinien unterscheiden sich von Apples Regelwerk vor allem dadurch, dass die Prüfung nicht mit der Veröffentlichung endet, sondern kontinuierlich weiterläuft. Für React Native Apps sind sensible Berechtigungen ohne plausible Begründung, eine Data-Safety-Sektion ohne Deckung im tatsächlichen SDK-Verhalten und ein veraltetes Target-API-Level die häufigsten Ablehnungsgründe. Hinzu kommen Deceptive-Behavior-Risiken bei intransparenten OTA-Updates und App-Access-Probleme durch verwaiste Testkonten.

Der wirksamste Schutz gegen wiederkehrende Probleme mit den Play Store Richtlinien ist ein regelmäßiger interner Review-Zyklus, der Data Safety, Permissions und Target API Level nicht nur vor der Einreichung, sondern auch nach jedem größeren Dependency-Update erneut prüft. Wer diese Prüfung als festen Bestandteil des Release-Prozesses etabliert, reduziert das Risiko einer plötzlichen Kontosperrung erheblich - ein Ereignis, das im schlimmsten Fall alle Apps eines Entwicklerkontos gleichzeitig betrifft.

11. FAQ: Play Store Richtlinien für React Native Apps