If your build was rejected this morning with a Guideline 5.1.1(v) letter pointing at the absence of in-app account deletion, and the only login path in the app is Sign in with Apple, Google, or Facebook, you are looking at the most common shape of this rejection in 2026. The reviewer is not asking for a new feature on top of the social login. They are saying the social login created an account record, and the account record needs an in-app delete path.
Short answer
Guideline 5.1.1(v) rejects iOS apps that support account creation but do not let users initiate account deletion inside the app, and the rule applies to social login providers the same way it applies to email and password. Apple's account deletion support page lists Facebook Login, Google Sign-In, Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, and WeChat Login next to Sign in with Apple, and requires that the deletion also revoke the social network credentials and disable data access between the app and the provider.
What you should know
- The rule applies to social logins, not only to Sign in with Apple. Apple's published list of providers covers Google, Facebook, X, LinkedIn, Amazon, and WeChat. Any of these used to create the primary account triggers the deletion requirement.
- Deactivation is not deletion. Apple's support documentation says the entire account record and associated personal data have to be deleted. A disabled or hidden account fails the policy.
- In-app initiation is mandatory for general consumer apps. A web link, a support email, or a phone number as the only path is the most common reason reviewers cite Guideline 5.1.1(v).
- Sign in with Apple needs a token revocation call. Apple's revoke_tokens REST API is the endpoint Apple's guidance points at, hosted at appleid.apple.com/auth/revoke.
- Highly regulated apps still need in-app initiation. Guideline 5.1.1(ix) lets banking and health apps layer extra verification on top, but the user still starts the deletion inside the app.
What does Guideline 5.1.1(v) actually say about social logins?
The published text of Guideline 5.1.1(v) ties three obligations together. The app must offer account deletion within the app if it supports account creation. The app must include a mechanism to revoke social network credentials and disable data access between the app and the social network from within the app. The app may not store credentials or tokens to social networks off of the device.
The three parts are read together by reviewers. A button that wipes the local server record but leaves the Google or Facebook permission intact does not satisfy the second sentence. A page that revokes the social credential but leaves the user record on the server does not satisfy the first. Apple's account deletion support page is explicit that the deletion path has to remove the account record, the personal data, and the linkage to the third-party identity provider.
Why does using Google or Facebook sign-in trigger the rejection so often?
Most apps that get rejected on this clause are not missing a delete button by design. They were built with a social login flow first, the developer added an email sign-up path later, and the deletion screen was wired up against the email path only. When the reviewer creates a test account through Google or Facebook, they end up on a settings screen with no delete option for that login type, or with a delete option that throws an error because the backend was not written to handle a social identity.
The second common shape is the link-out. The app shows a settings entry that says 'To delete your account, visit our website at example.com/delete-account'. Apple's support page lists this exact pattern as non-compliant for general consumer apps. The deletion has to start inside the app. A web flow is permitted as the second step, for example to confirm identity, but the entry point belongs in the app.
What does Apple expect the social login deletion flow to do under the hood?
Apple expects four things to happen, in any order, when the user confirms deletion. The server account record is removed along with any personal data tied to it. The social network token stored against that account is revoked. The data access permission granted to the app on the provider side is also released so the app no longer reads from the user's Google, Facebook, or X profile. The user is informed of the timeline if the deletion is not immediate.
For Sign in with Apple, the revocation step is a documented call to appleid.apple.com/auth/revoke with a client_id, client_secret, the token, and a token_type_hint. For Google, the equivalent is Google Identity's token revocation endpoint. Facebook exposes a DELETE request on the Graph API permissions edge. Calling the provider's revoke endpoint is the technical action that backs up the policy promise.
What does the rejection letter usually say?
The standard letter cites Guideline 5.1.1(v), Data Collection and Storage. It then names the missing element, usually with one of these phrases: 'the app supports account creation but does not include an option to initiate account deletion', 'the app supports account creation but does not include a mechanism to revoke social network credentials', or 'we found the app sends the user to a website to complete the account deletion'. The letter asks the developer to add the missing path and resubmit. It does not usually quote a specific API or method, because the policy is read at the user experience level rather than the binary level.
Reviewers test the path manually. The screenshot they attach to the rejection is almost always a capture of the settings screen or a step in the deletion flow where the option is missing or fails. This makes 5.1.1(v) one of the few Guideline 5.1.1 sub-clauses where the reviewer's own session is the evidence, and there is no useful argument about a misunderstanding.
Is there an exception for highly regulated industries?
There is, but it is narrower than most teams assume. Guideline 5.1.1(ix) allows apps in highly regulated industries to use additional customer service flows to confirm and facilitate the account deletion process. The Apple support page lists banking, healthcare, financial services, and government services as typical fits. The exception lets a bank confirm the deletion request through its existing verification channels. It does not let a fintech app skip the in-app initiation step.
The practical line is this. The user has to be able to start the deletion inside the app. The app can then route the request to a verification step that may involve a phone call, an in-person visit, or a document upload. The path that fails review is the path where the in-app entry is missing entirely, regardless of how strong the offline verification is.
How to fix the rejection without inviting a repeat letter
The fix has four parts: an in-app entry point, a working server deletion, a token revocation call for every provider in use, and a user message that explains the timeline. Each part has its own failure mode.
| Element | What reviewers test | Common mistake | Cited clause |
|---|---|---|---|
| In-app entry point | A delete option visible in account settings | Hidden behind two help screens or a web link | 5.1.1(v) |
| Server deletion | Account record gone after confirmation | Deactivated but recoverable | 5.1.1(v) |
| Revoke social token | App-issued token invalid on provider side | Token left valid on Google or Apple | 5.1.1(v) |
| Disable data access | App permission removed on provider | Permission still granted in user account | 5.1.1(v) |
| Timeline notice | User knows when data is removed | No notice or vague language | 5.1.1(v), 5.1.1(i) |
For a typical app with Sign in with Apple, Google Sign-In, and a fallback email path, the working pattern is a single Delete Account screen that accepts a re-authentication, calls the backend deletion endpoint, then issues the matching revoke call (Apple, Google, or no extra step for plain email) and a 30-day data removal notice.
What to watch out for
A common mistake is to ship the deletion flow only for the email path because that is the only flow the team built in-house, while the social login flows remain undeletable. Reviewers create a Google or Facebook test account most of the time, so the rejection arrives even when the email path is correct.
A second mistake is to call the deletion endpoint without calling the provider's revoke endpoint. The user record disappears on the app's side, but the user revisits the app, taps Sign in with Google, and the account silently re-creates because the social token was never revoked. Apple's support page reads this as data access continuing between the app and the social network, which is exactly what 5.1.1(v) prohibits.
A third mistake is to read the highly regulated exception broadly. A dating app, a productivity app, or a B2B SaaS portal does not qualify even when the data is sensitive in the team's view. For builders who want an external scan of which social login providers their iOS bundle actually integrates and whether the revoke paths are present, PTKD.com (https://ptkd.com) is one of the platforms that maps the OAuth SDK symbols inside a compiled IPA against the deletion-flow requirement.
Key takeaways
- Guideline 5.1.1(v) treats Google, Facebook, X, LinkedIn, Amazon, WeChat, and Sign in with Apple identically. If any of them creates the primary account in the app, the in-app deletion requirement is on.
- The deletion has to wipe the server record, revoke the social network token, and release the data access permission on the provider side. A delete button alone is not enough.
- The in-app entry point is mandatory for general consumer apps. A link to a website, a support email, or a phone number as the only path is the modal cause of the rejection.
- Sign in with Apple specifically needs a call to the revoke_tokens REST API at appleid.apple.com/auth/revoke. Skipping the call is a documented policy gap, not a stylistic preference.
- Some teams outsource the pre-submission check entirely to platforms like PTKD.com (https://ptkd.com), which scan a compiled IPA for the social login SDKs in use and the deletion flow symbols that match each provider.
