In-app account deletion: what Apple and Google require, and how to build it

Apple's rule: guideline 5.1.1(v) and its support page

The guideline itself is one sentence: if your app supports account creation, you must also offer account deletion within the app. The detail lives on Apple's support page, "Offering account deletion in your app".

That page sets the bar higher than many teams expect. Deletion has to remove the account record along with its associated personal data. You may offer extra options, but offering only to deactivate or disable the account is not enough. The option should be easy to find, and Apple says it typically sits in account settings.

You may send people to your website to finish, as long as the app links directly to the deletion page. Apple's Human Interface Guidelines add a warning here: do not bury that link in the privacy policy or terms. Unless you are in a highly regulated industry, Apple says you should not make people phone you, email you or go through a chat support flow. Asking them to re-authenticate or enter a code sent to their email is fine. Making it unnecessarily difficult is not, and Apple says those apps will not pass review.

Google Play's rule: an in-app path and a web link

Google's Play Console Help page on account deletion covers apps where users can create an account, including apps where an account is optional for some features. The app needs a prominent in-app path, such as account settings, or a link to a web deletion resource.

The web resource is the part people miss. Every app with account creation has to enter a deletion link in the Data safety form, under the Data deletion questions on the App content page in Play Console. Google lists what that page must do.

• Load without errors.
• Make the deletion pathway prominent and easy to find.
• Name the app or developer exactly as it appears on the Play listing.
• Let users request deletion without going back to the app or reinstalling it.
• Describe any steps they must take first, such as cancelling a subscription, with a support flow available.
• If you point at an existing privacy policy, highlight the deletion section, for example with an anchor link.

The two stores compared, requirement by requirement

Build to the stricter answer in each row and one flow can serve both stores.

How I would build the deletion flow

Start on the server. A delete button that only signs the user out is the most common way I would expect this to fail review, and it also leaves you holding data you promised to remove.

This is the order I would build it in for a Flutter app with its own backend.

• Put "Delete account" in account settings, one tap from the profile screen, and use the same wording on the web page.
• Re-authenticate before deleting. Firebase Authentication throws a requires-recent-login error if the user signed in too long ago, so plan a fresh sign-in step rather than treating it as a bug.
• Show one confirmation screen that says what will be deleted, what you must keep by law, and how long it takes.
• Check for an active auto-renewable subscription. Apple says billing continues through Apple, so tell the user and ask them to cancel first. On iOS 15 and later, showManageSubscriptions opens the subscription screen inside the app.
• Delete on the server: the user row, profile data, uploaded files and user-generated content. Apple names photos, videos, text posts and reviews, including ones shared with others.
• If the account used Sign in with Apple, revoke the user's tokens through the Sign in with Apple REST API. Firebase's docs say it does not store those tokens, so the user must sign in again before you revoke and delete.
• Ask each service provider that holds the user's data to delete it too. Google's page says this explicitly.
• Send a confirmation when deletion is complete, as both Apple's support page and its Human Interface Guidelines ask.
• Publish the web request page and paste its URL into the Data safety form before you submit the Android build.

Cases that look compliant and are not

Region-only deletion is one. A flow built only for GDPR or CCPA users does not satisfy Apple, which says everyone should be able to delete their account wherever they are. If you already have such a flow, offer it to all users.

Scheduled deletion is another. You may let people schedule deletion for when their subscription ends, but Apple's page says only if there is also an option to delete immediately.

Then there are apps that sign people up through the browser. Apple says deletion must still be offered in the app. Accounts created silently for guests count as accounts too, and need a delete option.

Health and finance apps sit in a harder spot. They may need to keep records, and Apple allows extra customer service steps for highly regulated industries. I would get a lawyer to say what must be retained before writing the confirmation text, because that text is a promise to the user.

Where account deletion sits in my packages

All three of my packages include sign-up and login, so all three need deletion. I treat it as part of the login scope, not an extra. On Launch ($999) that usually means the in-app flow, re-authentication and removing the account from the auth provider. On Growth ($1,699) the app has its own Node.js backend and PostgreSQL database, so deletion also has to clear your tables and stored files. Scale ($2,500) adds an admin dashboard, which is a good place to see pending requests and any retained records.

Store submission help is in every package, and the Data safety deletion link is part of that submission. Specialised compliance work, such as retention rules for health or financial records, is quoted separately. Approval stays Apple's and Google's decision.