React Native: Creating and Maintaining a Play Console Listing

1. Why the Play Console listing is more than a formality

A Play Console listing covers far more than uploading an app binary. Google checks every submission, automatically and in part manually, to see whether the store listing, content rating and Data safety declarations match each other and the actual app. For React Native and Expo apps this is compounded by the fact that third-party libraries, for analytics, crash reporting, or push notifications, bring their own data processing that must be correctly declared in the Play Console listing even though it is not visible in your own JavaScript code.

An incomplete or inaccurate Play Console listing rarely leads to an immediate rejection, but it frequently causes follow-up questions, delayed releases, or later policy violations once Google spots a discrepancy between declared and actual behavior. The following sections walk through the entire path: from the initial app creation through the store listing and Data safety all the way to testing tracks and submission automation.

2. Creating the app in Play Console

The first step for every Play Console listing is creating the app in the Play Console dashboard under an existing developer account. This sets the app name, default language and the basic classification as an app or a game, and confirms the mandatory declarations about developer program policies and US export laws. The package name (e.g. `com.example.myapp`) is fixed at this point and cannot be changed afterward; it must exactly match the `applicationId` in the React Native or Expo configuration.

Right after creation, Play Console shows a checklist of open tasks that must be completed before the app can even go into internal testing. This checklist is the guiding thread for the rest of the Play Console listing: store listing, content rating, Data safety, app content declarations, and at least one active testing track must all be complete before a release is even possible.

# 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: title, descriptions and graphics

The store listing is the publicly visible part of the Play Console listing and consists of the app title (max 30 characters), a short description (max 80 characters, appears prominently in search results) and a full description (max 4000 characters). For React Native apps it pays to phrase the short description without jargon so it conveys the app's concrete value, since Google weighs this text heavily in Play Store search ranking.

For graphics, the Play Console listing requires at minimum an app icon (512x512px, PNG with alpha channel), a feature graphic (1024x500px) and at least two screenshots per supported device class (phone, 7-inch tablet, 10-inch tablet). Screenshots should reflect the app's actual state, since misleading screenshots violate the metadata policies and can lead to rejection. For React Native projects it is worth generating screenshots automatically from an emulator run, so they can be refreshed without manual effort after every major UI update.

// 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. Filling out the content rating questionnaire (IARC) correctly

Every Play Console listing requires a content rating, determined via the IARC questionnaire (International Age Rating Coalition). Among other things, the questionnaire asks about depictions of violence, user-generated content, location sharing, and communication features between users. For many React Native business or utility apps the questionnaire is brief, but apps with chat features, user-generated content or location sharing must answer these questions precisely, since an inaccurate answer can later trigger a re-rating and, in severe cases, removal from the store.

Important for the Play Console listing: the content rating must be redone whenever relevant app features change, for example when a chat feature or an in-app purchase system is added later. Google does not automatically re-check this on every release; instead it requires the developer to proactively update the questionnaire, a point that is easy to overlook in fast-iterating React Native projects.

5. Data safety: declarations that must match reality

The Data safety section is the part of the Play Console listing that causes the most problems in practice, because it must precisely describe what data the app collects, whether it is shared, and for what purpose. For React Native apps this is especially demanding, since not only your own code but every bundled library can bring its own data collection: an analytics SDK may send device identifiers, a crash reporting tool collects stack traces that can contain personal data, and an ad SDK processes advertising IDs for tracking purposes.

The rule of thumb for a clean Play Console listing: every library in `package.json` that performs network requests should be checked against its own privacy policy before finalizing the Data safety declarations. A mismatch between declared and actual behavior is increasingly caught by Google's automated network traffic analysis, triggering correction requests or, in repeated cases, a developer account suspension.

{
  "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. Additional app content declarations

Beyond content rating and Data safety, the Play Console listing requires further declarations: the target audience, an ads declaration stating whether the app shows advertising, and where relevant, statements about government apps or financial features. If an app also targets children, the stricter Families policy rules kick in as well, restricting the use of certain ad SDKs and tracking technologies among other things.

For React Native apps with in-app advertising, the correct ads declaration in the Play Console listing is especially important because it is directly linked to the Data safety section: if ads are declared but no corresponding data collection is stated, or vice versa, an inconsistency arises that stands out during review. It is worth maintaining all declarations as one coherent document rather than filling them out in isolation across different Play Console forms.

7. Testing tracks and staged rollouts

A Play Console listing does not need to go straight to production. Google offers three testing tracks: Internal Testing (up to 100 email addresses, instant availability without review), Closed Testing (larger, invited user groups, with review) and Open Testing (publicly accessible via the Play Store, with review). Since 2023, Google even requires new developer accounts to maintain at least 20 active closed testing testers for 14 days before a production release is possible at all.

For the production release itself, the Play Console listing supports staged rollouts: a new version is initially delivered to only a percentage of users (e.g. 10%) before gradually increasing to 100%. This is especially valuable for React Native apps, since native regressions that testing missed can be caught with limited blast radius and halted via rollback before the entire user base is affected.

# 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 and automation with eas submit

Since August 2021, Play App Signing has been mandatory for new apps and is therefore a fixed part of every Play Console listing. Developers upload their app signed with an upload key, and Google internally signs the final distribution package with a separate, securely stored app signing key. For React Native projects using EAS, `eas submit` handles the entire interaction with the Play Developer API, including uploading the Android App Bundle to the desired track.

Automation through `eas submit` requires a service account JSON from the Google Cloud Console with "Release Manager" rights or more finely scoped permissions. This setup only needs to happen once per project and then makes the Play Console listing fully controllable through CI pipelines, including automatic delivery to internal testing on every merge to the main branch.

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

9. Manual submission vs. eas submit vs. Fastlane supply

Maintaining a Play Console listing over time can follow three common paths, differing in automation level and control. The following overview compares the three approaches along the criteria that matter most in practice.

For Expo-based React Native projects, `eas submit` combined with a well-maintained Play Console listing is the path with the least maintenance overhead. Teams that also want to version and automatically sync store listing metadata itself benefit additionally from Fastlane `supply`, which can update screenshots, descriptions and graphics directly from the repository.

10. Summary

A complete and well-maintained Play Console listing consists of far more building blocks than app creation initially suggests: store listing, content rating, Data safety, app content declarations and testing tracks must all stay consistent with each other and with the actual app. The Data safety section in particular deserves special attention for React Native apps, since bundled third-party libraries bring their own data processing that must be correctly declared in the Play Console listing.

Anyone who treats the Play Console listing as a living document, reviewed with every functional change to the app rather than filled out once and forgotten, avoids most policy conflicts. Automation via `eas submit` or Fastlane `supply` further reduces the manual effort for every new version and makes testing tracks and staged rollouts part of a reproducible release process.

11. FAQ: Play Console Listing for React Native Apps