The delete-account button both app stores require.

Adding sign-in to an app is an afternoon of work — drop in Firebase Auth or any of its rivals and you have accounts, sync, and a user ID to hang data on. The exit is the part nobody budgets for. Both stores now require that anyone who can create an account in your app can also destroy it — completely, from inside the app — and both check for it at review. Here's what the rules actually demand, and the order-of-operations trap that breaks most first implementations.

Apple's rule: deletion, not deactivation

The rule is App Store Review Guideline 5.1.1(v), enforced since June 30, 2022: if your app supports account creation, it must also let people initiate deletion of that account inside the app. Three details in Apple's guidance do the real work. The option has to be easy to find — a control buried three menus deep behind an unlabeled gear is the kind of thing reviewers flag. It has to be actual deletion: the account record and the personal data attached to it go away. Temporarily disabling or "deactivating" the account, the way large social networks famously do, explicitly doesn't count.

And if your app offers Sign in with Apple, deleting the account also means revoking the user's tokens through the Sign in with Apple REST API. That's a server-side call with a signed client secret — not something the client SDK does for you, and not something you'd guess was part of "add a delete button" until the rejection explains it.

The guideline applies to every submission, not just new apps. An app that shipped sign-in years ago and has been coasting is one bug-fix update away from meeting it.

Google's rule is the same, plus a URL

Google announced its version in April 2023 and phased it in through 2024, tied to the Data safety form in Play Console. It's the same core demand — an in-app way to delete the account and its data — with one addition that's easy to miss: you must also provide a web link where users can request deletion, and that link is published on your store listing's Data safety section.

The web link is the interesting half. It exists for the person who uninstalled your app eight months ago and only later remembers their data is still on your servers. They must be able to delete the account without reinstalling — which means you need a live page on a real domain where a signed-out user can start the process. If you've been putting off having any website at all, this is one of the quiet requirements that settles the question — we've written before about the small mandatory website every app ends up needing, and the deletion URL sits right next to the privacy policy on that list.

What "delete" actually means

Both rules are aimed at the same dodge: the flow that looks like deletion but just flips a disabled flag and keeps everything. What the stores expect is that the account record and its associated data genuinely go away. There are honest carve-outs — data you're legally required to retain (purchase records, fraud-prevention logs) can survive, and a short grace window ("your account will be permanently deleted in 14 days; sign back in to cancel") is acceptable, as long as you say clearly what happens and the deletion really lands afterwards. What doesn't fly: a flow that only signs the user out, or a consumer app whose only path is "email support and wait." Apple gives regulated industries some latitude for extra verification steps; a to-do app doesn't qualify.

The order-of-operations trap

Every Firebase developer writes the same first draft: a button that calls user.delete(). It passes your testing and fails in production, for two separate reasons.

The first is requires-recent-login. Firebase treats account deletion as a security-sensitive operation and refuses it when the user's last sign-in is too old. You always test the flow seconds after signing in, so you never see the error — your real user, whose session is six months old, hits it every time. The fix is to reauthenticate first: ask for the password again, or re-run the Google or Apple sign-in sheet. Done right, reauth doubles as your confirmation step — a cancelled sheet aborts the whole thing with nothing touched.

The second reason is bigger: deleting the auth user deletes nothing else. Every Firestore document and Storage file the account ever created stays exactly where it was, attached to a user ID that no longer exists — which fails the "account record and associated data" test outright. You have to cascade the deletion yourself, and the order matters more than it looks. Your security rules are (or should be) owner-only: request.auth.uid has to match the data's path. The moment the auth record dies, those rules lock everyone out — including your own cleanup code. Delete the user first and the orphaned data becomes undeletable from the client, permanently.

So the sequence that works runs backwards from the obvious one: reauthenticate, then purge cloud data while the user is still authenticated — Firestore in pages of batched writes (a batch caps at 500 operations), Storage by walking the folder tree, because the client SDK has no recursive delete — then local data, and the auth record dead last. Make each purge step best-effort: if one thumbnail fails to delete, log it and keep going, because the alternative is a half-deleted account stuck in a flow that errors forever. That's the exact sequence ShotCanvas ships in its own delete-account flow, and almost none of it was in the first draft.

The one thing the button can't do

Deleting an account does not cancel a subscription. If your user subscribed through the App Store or Google Play, the billing relationship is between them and the store — your servers were never part of it, and removing your account record doesn't touch it. Left unsaid, that's a customer paying every month for an app they can no longer sign in to. You can't fix it with code, so fix it with words: state it plainly in the confirmation dialog and point to the store's subscription settings. It's the difference between a compliant flow and an angry one-star review from someone you technically served correctly.