Add Account Deletion to Pass App Review

What the guideline actually requires

Guideline 5.1.1(v) says that apps supporting account creation must also let users initiate deletion of their account from within the app. Read that carefully, because the details are where rejections live.

• In-app, not off-app. The user must be able to start the deletion inside your app. Kicking them to a website or a support email does not satisfy the rule for apps outside highly regulated industries.
• Delete, not disable. Temporarily deactivating or suspending an account is explicitly not enough. The account and its personal data have to go.
• Findable. The option needs to be easy to locate. Reviewers look for it, and if they cannot find it quickly, you get bounced.
• The narrow exception. Apps in highly regulated industries, under 5.1.1(ix), may add a customer-service confirmation step. If that is not you, do not add friction like a mandatory phone call.

Verified against Apple's current developer guidance, July 2026.

Why Apple cares about this at all

It helps to understand the intent, because it tells you when the rule bites. The principle is simple: if a user can create an account and hand you their data, they must be able to take it back and leave, from the same app, without jumping through a support gauntlet. Deactivation fails that test because the data is still yours. A support-only flow fails it because the user is now negotiating with you to exercise a right they already have. The rule exists to make leaving as easy as joining. Once you see it that way, the implementation details below stop feeling arbitrary and start feeling obvious.

What we shipped, honestly

When Apple rejected our app under 5.1.1, one half of it was this: we had signup but no way to delete an account. Here is exactly what we did to fix it, told straight, because the honest version is more useful than a perfect-world version.

We added a delete-account action to the app's account hub, the screen where a user manages their profile. When invoked, it deletes the user's profile record from our database. That profile row is the anchor for the user's data, and related records are removed with it through database constraints. Then it signs the user out. We shipped this as build 62, resubmitted, and the listing went live.

That cleared review. It is also worth being precise about scope, because you deserve the real picture: our fix deleted the user's profile and associated data and signed them out. A more complete implementation also deletes the underlying authentication record server-side, and if you offer Sign in with Apple, revokes the Apple tokens (more on that below). If you are building this now, build the complete version. We are telling you what passed and what a fuller version looks like, not dressing up the smaller one.

The complete, do-it-right implementation

Here is the version to build if you are starting fresh. It has three parts.

1. A findable, confirmed UI action

Put a "Delete account" control in account settings or a profile hub. Do not hide it. Because deletion is destructive, gate it behind a confirmation step so nobody triggers it by accident, a confirmation dialog, or a typed confirmation for extra safety. Keep the copy plain: tell the user their account and data will be permanently deleted.

2. Actually delete the data, server-side

The client can start the deletion, but the real removal should happen with proper authority on the server, not only from the app. The robust pattern is a server function that runs with a service role and:

• deletes the user's profile and all records tied to it,
• deletes the authentication user itself so the login no longer exists,
• and returns a clean success so the app can confirm to the user.

Doing it server-side matters because a client alone often cannot delete the underlying auth user for security reasons. A small backend function with a service role closes that gap. Cascading database constraints keep you from missing related tables.

3. Revoke Sign in with Apple tokens

If your app offers Sign in with Apple, there is an extra step, and reviewers increasingly check for it. When a user deletes their account, call the Sign in with Apple REST API token revocation endpoint to revoke their tokens. This fully disconnects your app from the user's Apple ID, which is the whole intent of deletion. Skipping it leaves a dangling connection and can cost you a rejection even when the rest of your delete flow is fine.

4. Map every place the user's data lives

Deletion is only honest if it is complete. Before you ship, list every table, bucket, and outside service that holds something tied to the user: their profile, the content they generated, uploaded files, analytics identifiers, and any record held by a payment provider. Database cascade rules handle the tables that reference the user, but files in storage and data mirrored into other services are often not covered by a cascade. Delete those explicitly, or you will have told the user their data is gone while a copy sits in a storage bucket. That gap is both a broken promise and a future privacy complaint.

5. Confirm, then confirm the result

Because deletion cannot be undone, gate it behind a clear confirmation, and once it runs, tell the user plainly that the account is gone and return them to a signed-out state. A silent success looks like a bug, and a user who is not sure whether their delete worked will email support or leave a one-star review. Close the loop on screen.

Google Play requires the same thing, plus a web link

This is not only an Apple rule. Google Play's User Data policy requires the same in-app account deletion, and it adds a twist Apple does not have. If your app allows account creation, Google requires you to:

• provide an in-app path to delete the account and its associated data, and
• provide a web link, listed in your Play Console Data safety form, where a user can request account and data deletion without installing or reopening the app.

That web deletion link is the part iOS-first builders forget. Google wants it in the Data safety section, and a missing or invalid link there is its own enforcement flag. Google moved this to full enforcement on April 15, 2024, and non-compliant apps can be removed from Google Play. Verified July 2026.

Both stores allow a sane retention exception: you may keep specific data when you have a legitimate reason, such as security, fraud prevention, or a regulatory obligation. Keep only what you can defend, and say what you keep and why in your privacy policy.

The practical upshot is that one piece of work covers both stores. Build the delete flow once, wire it to a server function that removes the data, expose an in-app entry point to satisfy Apple, and publish a web request page to satisfy Google. Do not build it twice.

The checklist reviewers effectively run

Before you submit, walk this:

1. Can a user find the delete option without hunting? Settings or profile hub, plainly labeled.
2. Does it delete, not just deactivate? The account and personal data are gone.
3. Is it fully in-app? No forced email or phone call, unless you are a regulated industry.
4. Is it confirmed? A destructive action should not fire on a single accidental tap.
5. Are Sign in with Apple tokens revoked, if you use it?
6. Does the auth record itself get removed, server-side, not just the profile row?

Hit all six and this rejection line never touches you.

Test your own delete before review does

Before you submit, run the delete end to end on a real account and then check that the data is actually gone. Create a throwaway account, add some data, delete it, and then look: is the profile row gone, are the related records gone, is any uploaded file gone from storage, can the same login still get in? A delete that leaves a working login or an orphaned row will either fail review or surface later as a complaint. The two minutes it takes to verify is cheaper than a rejection round or an angry email. Treat the delete like any other feature: it is not done until you have watched it work.

Why this is worth doing well, not just doing

Two reasons beyond passing review. First, it is the law-adjacent right thing: people are entitled to leave and take their data with them, and a clean delete builds the trust that keeps the rest of your users. Second, a half-built delete that leaves auth records or Apple tokens behind can pass one review and fail the next, or surface as a privacy complaint later. Build the complete version once.

There is also a maintenance argument. Account deletion is the kind of feature that quietly rots if you build it halfway, because every new table you add later needs to be wired into the delete path, and a partial delete gets more partial over time. If you build it complete and centralize the deletion in one server function, adding a new data type later is a one-line addition to that function rather than a forgotten gap that becomes tomorrow's rejection. Do the whole thing once and it stays done.

Before you build the account system at all

Account deletion is downstream of having accounts, which is downstream of having an app worth signing into. If you are still at the idea stage, it is worth making sure the concept is worth all this plumbing. Our generator grades an idea against real market signals and returns a build-ready blueprint, so you build the right thing before you wire the details: generate and grade an idea free.

Back to the path: this is the fix that cleared half our rejection. The other half, and the full list of what review bounces, is in why apps get rejected in 2026. If your app touches a model, read how to get an AI app approved by Apple next, and the whole journey lives in how to ship an app in 2026.