How to add an account deletion page for iOS Guideline 5.1.1(v)

What the guideline asks for

Apple's requirement has a few concrete parts.

Deletion must be initiable in the app. A user who can sign up inside your app must be able to start deletion inside your app too. Burying it behind a support request does not satisfy the requirement.

It must be a deletion, not a deactivation. Disabling sign-in while retaining the account is not deletion. If you must retain certain records for a legal or regulatory reason, you can retain them, but you should say so plainly rather than describing a suspension as a deletion.

The control must be findable. Apple reviewers look for it. A deletion option nested several unlabelled screens deep in a settings menu is a common cause of a rejection that developers experience as arbitrary.

Full account deletion, not just the app's local data. Clearing a local cache is not what is being asked.

Google Play has its own account deletion requirements, and they add something Apple's do not: a web-based deletion path that a user can reach without installing the app, declared in Play Console. If you ship on both stores — most apps do — you need both the in-app flow and the reachable URL.

Why Firebase Authentication makes this easy to get half-right

Firebase Auth gives you a delete-user call, and that is genuinely useful: it removes the authentication record and the Firebase user ID that the table above marks as likely collected. The trap is believing that is the whole deletion.

The Firebase user ID is a foreign key. It is very likely present in your Firestore documents, your storage object paths, your analytics user properties if you set them, and your subscription records if you identify customers by account ID. Deleting the auth record while leaving those rows behind produces orphaned personal data and a deletion claim that is not accurate.

Depending on the sign-in methods you enable, the auth record itself may hold an email address or a phone number — which is exactly why the table marks those as configuration-dependent rather than assumed. Which ones apply is a function of your production configuration, not of the SDK being installed, so an App Passport asks you which sign-in methods you actually enable.

Before you ship a deletion flow, write down every place a user identifier lands. That list, not the SDK call, is your deletion scope.

What a complete deletion flow contains

A flow that holds up under review generally has:

1. A clearly labelled entry point — "Delete account" in account or settings, using that word.
2. Confirmation with a clear consequence — what is deleted, what is retained and why, and whether it can be undone.
3. Reauthentication for a sensitive action. Firebase requires a recent credential for deletion; handle the reauthentication error rather than showing a generic failure.
4. Deletion across every store that holds the identifier, not only the auth record.
5. An honest statement about timing. If deletion is asynchronous, say so. If backups age out on a schedule, say that instead of implying instant erasure everywhere.
6. A web-based path for Google Play's requirement, reachable without the app installed.

Common mistake

The most common mistake is offering deletion only by email or through a contact form. It feels reasonable — a human reviews each request — but it does not meet the in-app initiation requirement, and it is one of the more frequent 5.1.1(v) rejections.

The second is calling Firebase's delete-user method and stopping there, leaving user rows in Firestore keyed by a user ID whose auth record no longer exists. Your privacy policy says the account was deleted; your database disagrees.

The third is a "Delete account" button that logs the user out. Whether the cause is an unhandled reauthentication requirement or a placeholder that was never wired up, a reviewer testing the flow sees a control that does not do what it says.

The fourth is shipping the in-app flow and forgetting the URL, which passes Apple review and then stalls on Google Play.

Why apps get rejected

The recurring reasons, in rough order of how often they appear:

• No in-app deletion at all in an app that offers account creation.
• Deletion that only deactivates or only signs the user out.
• A deletion control the reviewer cannot find.
• A deletion URL required by Play that is missing, wrong, or behind a login the user no longer has.
• A privacy policy that promises deletion the app does not implement.

The last one is worth dwelling on, because it is the mismatch class rather than the missing-feature class. Store answers, privacy policy, and app behaviour are read as one story. A contradiction between them is a finding whether or not any individual document is wrong on its own.

Where Declora fits

An App Passport generates a Delete Account Public Page as one of the four hosted pages, giving you the reachable URL Google Play asks for, at a stable address that stays live in Safe Mode even after active management ends. Requests submitted there arrive in your Request Inbox with a verification step.

To be exact about the division of labour: Declora delivers and tracks deletion requests. It does not reach into your Firebase project. Deleting the auth record and the associated rows is your app's job, because only your code knows where the identifier went. What the product does is make sure your Apple answers, your Google Play answers, and your published pages describe the same deletion behaviour — and the Consistency Check flags it when they do not.

FAQ

Does Apple accept a deletion request form on my website instead of an in-app flow?

Not as a replacement for in-app initiation. If users can create an account in the app, they must be able to start deletion in the app. A web page is a useful addition — and Google Play expects one — but it does not substitute.

Is deleting the Firebase Auth user enough?

Only if the Firebase user ID appears nowhere else. In most apps it appears in Firestore documents, storage paths, subscription records, or analytics user properties, and those need handling too.

Can I retain some data after an account deletion?

Yes, where you have a genuine reason such as a legal retention obligation, financial records, or fraud prevention. State what is retained and why rather than describing the outcome as complete erasure.

Do I need a separate deletion URL for Google Play?

Yes. Play's requirements include a web-based path a user can reach without installing the app. A generated Delete Account Public Page provides that URL at a stable address.

Does Declora delete my users' data for me?

No. Declora delivers verified deletion requests to your Request Inbox and generates the Public Pages and store answers that describe your process. Your app performs the deletion. Declora is not a law firm, does not provide legal advice, and cannot guarantee approval by Apple, Google, or any regulatory authority.