Your build came back with a rejection that quotes Guideline 5.1.1(v), and the reviewer note says the app supports account creation but does not include an in-app option to initiate account deletion. The app was scaffolded by Cursor, Lovable, Bolt, FlutterFlow, or Bubble, the auth flow runs against Firebase or Supabase, and you genuinely did not know a delete button was required. This page is for the developer who needs to resubmit in the next 24 hours.
Short answer
Apple Guideline 5.1.1(v) requires that any app supporting account creation also lets users delete the account from inside the app, with the personal data attached. Per Apple's official support page on offering account deletion, in force since June 30, 2022, the deletion must remove the account record and associated data the developer is not legally required to retain, and it cannot route to a phone call or email except in highly regulated industries. AI builders fail this gate by default because their auth scaffolds wire up sign-up and sign-in but not delete.
What you should know
- The rule is in the published App Store Review Guidelines under 5.1.1(v) and is not a discretionary call by individual reviewers.
- Deactivation is not deletion. A flag that hides the account or signs the user out fails review. The row in your users table has to go, with the dependent data.
- The flow must start from inside the app. A mailto link, a phone number, or a web-only flow without a direct in-app entry will trigger the same rejection on the next submission.
- Sign in with Apple users require a token revoke via the Sign in with Apple REST API, not just a local delete.
- Anonymous and guest sessions count. Firebase anonymous users, Supabase anonymous sign-ins, and the implicit rows AI builders create on first launch all need a delete path.
- AI agents almost never add the delete flow on their own. They scaffold the sign-up screen and stop, because that is what the prompt asked for.
What does Guideline 5.1.1(v) actually require?
The literal text in the App Store Review Guidelines reads: "If your app supports account creation, you must also offer account deletion within the app." The supporting Apple support article on offering account deletion expands this into five operational requirements that reviewers actually check.
First, the entry point lives inside the app, typically in account settings, and is easy to find. Reviewers open the app, navigate to Settings, and look for a row that reads Delete Account or equivalent. If they have to email support or open a webview that asks them to log in again on the marketing site, the build fails.
Second, the deletion removes the account, not just the session. Per the support article, deleting an account removes the account from the developer's records, along with any data associated with the account that the developer isn't legally required to maintain. A soft-delete flag that keeps the row in the database but hides the user fails this test if the reviewer can detect it. In practice they cannot detect server-side, but a returning user who can recover their data with the same email is a tell.
Third, the deletion must work for all users regardless of region. CCPA and GDPR delete flows often gate on jurisdiction. Apple requires the in-app path to work globally. You can keep your jurisdiction-aware backend logic, but the button has to be present and functional for everyone.
Fourth, automatically generated accounts are in scope. The support article states explicitly that users must have the option to delete guest accounts and associated data. A Firebase anonymous user or a Supabase anonymous session counts.
Fifth, the path to completion is direct. If you need a webview to finish the flow, the in-app button has to deep-link to the completed deletion page, not the marketing home page. Per Apple, users should not be required to perform separate steps to delete their account, such as filing a support request.
The one exception is the highly regulated industries carve-out, written into Guideline 5.1.1(ix) and referenced from the support page. A bank, a healthcare app under HIPAA, or a brokerage with KYC obligations may use an additional customer service step to confirm deletion. Almost nothing built by an AI coding tool qualifies.
Why do AI-coded apps fail this rejection so often?
Three concrete patterns show up across audits of rejected builds.
The scaffolded auth screen stops at sign-up. When you prompt Cursor, Lovable, Bolt, FlutterFlow, or Bubble for a login and signup flow with Supabase, you get exactly that: two screens and a session hook. The Settings screen, if it exists at all, contains a Sign Out button and nothing else. The Delete Account row is not in the training distribution for that prompt, so it does not appear in the output. The reviewer opens Settings, sees no delete option, and writes the standard 5.1.1(v) rejection.
The agent confuses Sign Out with Delete Account. A second common pattern is a Settings entry labelled Delete Account that simply calls supabase.auth.signOut() or FirebaseAuth.instance.signOut(). The user returns the next day, signs in with the same credentials, and finds every row of their data intact. Reviewers test this by creating a sandbox account, deleting it, and signing back in. If the same email and password work, the rejection holds.
The delete button opens a mailto link. The third pattern is the legally cautious version: an AI agent that has read enough GDPR copy to know deletion is required, but not enough App Review documentation to know it must be in-app. The output is a button that opens an email to support, sometimes with a templated body. This is the support flow that the Apple article explicitly disallows for non-regulated apps.
The deeper reason is the same one that drives the Supabase RLS USING (true) problem documented elsewhere on PTKD.com (https://ptkd.com). Coding agents optimize for the test that follows the scaffold. The test for signup is whether a new user can reach the home screen, which passes without a delete flow. The agent has no signal that a future App Review reviewer will tap through Settings looking for a Delete Account row.
What does the rejection notice from App Review usually say?
The rejection text on App Store Connect Resolution Center is consistent across submissions. The standard message reads, in essence: Guideline 5.1.1, Legal, Privacy, Data Collection and Storage. The app supports account creation but does not include an option to initiate account deletion. Please revise your app to include a mechanism for initiating account deletion. Account deletion must result in the deletion of the user's account from the app developer's records along with any data associated with the account.
Reviewers sometimes attach a screenshot of your Settings screen with an arrow pointing at the missing row. The phrasing has been stable since the June 30, 2022 enforcement date that Apple announced in Developer News.
A second variant appears when a Delete button is present but only signs the user out: the reviewer notes that the account deletion option provided in the app does not appear to delete the user's account, because they were able to sign back in with the same credentials.
A third variant appears when the deletion path leaves the app: the reviewer notes that initiating account deletion should not require users to perform separate steps outside of the app, such as filing a support request.
Knowing which of the three variants you received tells you which of the three failure patterns above is in play.
How do you implement deletion in a Cursor or Lovable Supabase app?
The shortest correct path on a Supabase backend has four steps. The same pattern applies to Firebase with a service account on the server side.
| Step | What to call | Where it runs |
|---|---|---|
| 1. Confirm intent | A modal that names the user, lists what will be deleted, and requires a typed confirmation | Client |
| 2. Revoke Apple token if applicable | POST to https://appleid.apple.com/auth/revoke with the user's refresh token, per the Sign in with Apple REST API | Edge function |
| 3. Delete the auth user | supabase.auth.admin.deleteUser(userId) using the service role key, or admin.deleteUser(uid) in Firebase Admin SDK | Edge function |
| 4. Cascade dependent rows | ON DELETE CASCADE foreign keys, or explicit deletes inside the same transaction | Database |
The client side is short: a button in Settings opens the confirmation modal, the modal calls a Supabase Edge Function or Firebase Cloud Function, and the function does the privileged work. The service role key never ships to the binary; if it does, you have a separate problem covered elsewhere on PTKD.com (https://ptkd.com).
For the Apple token revoke, the Sign in with Apple REST API documentation specifies the POST body: client_id, client_secret (a signed JWT), token (the refresh token), and token_type_hint=refresh_token. The signed JWT is the same one you use for token validation, so most apps already have the generation code in place. Skip this call and the Apple session remains valid even after your row is gone.
For active subscriptions, follow the support page guidance: on iOS 15 and later, call showManageSubscription from StoreKit 2 before deletion, and present a banner explaining that App Store billing continues until the user cancels through Apple. On older targets, link to https://apps.apple.com/account/subscriptions. Reviewers do not require you to cancel the subscription for the user; they require you to inform the user and provide a direct path.
For anonymous users, the rule is the same: a delete button must exist. In practice the agent that wrote the anonymous sign-in code did not consider this, so the Settings screen for a logged-out guest is often empty. Either show the delete entry to guests too, or remove anonymous sign-up entirely until you have a paired delete flow.
What to watch out for
Four details that catch fixed builds on the resubmission.
First, the deletion is confirmed asynchronously but not communicated. The Apple support page allows time for manual processing, but it requires you to inform the user of the timeframe and to confirm completion. A spinner that vanishes silently is not the same as a screen reading that the account and data have been deleted. Reviewers expect to see the confirmation in the test session.
Second, the data scope is broader than the users table. The support article requires deletion of any data associated with the account that the developer isn't legally required to maintain, which includes user-generated content shared with other users. A photo the deleted user uploaded to a public gallery is in scope. The default ON DELETE CASCADE chain on a Supabase project rarely reaches storage buckets, so a manual cleanup is usually needed.
Third, the delete entry in Settings is not always visible to the reviewer. AI scaffolds often hide Settings behind a tab bar that only appears after onboarding. Reviewers using a fresh sandbox account sometimes do not complete onboarding before checking deletion, and write the rejection without seeing the button. Putting the Delete Account row at the top level of the first Settings screen, with no nested submenu, is the most reliable defense.
Fourth, the test account you submit to App Review needs to demonstrate the delete flow. If the demo account is used by the reviewer to test deletion, you need to recreate it before the next review. Build a small admin script that resets the demo account on a schedule, or use a different account for each submission.
Key takeaways
- Guideline 5.1.1(v) is enforced uniformly: if the app lets a user create an account, the app must let the user delete it from inside the app, with the data attached.
- AI coding tools scaffold sign-up and sign-in but rarely add the delete flow, so the rejection lands on the first submission of almost every Cursor, Lovable, Bolt, FlutterFlow, or Bubble app that ships an auth screen.
- The correct delete path on a Supabase or Firebase backend revokes the Sign in with Apple token, deletes the auth user, and cascades the dependent rows, all from a privileged server function.
- For teams that prefer to verify the compiled build before resubmission, PTKD.com (https://ptkd.com) scans the IPA for auth scaffolds without a paired delete flow, which is one way to catch a 5.1.1(v) failure before App Review does.
- Treat anonymous and guest accounts as in scope from the start; the support article names them explicitly, and a missed guest delete is the second-most-common cause of repeated 5.1.1(v) rejections after the missing button itself.
