Who is this for?
For anyone about to publish an app (iOS especially) that has user accounts — you don't need to code. If your app lets people sign up, Apple will require this no matter what. Better to get it right the first time than eat a rejection and lose days.
When does this show up? (and why it catches you off guard)
The moment is always the same and it always hurts: you finish your app, submit it for App Store review… and it gets rejected over rule 5.1.1. It catches you off guard because the AI, while building, focuses on the flow to create an account and use the app — it almost never thinks about the flow to delete it. It's a legal and an Apple requirement that you have to ask for yourself, explicitly, before publishing.
The rule, spelled out (Apple 5.1.1 v)
If your app allows creating an account, it must allow initiating the deletion of that account FROM WITHIN the app. Just "deactivating" or "pausing" doesn't cut it. Sending the user to an email or an external form doesn't cut it either (except in heavily regulated industries like banking or healthcare). The button has to be easy to find, usually in Settings.
The trap that sinks you TWICE
The social-media advice that's poison
There's one going around: "to comply fast, keep the account but hide the name and email." Don't do it. Hiding is not deleting: (1) it violates Europe's GDPR and California's CCPA — which require actual deletion of the personal data — and exposes you to fines; and (2) if Apple detects it, it rejects you anyway. It's losing on both fronts.
The correct way · soft delete + anonymization
Here's the balance that actually works. The real technical problem is: if you delete the user "the brute-force way," your database breaks (their orders, comments, etc. end up pointing to a user that no longer exists). The professional solution: you truly delete the personal data (name, email, photo, phone) but you leave an anonymous shell in its place so the relationships don't break. The personal stuff is gone forever; your database integrity stays intact.
Picture it like this
It's like when an employee leaves a company: you wipe their personal data from the system, but the projects they worked on don't vanish — they get marked as "former employee." The work stays; the person is anonymized. That's soft delete with anonymization.
The 3 pieces Apple and the law require
Your deletion has to have
- A "Delete my account" button that's easy to find, inside the app (typically in Settings).
- Actual deletion of the personal data: name, email, photo, phone — anonymized irreversibly.
- Deletion in the authentication system too (not just in your users table — also in Supabase Auth / the login provider).
Master prompt · ask your AI for it
This prompt asks your AI for everything needed to comply with the rule and the law, without breaking your database. Copy it and paste it in:
Implement account deletion for my app, complying with Apple's rule 5.1.1 and GDPR/CCPA. My stack: [tell it your stack, e.g. Supabase + Next.js]. 1. Create the "Delete my account" button inside Settings, easy to find. 2. Before deleting, show a clear confirmation (this is irreversible) and, if you want, ask to verify identity (a code via email/phone). 3. Do a SOFT DELETE with irreversible ANONYMIZATION of the personal data: name, email, photo, phone. Don't hide them: replace them with anonymous values (e.g. "deleted user") or NULL. 4. Leave a shell so the foreign keys don't break (their orders/comments must not blow up). 5. Delete the identity in the auth system too (e.g. Supabase Auth admin deleteUser), not just in my table. 6. If the user has an active SUBSCRIPTION, warn them BEFORE deleting and tell me how to handle the cancellation so you don't keep charging them or lose the billing record the law requires you to keep. 7. Log in an audit trail that the account was deleted (without personal data) in case the law requires proof. Give me the migration, the anonymization function and the button component, and explain in simple steps what each part does.
The case almost nobody handles · subscriptions
Don't lose money (or break the law) when deleting
If the user being deleted has an active subscription, there are two traps: continuing to charge them after they leave (a legal and reputational problem), or deleting the billing record the law forces you to keep for years. The rule: cancel the subscription on deletion, but keep the anonymized accounting record (without personal data). Your AI handles it if you ask — that's why it's in the prompt.
How to confirm it came out right
Checklist before submitting for review
- The button is easy to find inside the app (not hidden on an external website).
- After deletion, the personal data no longer exists in your database (verify it by hand).
- The user also disappears from the auth system (they can't log in again).
- The things they left behind (orders, comments) didn't break anything — they still show an anonymous author.
- If there was a subscription, it got canceled and the accounting record remains without personal data.
This is not legal advice
This guide explains the recommended technical practice for complying with Apple's rule 5.1.1 and the deletion principle in GDPR/CCPA. For your specific case (especially if you handle sensitive data or you're in a regulated industry), consult a legal professional.
In NeuralOS, correct deletion comes built in
The apps you build in NeuralOS are born with the account-deletion flow ready and compliant — button in Settings, anonymization, and deletion in auth — so you don't get rejected over this. One less thing to worry about before publishing.