GENERAL INFORMATION · JULY 2026
The rejection
An app supports sign-up. Somewhere in settings there is “Log out,” and perhaps “Deactivate.” To actually remove the account, a person has to email support, or visit the website, or ask. The build is finished, the documents are written, and review returns a privacy rejection under Guideline 5.1.1(v).
It is a frustrating one to receive late, because nothing is wrong with the product. What is missing is a path.
What Apple actually requires
Apple’s App Review Guidelines state, at 5.1.1(v) Account Sign-In, that if your app supports account creation, you must also offer account deletion within the app. Apple’s own support page puts the start date at June 30, 2022 and sets out what that means in practice. Read both directly: App Review Guidelines and Offering account deletion in your app.
Four points from Apple’s support page do most of the work in practice:
- Deletion is not deactivation. Apple asks you to offer to delete the entire account record along with associated personal data, and says that only offering to temporarily deactivate or disable an account is insufficient.
- It has to start in the app. Apple says the option should be easy to find, typically in account settings. If a person must visit a website to finish, Apple asks for a link directly to that page — a link is a completion step, not a substitute for the in-app path.
- Shared content counts. Apple notes that people expect all data associated with the account to be deleted, including user-generated content shared with others.
- Slow is allowed; silent is not. If deletion is manual or takes time, Apple says that is acceptable, provided you tell the person how long it will take and confirm when it is done.
Apple also addresses the edges: apps in highly regulated industries, as described in Guideline 5.1.1(ix), may use additional customer-service flows; apps outside those industries should not require a phone call or an email. Legal retention obligations still apply, and data you are legally required to keep is carved out of what deletion removes. Automatically generated “guest” accounts are included. Where an auto-renewable subscription is attached, people should be told and given the chance to cancel. Apps using Sign in with Apple are pointed to the REST API to revoke tokens.
Apple’s guidelines change, and this page reflects Apple’s own pages as read on July 25, 2026. Check the current text before you rely on it.
Where the documents come in
This is where a build problem becomes a documents problem. Almost every privacy policy already promises deletion. It says a person may request deletion of their account and associated data, and often names a route and a timeframe. That sentence was probably written before anyone decided how deletion would actually work.
So the useful questions are not about the guideline at all:
- Does the route your policy describes exist, and is it the one the app actually offers?
- Does “delete” mean the same thing in the policy, in the app, and in your backend — full record removal, or a disabled flag and a retention window?
- If you keep some data because you are legally required to, does the policy say so, and say which?
- If deletion takes a week, does the policy say a week, or does it imply immediate?
- Does deletion reach the third parties and SDKs that received the data, and does the policy describe what they do?
- Do the Terms describe what happens to purchases, subscriptions, and shared content when an account ends?
A team can answer all of these. They are factual questions about your own product. But they are the questions where the documents and the build most often turn out to describe two different systems.
What to do about it
Put the deletion flow and the deletion sentence side by side and make them the same claim. If they differ, the first decision is not which text to edit — it is which one is telling the truth about the product.
Two neighbouring notes may help: the same reconciliation exercise applied to the data flows a privacy policy has to describe, and, if you want a broader sweep before submitting, the 12-point pre-submission read-through, where this is one line among twelve.
A caution worth stating plainly
This note is general information, not legal advice, and it is not exhaustive. It describes Apple’s published requirement as of the date above; it does not tell you what your app must do, what your obligations are under any privacy law, or how long you may or must retain any particular record. Reading it does not make your app compliant, correct, or approved. It is a way to find questions, not a way to close them.
If you would like both documents read
The Focused Review is a written review of your app’s existing, final-form Privacy Policy and Terms of Use — $275 flat, one app, both documents, under Tennessee law. You receive written issue spots and considerations. It is not drafting, not revisions, not a compliance certification, and it does not produce or edit code, build your deletion flow, or contact Apple for you.
Have both final documents? Begin the private Focused Review →