App Store Compliance

Designing your iOS account deletion flow for App Store Guideline 5.1.1(v)

What Apple actually requires for account deletion since June 2022 — the in-app path, the public URL, the Sign in with Apple revoke step, and the subscription cancel chain that catches every team off guard.

· 9 min read

If you’re shipping an iOS app that creates user accounts, App Store Review Guideline 5.1.1(v) applies to you. Since June 30, 2022, Apple requires that any app supporting account creation must also support account deletion — initiated from within the app itself, not just by emailing support.

What Apple’s guideline doesn’t say is how strict App Review actually is about it. After helping a lot of teams ship deletion flows, the rejections cluster around five mistakes. This post is a checklist for designing the deletion flow once and not getting bounced.

What Guideline 5.1.1(v) actually requires

Apple’s official account deletion support page spells it out:

  1. Account deletion must be initiated from within the app. An email link or a “contact us” page is not enough — there must be a UI button.
  2. The deletion must offer to delete the entire account record along with associated personal data. Deactivation alone (where the data is preserved but the account is suspended) is not sufficient.
  3. The option must be easy to find. Buried under three menu levels with a different label gets flagged.
  4. Apps that “make it unnecessarily difficult” — extra confirmation friction, dark patterns, mandatory phone calls — fail review.
  5. If your app offers Sign in with Apple, deletion must also revoke the user’s auth token via Apple’s REST API.

App Store Connect also has a separate optional field — User Privacy Choices URL — for a public web page documenting your deletion process. This is the deletion URL most third-party generators talk about. It’s optional but strongly recommended; App Review uses it as a reference, and search engines surface it for users who can’t access your app.

Mistake 1: Hiding the deletion button

The classic version: a “Delete Account” link buried under Settings → Account → Privacy → Manage My Data → Advanced Options → “Delete account.”

Apple’s actual standard is one or two taps from the main account settings. Common safe patterns:

  • Top-level Settings tab with Delete Account as a row near the bottom of the account section, separated from the rest of the settings.
  • Profile screen with a clearly-labeled Delete Account button at the bottom.
  • Dedicated “Privacy & Data” submenu under Settings, with Delete Account as the last item.

The label matters too. “Manage Account,” “Close Account,” “Cancel Account,” “Remove Account” are all variants App Review has flagged because they don’t explicitly say “delete.” Use “Delete Account” verbatim.

Mistake 2: Soft-delete only

Some teams interpret “deletion” as soft-delete — flag the row, hide it from the user, retain everything in the database. Apple is explicit that this isn’t enough. The user’s data has to actually be removed.

Practical implementation:

  • Hard-delete the user’s primary record and all rows that reference it via foreign key.
  • Anonymize rows you can’t legally delete (e.g., transaction records you must retain for tax compliance). Replace the user reference with a generic null/sentinel value so the record exists for accounting but doesn’t identify the user.
  • Cascade-delete content the user owns (posts, uploads, profile media). For shared content (group chats, comments on others’ posts), policies vary — Apple accepts either deleting the user’s authored content or anonymizing it.
  • Trigger a backend job to clean up secondary stores: search indexes, analytics events tagged to the user, cached profile images on a CDN, ML training data.

Document this in your privacy policy and your User Privacy Choices URL. Be specific: “Account deletion removes your profile, posts, and authored content within 30 days. Transaction records are retained for 7 years for tax compliance.” Vague answers (“we delete your data when you ask us to”) get flagged.

Mistake 3: Forgetting the Sign in with Apple revoke

If you offer Sign in with Apple, your deletion handler must call Apple’s REST API to revoke the user’s auth token. Apple specifically calls this out, and they audit it.

The endpoint is https://appleid.apple.com/auth/revoke. Server-side flow:

POST https://appleid.apple.com/auth/revoke
Content-Type: application/x-www-form-urlencoded

client_id=YOUR.SERVICES.ID
&client_secret=YOUR_SIGNED_CLIENT_SECRET
&token=USER_REFRESH_TOKEN
&token_type_hint=refresh_token

You’ll need:

  • A Services ID (set up in your Apple Developer account, separate from the iOS app’s Bundle ID).
  • A signing key for the client secret (generated from a private key Apple gives you).
  • The user’s refresh token, which you got at sign-in time and stored.

If you don’t have the refresh token (e.g., the user signed in once and never returned), you can’t revoke. Store the refresh token at sign-in time so you have it later. This is the single most-rejected detail in modern App Review for apps using Sign in with Apple.

Mistake 4: Letting subscriptions silently continue

If the user has an active App Store auto-renewable subscription, deleting their account from your app does not cancel the subscription. Apple owns the billing relationship. The user has to cancel the subscription separately through Settings → Apple ID → Subscriptions, or via apps.apple.com/account/subscriptions.

Apple’s guideline expects you to notify the user before deletion that:

  1. Their App Store subscription will continue billing through Apple even after their app account is deleted.
  2. They need to cancel the subscription separately, with a tap-to-cancel link or button.

Two ways to satisfy this:

  • iOS 15+: Use StoreKit.AppStore.showManageSubscriptions(in:) to deep-link the user to the system subscription-management sheet.
  • Older iOS: Provide a button labeled “Manage Subscription” that opens https://apps.apple.com/account/subscriptions.

Block the deletion flow until the user has explicitly acknowledged this notice.

Mistake 5: No public-facing deletion URL

App Store Connect’s User Privacy Choices URL field is optional, but App Review treats apps with one as more compliant than apps without. The page should:

  • Explain the deletion process step-by-step (mirrors what’s in the app).
  • Document timeline (“we complete deletion within 30 days”).
  • Disclose any data you retain after deletion and why (“transaction records for 7 years for tax compliance”).
  • Provide a backup email or web form for users who can’t access the app (lost device, locked account, etc.).

OrbitKit generates this page from a wizard mapped to the same data model as your privacy policy. See the data deletion URL generator for the structured form.

A reference deletion-flow architecture

For a typical iOS app with a backend:

  1. In-app UI: Settings → Account → Delete Account button. One confirmation dialog, no friction beyond verifying the user is who they say (e.g., re-authenticate or enter a code from their email).
  2. App calls backend with the user’s auth token and a confirmed: true flag.
  3. Backend handler:
    • Revokes Sign in with Apple token (if applicable).
    • Hard-deletes the user record + cascading owned content.
    • Anonymizes rows that must be retained.
    • Queues a background job for secondary-store cleanup (search index, analytics, CDN cache).
    • Returns success to the app.
  4. App shows confirmation: “Your account has been deleted. Your App Store subscription, if any, will continue billing — manage it at Settings → Apple ID → Subscriptions.”
  5. App signs the user out and returns to a logged-out state.

The whole flow is one tap, one confirmation, one backend call, one notice. Anything longer is a rejection risk.

Where OrbitKit fits

OrbitKit doesn’t write your iOS deletion code (that’s in your app). What it handles is the public-facing documentation Apple wants:

  • A wizard that captures your deletion methods, steps, timeline, and retention disclosure.
  • A hosted page at https://your-domain.com/delete that App Store Connect’s User Privacy Choices URL field can point to.
  • Updates that flow through to the deployed page in seconds, no redeployment needed.

If you’re shipping a deletion flow this week, the data deletion URL generator gets you the public-facing piece in 10 minutes. The in-app code is on you.

Further reading