User Account Deletion Flow: The iOS App Store Rule

If your app lets a user create an account, Apple requires that the same app let them delete it, from inside the app. This is not optional and not satisfied by a deactivate toggle or a “email us to close your account” line. It is one of the more common late-stage App Review surprises, because teams build sign-up early and account deletion never. Here is what the rule actually says, the flow it expects, and a clean template to build from, a free VP0 design (the free iOS and React Native design library AI builders read from) at $0.

What the rule says

App Store Review Guideline 5.1.1 requires that apps supporting account creation also let users initiate account deletion within the app. Apple’s own guide to offering account deletion spells out the expectations: the deletion is of the account and its associated data, the entry point is in the app, and it is a real delete, not a hidden deactivate. The distinction matters:

Action	What happens to data	Satisfies the rule?
Deactivate / pause	Kept, restorable later	No, on its own
Email support to close	No in-app path	No
Delete account	Account and associated data removed	Yes

You can still offer deactivate as an option, but a genuine delete path has to exist and be reachable in the app.

The flow it expects

Four parts, kept honest:

First, a findable entry point, normally in account or privacy settings, reachable in a few taps. Second, a confirmation that states in plain language what will be removed and that it cannot be undone. Third, the actual deletion, your backend removes the account and associated personal data (this is the part a UI cannot do for you, so wire it to a real endpoint). Fourth, an honest result state confirming the account is gone. What you must not add is friction designed to stop people: a buried button, guilt-tripping copy, or a maze of screens. That is exactly the anti-pattern covered in account deletion and retention dark-pattern alternatives, and Apple’s Human Interface Guidelines push the same way toward clarity.

Regulated cases and edge handling

Some apps have genuine legal retention duties (finance, health) and cannot purge everything instantly. You can disclose that honestly, retain only what the law requires, and still delete the account and the rest; you can add a verification step for sensitive actions. What you cannot do is use those duties as an excuse to avoid deletion entirely. The same honesty applies to data your app collected through other features, like a background geolocation tracking history, which should be removed with the account, and the consent posture matches the GDPR consent banner for iOS apps. If your app handles payments, make sure deletion also addresses stored payment details, which ties into flows like the iDEAL payment bank selector UI.

The screen this required row lives on, with the persistence and grouping AI builders skip, is built in the SwiftUI settings page boilerplate.

Key takeaways

• If your app supports account creation, Apple requires in-app account deletion (guideline 5.1.1).
• Deactivate is not delete; a real deletion path must exist and be reachable in the app.
• The flow is entry point, confirmation, real backend deletion, and an honest result state.
• No dark patterns: do not hide the button or steer users away with manipulative copy.
• Build the flow from a free VP0 template at $0 and wire it to your real deletion endpoint.

Frequently asked questions

Does Apple require an account deletion option?

Yes. Under App Store Review Guideline 5.1.1, any app that supports account creation must also let users initiate account deletion from within the app. Offering only a way to deactivate, pause, or email support does not satisfy it. The deletion must remove the account and its associated data, and the entry point has to be in the app, commonly in account or privacy settings.

What is the difference between deactivating and deleting an account?

Deactivating suspends the account but keeps the data so it can be restored; deleting removes the account and its associated personal data. Apple’s rule is specifically about deletion, so an app that only offers deactivate does not comply. You can offer both, but a true delete path must exist and be reachable from inside the app.

Where should the delete account button go?

In a place the user can actually find, typically account settings or a privacy section, reachable in a few taps. Hiding it, requiring an email to support, or burying it behind unrelated screens works against the rule and reads as a dark pattern. Pair the button with a clear confirmation that states what will be removed.

Can I add steps before deleting an account?

You can add a confirmation and, for regulated apps with legal retention duties, a verification step or a link to complete certain requirements, but the deletion must still be initiated in the app and must genuinely delete the account. What you cannot do is make deletion effectively impossible or steer users away with manipulative copy. Keep retention disclosures honest and specific.

What is the best template for an account deletion flow on iOS?

One with a clear settings entry, a plain-language confirmation, and an honest result state, no dark patterns. A free VP0 design, the free iOS and React Native design library for AI builders, gives you that deletion flow to generate in Cursor or Claude Code at $0, which you wire to your real backend deletion endpoint.