Account deletion on both stores
Two stores, two different requirements, and satisfying one does not satisfy the other.
Apple, Guideline 5.1.1(v): an app that supports account creation must let the user initiate deletion of the account from within the app. Not a support email, not a link out to a web form. In the app.
Google Play: additionally expects a route to request account and data deletion that is reachable without installing the app — a web-accessible URL you declare in Play Console.
So the complete answer is both: an in-app flow, and a web page, with the web URL declared to Play. Teams that build the in-app flow and stop get through Apple and then hit Play, usually at the worst moment.
What each store wants
| Apple | Google Play | |
|---|---|---|
| In-app deletion flow | Required | Expected |
| Web-accessible request route | Not required | Expected, and declared in Console |
| Deactivate-only | Not sufficient | Not sufficient |
| Support email only | Not sufficient | Not sufficient |
| Deletes associated data | Yes | Yes |
The patterns that get rejected
A link out to a web form. The most common failure on iOS. The requirement is that the app offers the path, and a link is pointing at one.
Deactivate dressed as delete. Offering to hide or disable an account when the user asked to delete it is exactly what the rule exists to prevent.
Deletion buried past a support flow. "Contact us to delete your account" is a support process, not a deletion feature.
A flow that fails silently. A button that appears to work and leaves the account intact is worse than no button, and it is the kind of thing a reviewer will actually test.
A declared Play URL that 404s. Test it from outside your network, logged out.
What good looks like
Findable. Settings or Account, one or two taps, not behind a submenu called something else.
Honest about consequences. What is deleted, what is retained and why, whether it is reversible, and what happens to an active subscription. That last point matters: deleting an account does not cancel an App Store subscription, and saying so prevents a real support problem and a real one-star review.
Actually deletes. Including on your backend, within whatever window your privacy policy states.
Mirrored on the web. A page that accepts a request from someone who no longer has the app installed, and a stated turnaround.
Documented in Review Notes. One line — "Profile → Settings → Delete account" — removes the possibility that a reviewer cannot find it. Review notes that work.
What a static check catches
Whether the app supports account creation at all — because if it does not, none of this applies. Whether a deletion path exists in the codebase, and whether it is reachable rather than orphaned. Whether the Play-declared deletion URL resolves. Whether the privacy policy mentions deletion and retention.
Those are deterministic and local. Whether your deletion flow is findable enough is judgement, and a reviewer decides it. shipcheck reports the first set before you build. What it checks.
Related
Guideline 5.1.1(v) in detail. · Google Play policy for RN apps. · The Data safety form.
More in this section
- App privacy labels: what gets checked, and how RN apps get them wrong
- Apple's required-manifest SDKs, mapped to npm packages
- Guideline 1.2: the four UGC requirements, and why AI apps trip it
- Guideline 1.4.1 — medical and health apps
- Guideline 2.1: app completeness
- Guideline 2.1, and what reviewers actually test
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 my app need in-app account deletion?
If it supports account creation, yes on iOS. App Store Guideline 5.1.1(v) requires apps that let people create an account to also let them initiate deletion of that account from within the app. A support email address is not sufficient on its own.
Is a link to a web page enough for Apple?
No. Apple expects the deletion to be initiated in the app. A link out to a form is the pattern that gets rejected, because the requirement is about the app offering the path rather than pointing at one.
What does Google Play require that Apple does not?
Play expects a way to request account and data deletion that is reachable without installing the app, which in practice means a web-accessible route you declare in Play Console. Apple's in-app requirement does not satisfy that on its own.
Does deleting an account have to delete all the data?
The user should be able to request deletion of the account and associated data. Some data may be retained where there is a genuine legal or record-keeping reason, and being clear in your privacy policy about what is retained and why is the honest way to handle it.
Does a temporary deactivation count?
No. Offering only a way to deactivate or hide an account, when the user asked to delete it, is the specific pattern the requirement exists to prevent.
shipcheck. “Account deletion on both stores.” Baker Ventures LLC, September 6, 2026. https://shipcheck.bakerventuresstudio.com/rejections/account-deletion-requirements/