What are the most common Google Play rejection reasons for React Native apps?

Data safety declarations that do not match what the app's SDKs actually collect, sensitive permissions such as background location without an approved Permissions Declaration, missing account and data deletion routes, and target API level, which blocks publishing outright rather than producing a review conversation.

Is Google Play review different from App Store review?

Structurally, yes. Apple's process is a human review that produces a cited guideline. Google mixes automated policy checks, some of which block the upload before any human sees it, with policy enforcement that can arrive after publication and can escalate to the developer account rather than just the app.

Google Play, for React Native and Expo apps

Updated September 6, 2026 · published by Baker Ventures LLC · sources cited inline

Play fails differently from the App Store, and the difference matters. Apple's process is a human review producing a cited guideline you can reply to. Google mixes automated checks that block an upload before any human sees it with policy enforcement that can arrive after publication — and that can escalate to the developer account rather than only the app.

The practical consequence: Play problems are less about persuasion and more about accuracy. A Data safety form that does not match your SDKs is not an argument you can win; it is a statement that is wrong.

The Data safety formWhy RN apps declare it wrong, the SDK-to-data-type map, and how to derive the form from the dependency tree instead of from memory. Target API levelBlocks publishing rather than triggering review. What raising it actually breaks, and why to do it early. Background locationPlay requires a Permissions Declaration with a demo video. The iOS and Android sides are two separate evidence bundles.

The four that catch React Native teams

Data safety that does not match the SDKs. Your declaration must cover the whole app including libraries. Firebase Analytics, Crashlytics, push providers and attribution SDKs all collect things you may never look at, and you are answerable for them. How to derive it properly.

Sensitive permissions without a declaration. ACCESS_BACKGROUND_LOCATION needs a Permissions Declaration in Play Console with a written justification and a demonstration video, and Google's expectation is that you use the least invasive option that satisfies the use case. A background-location request a foreground flow could satisfy is likely to be refused.

Account and data deletion. If your app allows account creation, Play expects a way to request account and data deletion — including a web-accessible route, not only an in-app one. This is a separate requirement from Apple's Guideline 5.1.1(v) and satisfying one does not satisfy the other.

Target API level. Annual deadline, blocks publishing, and raising it late is expensive because it opts you into that Android version's behaviour changes. Detail.

The merged manifest is where the surprises are

The AndroidManifest.xml that ships is not the one in your repository. It is the merge of yours with every library's, and it is where permissions you never declared appear.

find android -path '*intermediates*' -name 'AndroidManifest.xml' \
  | head -1 | xargs grep -E 'uses-permission|foregroundServiceType'

Every dangerous permission in that output needs either a Data safety row or a defensible reason it collects nothing. If you cannot account for one, that is the finding — and it is far cheaper to discover it here than in a policy notice.

Cite this page

shipcheck. “Google Play, for React Native and Expo apps.” Baker Ventures LLC, September 6, 2026. https://shipcheck.bakerventuresstudio.com/rejections/google-play/

Sources