How do I clear an App Store 5.1.1 account deletion rejection?

If your TestFlight or production submission came back with a Guideline 5.1.1 message about account deletion, the reviewer almost certainly opened your settings screen, looked for a Delete Account row, and could not find one. The fix is more specific than people assume, and a few details (Sign in with Apple token revocation, subscription warnings, user-generated content) turn this from a one-line ticket into a multi-day task.

Short answer

Guideline 5.1.1(v) requires that any app supporting account creation also offers account deletion from inside the app. According to Apple's support page on offering account deletion, the delete path has to remove the account record and the personal data tied to it, must be easy to find (typically in Settings), and cannot be replaced by a temporary deactivation. Apps using Sign in with Apple have to call the Sign in with Apple revoke endpoint. The requirement has been live for every new and updated app since June 30, 2022, and reviewers continue to enforce it in 2026.

What you should know

• The rule applies if the user can sign up, period. It does not matter whether the account is mandatory, optional, or auto-created as a guest record. If a user can create one, you must let them delete one.
• Deactivation, suspension, or disable does not count. Apple's account deletion support page calls out temporary deactivation specifically and says it is not enough.
• The delete control has to live in the app. Sending users to an email address, a help center page, or a generic privacy page fails the gate.
• Sign in with Apple has its own revoke step. If you offered Sign in with Apple, the deletion flow has to revoke the refresh token through the documented REST endpoint.
• Subscriptions are a separate billing relationship. Deleting the account does not cancel an active App Store subscription; the user has to be warned and pointed to subscription management.
• A delay is fine, opacity is not. Scheduled or manual deletion is allowed as long as the user sees the timeline and gets a confirmation.
• Highly regulated industries get a narrow exception. Banking, healthcare, gambling, legal cannabis, air travel, and crypto exchanges may add support flows under Guideline 5.1.1(ix).

What does Guideline 5.1.1(v) literally say?

The text of Guideline 5.1.1(v) in Apple's App Review Guidelines says: "If your app supports account creation, you must also offer account deletion within the app." The guideline points to a dedicated support page for the detail of what counts as offering deletion. That support page is the operational specification reviewers work from, and it is the document the resolution will be measured against.

The key parts of the support page are short. The option has to be easy to find, usually in account settings. The delete action has to remove the account record and the personal data Apple expects to be tied to that account, including user-generated content shared with others, such as photos, videos, text posts, and reviews. Temporary deactivation is explicitly called out as insufficient. The flow has to be available to every user globally, not just users in jurisdictions with deletion rights laws.

The rule went into effect on June 30, 2022 after Apple extended an earlier January 31, 2022 deadline, as documented in the Apple Developer Newsroom announcement. The requirement is now baseline. A new account creation feature added in a 2026 update is treated the same as one shipped years ago.

Why did Apple reject my build when I do have a delete page?

The Resolution Center notice for 5.1.1(v) usually quotes one of three patterns. The first pattern is that the app provides no path at all. The second pattern is that the path exists but is buried (only inside a Help center web view, or only inside a Privacy submenu the user has to scroll through). The third pattern, which trips up the most teams, is that the path exists but only leads to a support email, a contact form, or a deactivation toggle.

Reviewers usually open the Settings tab, scroll for a labeled row containing the word Delete or Close Account, and tap through. If the tap leads to a screen that says Email [email protected] to close your account, the reviewer flags the build. Patterns reported by developers on the Apple Developer Forums thread on 5.1.1(v) account deletion match this behavior closely. Sending a Help center link, even one with deletion instructions, is treated as not offering deletion in the app.

A second common rejection pattern is that the deletion path works only when the user is signed in through your primary provider but breaks for users who came through Sign in with Apple. The reviewer will create a test account through Sign in with Apple, attempt deletion, and reject the build if the flow errors out, never returns, or fails to remove the Apple account link.

What does a compliant deletion flow actually look like?

The pattern reviewers consistently accept has the following shape. A row in Settings reads Delete Account or Close Account. Tapping it opens a screen that explains, in plain language, what will be removed, how long it will take, and what happens to subscriptions. A confirmation step requires the user to type a phrase or re-enter their password. The action runs and either deletes the data on the spot or schedules it. The user sees a confirmation message and is signed out.

The table below maps each ingredient to the part of Apple's support page that drives it.

A last detail that matters: Apple lets you keep data you are legally required to retain, such as tax records or fraud history. That carve-out is narrow, and the user-facing copy has to be honest about it. Vague phrases like retain data for legitimate business interests do not survive a careful review.

How do I revoke Sign in with Apple tokens during deletion?

If your app offered Sign in with Apple at any point, the deletion flow has to call Apple's revoke endpoint with the user's refresh token. According to Apple's revoke tokens documentation, the call is a POST to https://appleid.apple.com/auth/revoke with client_id, client_secret, token, and token_type_hint=refresh_token in the form body. The client_secret is a short-lived JWT signed with the Sign in with Apple private key Apple issued when you set up the capability.

The revoke call has to succeed before the local account record is removed. If you delete the database row first and then fail the revoke, you have no way to retry; the refresh token is gone from your side and the Apple ID still has your app linked. Reviewers are not deep enough to test this case directly, but a stale Apple ID link surfaces months later when the user tries to sign in again and sees stale data, which becomes a separate support burden.

For builders working with no-code or AI-coded stacks where the auth layer is generated (FlutterFlow, Bubble, Lovable, Cursor, Claude Code), the deletion flow is typically the part of the auth scaffold that is missing. Adding it manually is a few hours of work plus a server-side function to handle the revoke call, which cannot run in the client because the client_secret would have to be embedded.

What edge cases trip up developers on the resubmission?

Four edge cases show up in roughly that order on Resolution Center threads.

The first is subscription billing. The user deletes the in-app account, the app removes the row, and the auto-renewable subscription keeps charging through Apple because the App Store relationship is separate. Apple wants you to notify users that billing continues unless they cancel separately, and to point them at subscription management, ideally with showManageSubscription() on iOS 15 and later or the App Store subscriptions URL https://apps.apple.com/account/subscriptions.

The second is guest accounts. If your app creates a guest record automatically (say, to save preferences before sign-up), that record is an account in Apple's eyes, and the deletion flow has to cover it. A device reset button is a reasonable answer; a hidden silent record is not.

The third is shared user-generated content. If a user posted public reviews, comments, or photos under their account, the support page explicitly lists those as data that has to be removed with the account, unless the user can choose to keep them anonymized. Apps with social features have to think carefully about this, because removing every post on deletion can break threads and other users' feeds. A workable pattern is to anonymize the author handle, replace the avatar with a generic placeholder, and keep the post body if it is part of a shared conversation, with clear copy in the deletion confirmation.

The fourth is web-account apps. Some apps create accounts only on the web and let users sign in through a browser flow. Apple's account deletion support page is explicit: those apps still have to offer deletion inside the app, even if the actual record lives in a web database. A direct link to a completion page on your site is allowed, but the user must be able to finish the action without follow-up steps. A link to a generic privacy page fails.

For compiled iOS builds where the auth surface was generated by an AI tool, scanning the IPA against OWASP MASVS authentication controls catches missing capabilities and broken Sign in with Apple wiring before the build reaches App Review. PTKD.com (https://ptkd.com) is one of the platforms focused on that kind of pre-submission read for builders shipping through App Store Connect.

What to watch out for

• A deactivate switch that hides the account. Apple's support page calls this out by name. Suspend, deactivate, and freeze are not deletion.
• A Settings entry that opens Safari to a contact form. The action has to complete inside the app or via a direct link to a completion page, not a generic privacy page.
• Deleting the database row before the Sign in with Apple revoke. Sequence the revoke first; only commit the local deletion once the Apple side has succeeded.
• No subscription warning copy. If billing continues through Apple after the account is gone, the user has to be told, with a way to manage the subscription.
• Treating the regulated-industry exception as broad. Guideline 5.1.1(ix) names a short list of regulated fields. Productivity, social, fitness, and consumer apps do not qualify, even if they collect identity data.
• Forgetting guest accounts created silently. A pref store keyed to a server-side anonymous ID is an account in Apple's reading; the delete path has to cover it.
• The myth that GDPR or CCPA implementation alone clears the rejection. A web form for European users does not satisfy 5.1.1(v); the action has to be available in the app to every user globally.

Key takeaways

• Guideline 5.1.1(v) requires an in-app delete path for any app that supports account creation, with a discoverable entry point, no support-only flow, and removal of the account record plus the personal data attached to it.
• A deactivate or disable option does not satisfy the rule, and the regulated-industry exception in 5.1.1(ix) covers only a short list of fields.
• Sign in with Apple deletions have to revoke the refresh token through Apple's REST endpoint before the local account record is removed, otherwise the Apple ID still shows the app linked.
• Subscriptions are a separate billing channel; the deletion flow has to warn users that App Store billing continues unless the subscription is canceled, ideally with a direct link to subscription management.
• For teams shipping iOS builds produced by AI tools or no-code builders where the auth scaffold is generated, scanning the compiled IPA against OWASP MASVS using a platform such as PTKD.com (https://ptkd.com) catches the missing delete path, the absent Sign in with Apple revoke call, and the silent guest-account record before App Review flags them.