The Short Answer
Guideline 5.1.1(v) is Apple's account deletion rule. If your app lets a user create an account, it also has to let that user initiate deletion of the account from inside the app, in a place they can actually find, not only through a support email or a web page you link out to. App Review cites 5.1.1 when it creates an account during testing and cannot find a way to delete it without leaving the app. The fix is a real delete-account action reachable from your settings screen that removes the account, not a deactivate or log-out button relabeled.
Deletion Is Not the Same as Deactivation
The distinction App Review actually checks is whether the account is gone, or just hidden. A button that disables sign-in but leaves the account and its data sitting in your database, reachable again the moment someone signs back in, is deactivation, not deletion. Apple's guideline is written around the user's expectation: when someone taps delete account, they expect the account and their data to actually go away, not to be parked in a disabled state indefinitely.
You are allowed to keep data you are legally required to retain, such as transaction records for tax purposes or information tied to an active fraud investigation, and you can tell the user that plainly in the deletion flow. What you cannot do is quietly keep everything and call the account deactivated instead of deleted.
The Account Deletion Test
App Store Launch Club members run three questions before submitting to check whether 5.1.1 applies and whether their build actually satisfies it.
- Does your app let a user create an account, either your own email-and-password system or through a third-party login like Sign in with Apple or Google?
- Can that user find a delete-account action inside the app itself, without being sent to a website, an email address, or a support ticket to get it done?
- Does tapping it actually remove the account and its personal data on your backend, rather than just signing the user out or flipping a disabled flag?
A yes to the first question with a no anywhere after it is a real gap. Test it yourself by creating a throwaway account, deleting it, and confirming on your own backend that the row is gone or clearly marked for removal, the same way a reviewer will.
Adding Account Deletion to an Expo App
In an Expo app, account deletion is not a client-only feature. The button in your UI has to call a real endpoint that does the deletion server-side, because the client never has permission to remove another user's row and should not be trusted to remove its own without a check either.
- Add a delete-account row inside your settings screen, not buried behind a support link. A single tap should lead to one confirmation step, not a maze.
- Confirm intent once, clearly. A simple are-you-sure dialog is enough. Do not require re-entering a password or adding extra friction beyond a single confirmation, since that itself can read as making deletion artificially hard.
- Call a backend endpoint that deletes the auth user. In Supabase this means the service role calling auth.admin.deleteUser from a server function, since the anon client key cannot delete an auth user directly. In Firebase this is the Admin SDK's deleteUser call from a Cloud Function, not the client SDK.
- Delete or anonymize the associated data in your database in the same server-side flow: profile rows, uploaded content, and anything else tied to that user ID, minus whatever you are legally required to retain.
- Revoke any linked third-party sign-in tokens, including Sign in with Apple, so the deleted account cannot silently reappear the next time that same Apple ID is used to sign in.
- Log the user out and clear their local session on the device immediately after the backend confirms deletion, so the app does not sit in a broken half-signed-in state.
The Guideline It Travels With: Sign in with Apple
5.1.1 and 4.8 get checked in the same review pass more often than not, since both are account-handling rules and a reviewer testing your sign-up flow naturally ends up testing your login options too. An app that added Sign in with Apple to clear a 4.8 rejection but still has no in-app account deletion is a strong candidate for a 5.1.1 rejection right behind it, and the reverse is just as common. The full setup for Apple's login requirement is covered in [Guideline 4.8: When Your App Actually Needs Sign in with Apple](/blog/app-store-rejection-guideline-4-8), and the broader authentication build is in [how to add authentication to your Expo app](/blog/how-to-add-authentication-to-your-expo-app).
How to Answer a 5.1.1 Rejection in Resolution Center
If the rejection already landed, treat it the same as any other App Review message: fix the specific thing cited, then reply once with what changed and a new build.
- Confirm the reviewer could not find or complete account deletion, which is almost always the actual issue rather than a misunderstanding of the guideline.
- State exactly where the delete-account action now lives in your app, by screen name, so the reviewer does not have to search for it again.
- Submit a new build with the fix rather than replying with a description of a change that has not shipped yet.
The general pattern for answering any Resolution Center message, including how App Review Information and demo credentials factor in, is covered in [Guideline 2.1 Information Needed](/blog/guideline-2-1-information-needed-rejection).
Short, practical drops on app ideas, validating fast, store listings, and passing app review. No spam, unsubscribe anytime.
Frequently asked questions
What is a Guideline 5.1.1 rejection?
Guideline 5.1.1(v) is Apple's account deletion rule. App Review cites it when an app lets a user create an account but gives no way to delete that account from inside the app, such as only offering deactivation, a log-out button, or a link to email support instead of a real in-app delete action.
Is deactivating an account the same as deleting it under 5.1.1?
No. Deactivation disables sign-in but leaves the account and its data in place, reachable again if the user signs back in. Guideline 5.1.1 expects an actual deletion path that removes the account and its personal data, not a disabled state relabeled as deleted.
Can I keep any user data after an account is deleted?
Yes, for what you are legally required to retain, such as records needed for tax purposes or an active fraud investigation. You can state this plainly to the user in the deletion flow. What is not allowed is quietly keeping everything and presenting deactivation as if it were deletion.
Does account deletion have to happen instantly?
The user has to be able to initiate deletion from inside the app in one clear flow. Apple does not require the underlying data to vanish in real time, but the request has to actually go through your backend and result in the account and its data being removed or scheduled for removal, not just a client-side sign-out.
How do I delete a Supabase auth user from an Expo app?
The client's anon key cannot delete an auth user directly. Route the delete-account button through a server-side function that uses the Supabase service role key to call auth.admin.deleteUser, then remove the related rows in your database in that same server-side flow.
Does Guideline 5.1.1 apply if my app has no account creation at all?
No. The requirement is scoped to apps that support account creation. If your app has no sign-up or account system, or every feature works without one, 5.1.1's account deletion requirement does not apply.
Last reviewed by David on August 26, 2026
