Account Deletion Is a Store Requirement

If your app has accounts, both major stores now require a way to delete one. Google additionally requires that the route be reachable from outside the app — a web page, not only a button behind a login.

The reasoning is sound and worth understanding, because it shapes the implementation: somebody who has already uninstalled must still be able to ask. A deletion feature that requires the app is unavailable to exactly the person most likely to want it.

Most teams meet this at submission, treat it as a form to satisfy, and ship something that technically complies. The interesting problems are underneath.

Deleting an account is not deleting the data

These get conflated constantly and they are different obligations with different answers.

Deleting the account removes the ability to sign in and the profile associated with it.

Deleting the data is a broader question, and the honest answer is almost never “all of it”. Some records must be retained — a completed transaction has tax and consumer-law consequences that outlast a user’s relationship with you. Some cannot meaningfully be removed, because they have been aggregated into statistics that no longer contain individual records.

Both stores accept this. What they do not accept is silence about it. The requirement is that you tell the user what is deleted, what is retained, and for how long — not that you delete everything.

Which makes the hard part a documentation exercise rather than an engineering one. Somebody has to go through every system holding user data and decide, per category, what happens on a deletion request. That list rarely exists before this work forces it.

The three implementations, and what each costs

Immediate hard delete. The request removes the records. Cleanest to explain, and it has two failure modes: a user who deletes by mistake has no recourse, and anything you were legally required to keep is gone.

Soft delete with a grace period. The account is disabled immediately and purged after a stated interval — commonly 14 or 30 days. Most businesses land here. It handles the mistake case and gives your systems time to propagate. It must be disclosed: “deleted immediately” is false if the data sits for a month.

Anonymisation. Personal identifiers are removed and the transactional record is retained without them. Correct where you have a genuine retention obligation, and it only works if the result is truly not re-identifiable — a record with a name removed but an email address and a delivery address intact is not anonymised.

★ Insight ------------------------------------- The implementation that causes trouble later is the one that deletes from the primary database and nowhere else. User data has usually also reached a CRM, an email platform, an analytics tool, a support system and a backup. A deletion that covers only the first is accurate about the database and false in the policy, and the policy is the document a regulator reads. The useful artefact is a map of every destination user data reaches — which is the same list an incident would demand. -------------------------------------------------

The backup problem, stated honestly

Backups contain deleted users. Every business’s do.

You cannot practically excise one record from an encrypted nightly archive going back ninety days, and no regulator seriously expects it. The accepted position is that deleted data may persist in backups until those backups expire on their normal cycle, and that it will not be restored into production.

What matters is that this is stated, with the retention period named. “Your data is removed from our systems immediately, and may persist in secure backups for up to 90 days, after which it is permanently destroyed” is honest and defensible. Claiming immediate and total removal is a claim your own backup schedule contradicts.

The web page

For the Google requirement specifically, a public page that:

• Is reachable without signing in and without the app installed
• Explains how to request deletion, with a form or an email address that is monitored
• States what is deleted, what is retained, and for how long
• Links from your store listing and your privacy policy

One thing worth checking, which we got wrong on our own pages: if your site has a release gate that checks legal pages, make sure this one is on the list. Ours held a hardcoded set of pages, so a page added later was outside it entirely — and could have gone live in a state the gate exists to prevent.

What to say when someone asks

The request itself is usually straightforward and the reply is where businesses get uncomfortable, because the honest answer is more complicated than “done”.

A reply that works:

We have deleted your account and the personal information associated with it. Some records are retained where we are required to keep them — transaction records for tax purposes, kept for the period the law requires. Your data may remain in encrypted backups for up to 90 days, after which those backups expire and are destroyed. We will not restore it.

Three properties make that a good reply. It confirms the action. It states the exceptions with reasons rather than hiding them. And it gives a real number for the backup period rather than an evasion.

The reply people regret sending is the one that claims total immediate erasure, because it is contradicted by the backup schedule and by the tax records, and a customer who later discovers either has been misled by a sentence nobody needed to write.

Before you submit

• The deletion route works from a browser, not logged in, on a phone.
• The page states what is deleted, what is retained, and the retention period.
• Every system holding user data is on the list, not just the database.
• Backup persistence is disclosed with a real number.
• Someone monitors the address or form the request goes to.
• The store declaration’s deletion answer matches what the page says.

The last one is the mismatch that gets found later, because the declaration is checked automatically and the page is read by people.

---

Awesome Apps is an app developer in Sydney building and publishing iOS and Android apps for Australian businesses. General information about store policy, not legal advice.