React Native: Play Console Eintrag erstellen und pflegen

1. Warum der Play Console Eintrag mehr ist als reine Formalität

Ein Play Console Eintrag umfasst weit mehr als das Hochladen einer App-Binärdatei. Google prüft bei jeder Einreichung automatisiert und teilweise manuell, ob Store-Listing, Content-Rating und Data-Safety-Angaben zueinander und zur tatsächlichen App passen. Für React Native und Expo Apps kommt hinzu, dass Third-Party-Bibliotheken - etwa für Analytics, Crash Reporting oder Push Notifications - eigene Datenverarbeitungen mitbringen, die im Play Console Eintrag korrekt deklariert werden müssen, auch wenn sie im eigenen JavaScript-Code nicht sichtbar sind.

Ein unvollständiger oder ungenauer Play Console Eintrag führt selten zu einer sofortigen Ablehnung, aber häufig zu Nachfragen, verzögerten Freigaben oder späteren Policy-Verstößen, wenn Google eine Diskrepanz zwischen deklariertem und tatsächlichem Verhalten feststellt. Die folgenden Abschnitte gehen den kompletten Weg durch: von der ersten App-Anlage über Store-Listing und Data Safety bis zu Testing-Tracks und Automatisierung der Einreichung.

2. Die App in der Play Console anlegen

Der erste Schritt für jeden Play Console Eintrag ist die Anlage der App im Play Console Dashboard unter einem bestehenden Entwicklerkonto. Dabei werden App-Name, Standardsprache und die grundlegende Einordnung als App oder Spiel festgelegt sowie die verbindlichen Erklärungen zu Entwicklerprogramm-Richtlinien und US-Exportgesetzen bestätigt. Der Package Name (z. B. `com.example.myapp`) wird an dieser Stelle festgelegt und kann danach nicht mehr geändert werden - er muss exakt mit dem `applicationId` in der React-Native- beziehungsweise Expo-Konfiguration übereinstimmen.

Direkt nach der Anlage zeigt die Play Console eine Checkliste offener Aufgaben, die abgearbeitet werden müssen, bevor die App auch nur in einen internen Test veröffentlicht werden kann. Diese Checkliste ist der rote Faden für den restlichen Play Console Eintrag: Store-Listing, Content-Rating, Data Safety, App-Content-Deklarationen und mindestens ein aktiver Testing-Track müssen vollständig sein, bevor eine Freigabe überhaupt möglich ist.

# Verify the applicationId matches the Play Console package name
# before any submission attempt
grep -R "applicationId" android/app/build.gradle
# applicationId "com.example.myapp"

# For Expo-managed projects, the equivalent value lives in app.json
grep -A1 '"package"' app.json

3. Store-Listing: Titel, Beschreibungen und Grafiken

Das Store-Listing ist der öffentlich sichtbare Teil des Play Console Eintrags und besteht aus App-Titel (max. 30 Zeichen), einer kurzen Beschreibung (max. 80 Zeichen, erscheint prominent in Suchergebnissen) und einer vollständigen Beschreibung (max. 4000 Zeichen). Für React Native Apps lohnt es sich, die kurze Beschreibung so zu formulieren, dass sie ohne Fachjargon den konkreten Nutzen der App transportiert - Google gewichtet diesen Text stark im Suchranking innerhalb des Play Stores.

Bei den Grafiken verlangt der Play Console Eintrag mindestens ein App-Icon (512x512px, PNG mit Alpha-Kanal), eine Feature-Grafik (1024x500px) und mindestens zwei Screenshots pro unterstützter Geräteklasse (Telefon, 7-Zoll-Tablet, 10-Zoll-Tablet). Screenshots sollten den tatsächlichen App-Zustand zeigen, da irreführende Screenshots gegen die Metadata-Richtlinien verstoßen und zu einer Ablehnung führen können. Für React Native Projekte empfiehlt es sich, Screenshots automatisiert über einen Emulator-Lauf zu erzeugen, damit sie nach jedem größeren UI-Update ohne manuellen Aufwand aktualisiert werden können.

// build.gradle (app module): versionCode must increase with every
// upload, versionName is the human-readable string shown in the listing
android {
    defaultConfig {
        applicationId "com.example.myapp"
        versionCode 42
        versionName "3.4.0"
    }
}

4. Content-Rating-Fragebogen (IARC) korrekt ausfüllen

Jeder Play Console Eintrag benötigt ein Content-Rating, das über den IARC-Fragebogen (International Age Rating Coalition) ermittelt wird. Der Fragebogen fragt unter anderem nach Gewaltdarstellungen, Nutzergenerierte Inhalte, Standortfreigabe und Kommunikationsfunktionen zwischen Nutzern ab. Für viele React Native Business- oder Utility-Apps fällt der Fragebogen kurz aus, doch Apps mit Chat-Funktionen, User-Generated-Content oder Standort-Sharing müssen diese Funktionen präzise angeben, da eine falsche Angabe später zu einer Neubewertung und in schweren Fällen zu einer Entfernung aus dem Store führen kann.

Wichtig für den Play Console Eintrag: Das Content-Rating muss neu ausgefüllt werden, sobald sich relevante App-Funktionen ändern, etwa wenn nachträglich eine Chat-Funktion oder ein In-App-Kaufsystem hinzugefügt wird. Google prüft diese Angaben nicht bei jedem Release automatisch neu, verlangt aber vom Entwickler, den Fragebogen proaktiv zu aktualisieren - ein Punkt, der in schnell iterierenden React-Native-Projekten leicht übersehen wird.

5. Data Safety: Angaben, die zur Realität passen müssen

Die Data-Safety-Sektion ist der Teil des Play Console Eintrags, der in der Praxis am häufigsten zu Problemen führt, weil sie exakt beschreiben muss, welche Daten die App sammelt, ob sie geteilt werden und zu welchem Zweck. Für React Native Apps ist das besonders anspruchsvoll, weil nicht nur der eigene Code, sondern auch jede eingebundene Bibliothek eigene Datenerfassung mitbringen kann - ein Analytics-SDK sendet möglicherweise Geräte-IDs, ein Crash-Reporting-Tool sammelt Stacktraces mit potenziell personenbezogenen Daten, ein Werbe-SDK verarbeitet Werbe-IDs zu Tracking-Zwecken.

Die Faustregel für einen sauberen Play Console Eintrag: Jede Bibliothek im `package.json`, die Netzwerkzugriffe durchführt, muss auf ihre Datenschutzerklärung geprüft werden, bevor die Data-Safety-Angaben final formuliert werden. Eine Diskrepanz zwischen deklariertem und tatsächlichem Verhalten fällt Google zunehmend durch automatisierte Netzwerkverkehr-Analysen auf und führt zu Nachbesserungsaufforderungen oder im Wiederholungsfall zu einer Sperrung des Entwicklerkontos.

{
  "data_safety_summary": {
    "collects_personal_info": true,
    "data_types": [
      { "type": "device_identifiers", "purpose": "analytics", "shared": false },
      { "type": "crash_logs", "purpose": "app_functionality", "shared": false },
      { "type": "approximate_location", "purpose": "app_functionality", "shared": false }
    ],
    "encrypted_in_transit": true,
    "user_can_request_deletion": true
  }
}

6. Weitere App-Content-Deklarationen

Neben Content-Rating und Data Safety verlangt der Play Console Eintrag weitere Deklarationen: die Zielgruppenangabe (Target Audience), eine Werbe-Deklaration, ob die App Werbung anzeigt, und gegebenenfalls Erklärungen zu Regierungsapps oder Finanzfunktionen. Richtet sich eine App auch an Kinder, greifen zusätzlich die strengeren Families-Policy-Regeln, die unter anderem den Einsatz bestimmter Werbe-SDKs und Tracking-Technologien einschränken.

Für React Native Apps mit In-App-Werbung ist die korrekte Werbe-Deklaration im Play Console Eintrag besonders wichtig, weil sie unmittelbar mit der Data-Safety-Sektion verknüpft ist: Wird Werbung deklariert, aber keine entsprechende Datenerfassung angegeben, oder umgekehrt, entsteht eine Inkonsistenz, die bei einer Überprüfung auffällt. Es empfiehlt sich, alle Deklarationen als zusammenhängendes Dokument zu pflegen, statt sie isoliert in verschiedenen Play-Console-Formularen auszufüllen.

7. Testing-Tracks und stufenweise Rollouts

Ein Play Console Eintrag muss nicht direkt in Production veröffentlicht werden. Google bietet drei Testing-Tracks: Internal Testing (bis zu 100 E-Mail-Adressen, sofortige Verfügbarkeit ohne Review), Closed Testing (größere, eingeladene Nutzergruppen, mit Review) und Open Testing (öffentlich über den Play Store zugänglich, mit Review). Seit 2023 verlangt Google für neue Entwicklerkonten sogar mindestens 20 aktive Closed-Testing-Tester über 14 Tage hinweg, bevor ein Produktions-Release überhaupt möglich ist.

Für die Production-Veröffentlichung selbst unterstützt der Play Console Eintrag stufenweise Rollouts: Eine neue Version wird zunächst nur an einen Prozentsatz der Nutzer ausgeliefert (z. B. 10 %), bevor sie schrittweise auf 100 % erhöht wird. Das ist besonders für React Native Apps wertvoll, weil sich native Regressionen, die im Testing nicht auffielen, so mit begrenztem Schaden erkennen und per Rollback stoppen lassen, bevor die gesamte Nutzerbasis betroffen ist.

# Trigger a staged rollout via the Google Play Developer API
# (percentage rollout of a specific release track)
curl -X PATCH \
  "https://androidpublisher.googleapis.com/androidpublisher/v3/applications/com.example.myapp/edits/EDIT_ID/tracks/production" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"releases":[{"status":"inProgress","userFraction":0.1}]}'

8. Play App Signing und Automatisierung mit eas submit

Seit August 2021 ist Play App Signing für neue Apps verpflichtend und damit ein fester Bestandteil jedes Play Console Eintrags. Entwickler laden ihre App mit einem Upload Key signiert hoch, Google signiert das finale Distributionspaket intern mit einem separaten, sicher verwahrten App Signing Key. Für React Native Projekte mit EAS übernimmt `eas submit` die komplette Interaktion mit der Play Developer API, inklusive Upload des Android App Bundles in den gewünschten Track.

Die Automatisierung über `eas submit` erfordert ein Service-Account-JSON aus der Google Cloud Console mit den Rechten "Release Manager" oder feingranularer zugewiesenen Berechtigungen. Dieses Setup muss nur einmal pro Projekt erfolgen und macht den Play Console Eintrag danach über CI-Pipelines vollständig steuerbar - inklusive automatischer Freigabe in Internal Testing bei jedem Merge in den Main-Branch.

{
  "submit": {
    "production": {
      "android": {
        "serviceAccountKeyPath": "./google-service-account.json",
        "track": "internal",
        "releaseStatus": "completed"
      }
    }
  }
}

9. Manuelle Einreichung vs. eas submit vs. Fastlane supply

Für die Pflege eines Play Console Eintrags über die Zeit stehen drei gängige Wege zur Verfügung, die sich in Automatisierungsgrad und Kontrolle unterscheiden. Die folgende Übersicht vergleicht die drei Ansätze entlang der praxisrelevanten Kriterien.

Für Expo-basierte React Native Projekte ist `eas submit` in Kombination mit einem sauber gepflegten Play Console Eintrag der Weg mit dem geringsten Wartungsaufwand. Teams, die auch die Store-Listing-Metadaten selbst versionieren und automatisiert synchronisieren wollen, profitieren zusätzlich von Fastlane `supply`, das Screenshots, Beschreibungen und Grafiken direkt aus dem Repository heraus aktualisieren kann.

10. Zusammenfassung

Ein vollständiger und gepflegter Play Console Eintrag besteht aus deutlich mehr Bausteinen, als die App-Anlage im ersten Moment vermuten lässt: Store-Listing, Content-Rating, Data Safety, App-Content-Deklarationen und Testing-Tracks müssen konsistent zueinander und zur tatsächlichen App passen. Gerade die Data-Safety-Sektion verdient bei React Native Apps besondere Aufmerksamkeit, weil eingebundene Third-Party-Bibliotheken eigene Datenverarbeitungen mitbringen, die im Play Console Eintrag korrekt deklariert werden müssen.

Wer den Play Console Eintrag als lebendiges Dokument behandelt, das bei jeder funktionalen Änderung der App überprüft wird, statt ihn einmalig auszufüllen und zu vergessen, vermeidet die meisten Policy-Konflikte. Automatisierung über `eas submit` oder Fastlane `supply` reduziert zusätzlich den manuellen Aufwand bei jeder neuen Version und macht Testing-Tracks sowie stufenweise Rollouts Teil eines reproduzierbaren Release-Prozesses.

11. FAQ: Play Console Eintrag für React Native Apps