In-App Account Deletion: The Rule That Sneaks Up On Most Devs

If your app allows users to create accounts, you must provide an in-app way to delete those accounts and the associated data. Not just a support email. Not just a deletion request form on your website. A button inside the app, reachable in a reasonable number of taps, that triggers actual data deletion. This rule has been enforced since 2023 and trips up a surprising number of apps with login flows.

Who the rule applies to

Any app where users can create accounts. The definition is broad: account creation includes traditional username/password signup, Sign in with Google, Sign in with Apple, Sign in with Facebook, magic-link email auth, SMS one-time codes, and any other flow that establishes a persistent server-side identity for the user.

Apps that don't have accounts at all (offline calculators, single-player games with no backend, utilities that store data only locally) are exempt. Apps where the only persistent identifier is a non-resettable device ID — i.e., apps that track users but don't let users authenticate — are technically exempt from this rule but have their own privacy issues to address.

What "in-app deletion" means in practice

The deletion control must be findable and usable inside the app, without leaving the app. Common implementations:

• A "Delete account" button in account settings.
• A "Manage account" section in the user profile menu with a deletion option.
• A confirmation flow — typing the word DELETE, entering the password, or otherwise demonstrating intent — before the deletion executes.

What does NOT satisfy the rule:

• A "Contact support to delete" message.
• A link that opens an external browser to a deletion form.
• A "Sign out" option without an associated deletion option.
• A flow that requires multiple confirmation emails or human review before executing the deletion.

What deletion actually has to do

Once the user confirms deletion, your backend must delete or anonymize the user's personally identifiable data within a reasonable timeframe — typically 30 days. The user's account record can be retained as a deleted-account stub for audit purposes, but identifiable data (name, email, profile content, message history) must go.

Exceptions: data you're legally required to retain (financial records, tax data, regulated-industry retention) can be kept and isolated. Data that's anonymized irreversibly (aggregated analytics, ML training data without identifiers) can be kept. Free-text content others rely on (comments on shared threads) can be reassigned to a generic "Deleted user" identity rather than removed wholesale.

External deletion paths

In addition to the in-app option, you must also provide an externally accessible deletion path — typically a web form linked from your privacy policy. This serves users who've uninstalled the app, lost device access, or want to verify deletion without reinstalling. The web form must accept account-identifying info and trigger the same backend deletion as the in-app button.

Account deletion in the Data Safety form

The Data Safety form has a specific question about deletion: "Do you provide a way for users to request that their data is deleted?" Answer yes only if both the in-app and external paths exist. Misreporting here triggers a re-review.

Common implementation mistakes

Even teams that build account deletion correctly often get it wrong in subtle ways:

• Auth-token only deletion. The delete button removes the user's session but doesn't actually trigger a backend delete. Reviewers test this by re-logging in with the same credentials after deletion and finding the account still works.
• Deletion that requires the user to be signed in but not verified. If your auth tokens have a long lifetime and never re-prompt for password, a stolen device can trigger account deletion by a malicious party. Re-authenticate before destructive actions.
• Race conditions. If your backend deletes user data but background jobs continue to process it (push notifications, scheduled emails), data leaks back into the user's lived experience after deletion.

How the wizard handles this

The Data Safety step (Step 7) asks whether your app allows account creation. If yes, it follows up with whether you have in-app account deletion. If you don't, the compliance check in Step 12 flags this as a blocker and links to this guide for implementation guidance.