Kembo
BlogDocsSign in
Kembo

Mobile auth in minutes. Google and Apple sign-in for Expo, Flutter, Capacitor, and Web.

Product

  • Documentation
  • Blog
  • Pricing
  • Get started

Legal

  • Privacy Policy
  • Terms of Service
  • DPA
  • Data Deletion

© 2026 Kembo

Operated by ByteStronauts

← All posts
July 25, 2026·8 min read

Account deletion on the App Store and Google Play: what's required and how to comply

Both Apple and Google require apps with account sign-up to offer in-app account deletion — and reviewers reject builds that don't. Here is exactly what the policies demand, the traps that fail review, and how to implement deletion the right way.

account deletionApp StoreGoogle Playapp reviewGDPRcompliance

Here is a rejection that surprises teams every week: your app lets people create an account, but there is no way to delete one from inside the app. Both Apple and Google now require account deletion, and it is a hard gate — a polished, finished app gets bounced at review over a missing button.

The rule sounds simple, but the details are where builds fail. This post covers exactly what the App Store and Google Play require, the traps that get deletion flows rejected even when they exist, and how to implement it so it passes the first time.

What the policies actually say

Apple. If your app supports account creation, it must also let users initiate account deletion from within the app. Not just "deactivate," not "email support" — an in-app path that starts a real deletion. A web link alone is not enough on its own.

Google Play. Apps that let users create an account must provide a way to request deletion of the account and associated data, both in-app and via a web URL you list on your Play Console Data safety form, so a user can find it without installing the app.

The throughline: deletion must be reachable, must remove data (not just hide it), and must be obvious enough that a reviewer can find it in under a minute.

The traps that fail review

  1. Deletion buried too deep.Reviewers expect to find it in a reasonable place — typically account or profile settings. If it takes a treasure hunt, it reads as "not really there."
  2. Deactivate dressed up as delete. Temporarily disabling an account is not deletion. The policy means the account and its data go away.
  3. "Contact us to delete."Forcing the user through a support email or off-app form fails Apple's in-app requirement.
  4. No web URL for Google. You implemented in-app deletion but never added the public web deletion URL to the Data safety form.
  5. Deleting the device session only. Wiping local tokens is a sign-out, not a deletion. The server-side account has to go.

Sign out is not delete

The most common implementation bug: the "Delete account" button just clears local storage and returns to the login screen. The account still exists on your backend. Reviewers test this — they delete, then sign in again with the same credentials. If it still works, you are rejected.

What a correct deletion flow looks like

  • Findable.A clear "Delete account" entry in profile or account settings.
  • Confirmed. A confirmation step so it is not triggered by accident — but not so many hoops that it feels obstructive.
  • Real. It calls your backend to delete or irreversibly anonymize the account and personal data.
  • Honest about timing. If you have a grace period or need time to purge backups, say so clearly. A scheduled deletion is fine if it is disclosed.
  • Web-accessible (Android). A public URL where the same request can be made, listed on the Data safety form.

The data question behind the button

Deletion is not only a store rule — it overlaps with privacy law. Under the GDPR's right to erasure and similar regimes, users can demand their data be removed, and your deletion flow is how you honor that at scale. Two practical points:

  • Decide between hard delete and anonymization. You may need to keep some records (for example, financial receipts) for legal reasons — anonymizing the personal fields can satisfy both obligations.
  • Remember downstream copies: backups, analytics, third-party processors. A complete deletion accounts for those, not just the primary database row.

How Kembo makes deletion a non-event

Account deletion is tightly coupled to where identity lives — and that is exactly the part Kembo owns. Because Kembo manages your users, deleting one is a first-class operation rather than a feature you have to invent.

  • The SDK exposes a delete-the-current-useraction you can wire to a settings button — it removes the account server-side and clears the device session, so "delete" really deletes.
  • Project owners can also remove users from the Kembo dashboard, which is handy for honoring deletion requests that arrive by email or your web URL.
  • Because authentication and privacy-first analytics are deliberately separate and analytics is not tied to a person, deleting a user does not leave a trail of personal data scattered across your metrics.

Add the deletion entry the day you add sign-up

The cheapest time to build account deletion is when you build account creation — the screen, the confirm dialog, and the backend call are fresh in your mind. Bolting it on under review pressure is how the "sign out pretending to be delete" bug sneaks in.

One button, one less rejection

Account deletion is a small feature with outsized consequences: skip it and you cannot ship. Build it correctly — findable, confirmed, real, honest about timing, and web-accessible for Android — and it disappears as a concern forever.

If your users live in Kembo, deletion is already a built-in action rather than a project. Create a free Kembo project, wire the delete action to a settings button, and cross one more App Review gate off your list. Next week we shift to building: a practical guide to authentication in Expo.

Ready to skip the Wednesday OAuth panic? Create a free Kembo project.