Play Store Policies: Common Rejection Reasons for React Native Apps

1. Why Play Store policies are checked continuously

Unlike Apple, where review mostly happens before release, Google checks Play Store policies continuously, even after launch. Automated systems constantly analyze network traffic, requested permissions and app behavior against the declarations in the Play Console listing. For React Native apps this means: a policy violation that goes unnoticed at submission can still lead to removal weeks or months later once Google's automated analysis detects a mismatch.

A second difference from Apple: under the Play Store policies, a single bundled third-party library with questionable behavior is enough to classify the entire app as a policy violation, regardless of whether the development team was even aware of that behavior. The following sections walk through the rejection reasons most relevant to React Native teams in detail, from permissions through Data safety to handling a suspension.

2. Sensitive permissions and the Permissions Declaration Form

Sensitive permissions like location, SMS, and call logs are among the most tightly monitored areas of the Play Store policies. If a React Native app requests one of these permissions, Google requires, in addition to the technical declaration in the manifest, a completed Permissions Declaration Form in the Play Console listing that justifies the concrete benefit of the permission for the app's core functionality. If this justification is missing or seems implausible, it is one of the most common rejection reasons for apps with elevated access rights.

The Play Store policies additionally require the app to show users its own, understandable explanation before the actual system permission dialog appears, explaining why the permission is needed, so-called "in-context permission priming". For React Native teams using a library like `react-native-permissions`, the plain technical request is not enough; the UI must actively explain the context before the native dialog shows up.

{
  "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 mismatch: declared vs. actual behavior

Arguably the most common rejection reason under the Play Store policies for React Native apps arises from a mismatch between the declared Data safety section and the app's actual behavior. React Native projects frequently bundle multiple third-party SDKs for analytics, crash reporting, and push notifications, each collecting its own data: an analytics SDK may send device identifiers, a crash reporter transmits stack traces, and a push provider processes push tokens that could potentially be linked to user profiles.

Google increasingly detects such mismatches through automated analysis of the app's actual network traffic, comparing it against declared information. If a discrepancy is found, the Play Store policies first require a correction within a set deadline; ignoring it or repeat violations risk harsher consequences, up to suspending the entire developer account, not just the individual 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: the rolling minimum

As part of the Play Store policies, Google requires every new or updated app to meet a minimum `targetSdkVersion`, raised annually; apps falling below this minimum can neither be newly published nor updated. For React Native projects that have gone a while without updating to a newer Expo SDK or React Native version, this rolling minimum can quietly become a blocker, since `targetSdkVersion` implicitly depends on the underlying Android Gradle configuration.

A common rejection reason arises when a team maintains a React Native project for months without major dependency updates and then, at the next submission, is surprised to find the current `targetSdkVersion` already sits below Google's new minimum. Regularly updating the Expo SDK or React Native itself is the most reliable way to proactively avoid this problem, rather than having to rush a large version upgrade under time pressure right before an important submission.

{
  "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 and the Families policy

The Play Store policies on restricted content cover, among other things, depictions of violence, illegal activity, and misleading health claims, rarely relevant for most React Native business apps, but decisive for apps with user-generated content or community features. If an app is additionally marketed to children or clearly targets a young audience, the far stricter Families policy rules apply, fully excluding certain ad SDKs, tracking technologies, and external links.

A common mistake in React Native apps with a mixed audience: a generic analytics or ad SDK is bundled unchanged for every user, even though part of the audience falls under the Families policy. In that case, the Play Store policies require a technical separation of SDK configuration by age group, which in practice often needs a dedicated build flag or a remote config switch.

6. Deceptive behavior: obfuscated bundles and OTA updates

Deceptive Behavior is one of the more harshly sanctioned areas of the Play Store policies and covers app behavior designed to deceive either users or the Play Protect system. For React Native apps using OTA update mechanisms like EAS Update, extra care is warranted here: if an app dynamically loads executable code after installation, Play Protect may flag this as potentially harmful behavior if the mechanism is not implemented transparently or if the downloaded code is heavily obfuscated.

Legitimate OTA update systems like EAS Update are generally tolerated under the Play Store policies as long as they exclusively deliver JavaScript bundle updates within the already-approved native runtime environment and do not load any new native capabilities or permissions. Once that boundary is crossed, for example through a custom-built update system that loads entire native modules, the risk of being classified as Deceptive Behavior rises considerably.

7. App access: test credentials and video walkthroughs

The Play Store policies on app access require that Google reviewers can actually test every part of an app, including areas behind a login, a subscription, or a regional restriction. For React Native apps with authentication, this means providing a working test account with credentials in the Play Console listing, similar to Apple's App Review notes but through its own dedicated form in the "App access" section of Play Console.

If part of the app cannot be made accessible through a test account, for example because a feature is tied to a real payment transaction or a physical location, the Play Store policies instead require a video demonstrating the relevant flow. A common rejection reason arises when the provided test account exists but no longer works during review because of an expired test data environment or a changed password.

8. The appeal process and the policy status dashboard

If an app is rejected or removed for an alleged violation of the Play Store policies, the Policy Status dashboard in Play Console shows the exact reason, including the affected policy and, where possible, concrete examples from the reviewed build. This dashboard is the first place to check whether a rejection is based on an actual violation or a misunderstanding of the app's functionality.

For the appeal process, the rule is: the more concretely the submission is backed with screenshots, code references, or a clear explanation of the affected behavior, the faster the re-review turns out. For repeated or severe violations of the Play Store policies, such as Deceptive Behavior, the success rate of an appeal is low, which is why thorough prevention is far more economical than a dispute with Google after the fact.

9. Common rejection reasons at a glance

The following overview summarizes the Play Store policies covered in this article and their typical triggers, so it can be used as a checklist before every submission.

These five areas of the Play Store policies cover the majority of all React-Native-specific rejection reasons. Checking them systematically before every submission, and regularly after publication too, significantly reduces the risk of a later account suspension.

10. Summary

The Play Store policies differ from Apple's rulebook mainly in that review does not end with publication, it continues indefinitely. For React Native apps, sensitive permissions without a plausible justification, a Data safety section not backed by actual SDK behavior, and an outdated target API level are the most common rejection reasons. On top of that come Deceptive Behavior risks from non-transparent OTA updates and app access problems caused by stale test accounts.

The most effective protection against recurring problems with the Play Store policies is a regular internal review cycle that re-checks Data safety, permissions, and target API level not only before submission but also after every major dependency update. Establishing this check as a fixed part of the release process considerably reduces the risk of a sudden account suspension, an event that in the worst case affects every app under a developer account at once.

11. FAQ: Play Store Policies for React Native Apps