Play's account deletion requirement
Two things are required, and teams reliably ship one.
1. An in-app path to request account and data deletion. This is the half everyone builds, because Apple requires it too. Apple's 5.1.1(v).
2. A publicly reachable web URL, declared in Play Console, that someone can use without the app installed. This is the half that gets missed, because Apple does not ask for it, nothing in the binary reveals its absence, and it lives in a Console form rather than in code.
Where it bites: Play Console, as a release-blocking declaration item rather than a message from a reviewer. It stops the release; it does not start a conversation.
Two details that catch people on the URL:
It must be findable without the app. Authenticating on the page to confirm who you are is normal. Requiring the app in order to reach the page defeats the purpose, since the people most likely to need it have already uninstalled.
It must say what actually happens. What is deleted, what is retained, why, and for how long. Retention for legal or fraud-prevention reasons is normal and should be stated rather than left implicit, because an unexplained "some data may be kept" is the version that draws questions.
Building the web page
It is a page, not a product. What it needs:
Title: Delete your [App] account
1. What deleting does: which account and which data are removed.
2. What is kept, why, and for how long. Be specific.
3. How to request it:
- In the app: Settings > Account > Delete account
- Or here: [form, or an email address that is monitored]
4. How long it takes, and what confirmation the user gets.
5. Who to contact if it does not happen.Step two is the one to write honestly. Transaction records kept for accounting, logs kept for a fixed period, anonymised analytics that cannot be tied back. Saying so is better than a blanket claim that everything disappears, which is usually not true and is checkable.
An email address is acceptable if it is genuinely monitored. An address that bounces is worse than no address, because it is trivially testable.
The in-app path
Reachable without support. A control in Settings, not an instruction to email.
Not buried. A path a user can find in under a minute.
Clear about consequences, before the destructive action.
Actually working. Test it end to end on a real account: the account should be gone, and signing in again should behave as a new user rather than restoring everything. A deletion that leaves the data recoverable on next login is the most common implementation bug in this feature, and it fails on both stores.
Where it appears in Console
The declaration sits with the app content and Data safety sections, and it interacts with them: your Data safety answers describe what you collect, and the deletion path describes how someone gets rid of it. The two should tell the same story.
A mismatch between them is the pattern Play's automated checks are looking for, and it is why filling the Data safety form from memory rather than from the dependency tree causes trouble downstream. Play Data safety.
The pre-submission check
# in-app deletion exists at all
grep -rniE 'delete (my )?account|deleteAccount|account deletion' src app --include=*.tsx --include=*.ts | head
# and it is not just a mailto
grep -rniE 'mailto:.*delet|contact us to delete' src app | head
# is the public URL live right now
curl -s -o /dev/null -w '%{http_code}\n' https://yoursite.example/delete-accountRun the third one on the day you submit. A URL that was live when you declared it and 404s now is a release-blocking item you will not see coming.
Where it sits among the other Play gates
| Requirement | What blocks |
|---|---|
| Account deletion | Release, as a declaration item |
| Data safety form | Release, when it mismatches behaviour |
| Permissions declaration | Publishing, until approved |
| Target API level | Updating below the floor |
| Foreground service types | Release |
| Closed testing | Production access for new personal accounts |
All six are decided by forms and automated checks rather than by a person reading your app, which is the structural difference between Play and App Review and the reason "we explained it in the notes" does not help here. Google Play rejections. · After a rejection.
shipcheck reports whether an in-app deletion path exists in the shipped UI and flags an app with account creation and no deletion route, citing both stores' requirements. It cannot check whether your declared URL is live, and it says so. What it checks.
More in this section
About shipcheck
shipcheck is a pre-submission checker from Baker Ventures LLC that runs inside Claude Code. It reads your React Native or Expo project, finds the things that get apps rejected or blocked at upload, cites the exact App Store Review Guideline or Google Play policy clause, and names the file and line to fix.
It exists because React Native and Expo apps fail for reasons that are invisible in the code you wrote: capability arriving through a dependency, purpose strings added by a config plugin, a privacy manifest missing from an SDK you never chose directly, and a generated ios/ directory that discards your edits on the next prebuild. shipcheck checks what the binary and the config actually declare, not what you intended. The rejection references on this site are free, need no account, and link to the primary Apple or Google document for every claim.
Questions and answers
Does Google Play require account deletion?
Apps that let users create an account must provide a way to request account and data deletion, both inside the app and through a publicly available web link declared in Play Console. The web URL is the part teams most often miss because Apple does not require one.
What is the difference between Apple's and Google's account deletion rules?
Apple's Guideline 5.1.1(v) requires deletion to be initiable inside the app. Google additionally requires a web-accessible URL that anyone can reach without installing the app, and it is declared in the Console rather than living in the binary.
Does the deletion URL have to work without logging in?
It has to be publicly reachable, meaning someone who no longer has the app can find and use it. Authenticating on that page to confirm identity is normal; requiring the app in order to reach the page is not.
Do I have to delete everything immediately?
The requirement is about providing the path and being clear about what is deleted, what is retained and for how long. Retention for legal or fraud-prevention reasons is normal and should be stated rather than left implicit.
What if the app has no accounts at all?
Then the requirement does not apply. The moment you add any form of sign-in, including social login, it does, and that is the release where it gets missed.
Where does this get caught?
In Play Console, as a release-blocking item on the Data safety or app content declarations, rather than as a message from a human reviewer. It stops the release rather than producing a conversation.
shipcheck. “Play's account deletion requirement.” Baker Ventures LLC, September 7, 2026. https://shipcheck.bakerventuresstudio.com/rejections/play-account-deletion-requirement/