Account Deletion for Streaming Apps: Requirements and a Working Flow

What the stores require

Apple requires that apps supporting account creation also let users initiate deletion of that account from within the app (App Review Guideline 5.1.1(v)). The option should be easy to find, typically in account settings. Temporarily disabling or deactivating the account does not count. If deletion takes time to complete, you may say so, but the user must be able to start it in the app.

Google Play requires the same for apps that let users create accounts, and adds a second requirement: a web link where users can request deletion of their account and associated data without having to reinstall the app. You declare that link in the Data safety section of Play Console, and it must be reachable and working.

Neither store accepts “email us to delete your account” as the only option. An email address can be part of the process, but there has to be a clear button in the app and, for Google, a page on the web.

Design the in-app flow

Put Delete Account under Account or Settings, close to Sign out, not hidden behind Help. Use a two-step confirmation: the first screen explains what will be deleted and what will be kept; the second asks for confirmation, ideally with a fresh sign-in or password entry so a family member on a shared TV cannot delete the owner’s account by accident.

1. User taps Delete Account and sees a plain summary: profiles, watch history, favorites and devices will be removed; invoices and payment records are kept as required by law.
2. If the user has an active subscription billed by Apple or Google, the screen explains that deleting the account does not cancel the store subscription, and links to the store’s subscription settings.
3. User confirms, re-entering their password or re-authenticating with their sign-in provider.
4. The app submits the request, signs the user out on this device, and shows a confirmation with the expected completion time.
5. The backend records the request, revokes sessions on all devices, and either deletes data immediately or queues it for a scheduled job.

Television apps deserve a thought. Typing a password on a TV remote is painful, so many services let users start deletion on TV by showing a code or QR link to the web deletion page. That is acceptable as long as the path is clearly offered from the TV app’s settings.

Handle store-billed subscriptions carefully

This is the part most teams get wrong. If a subscription was bought through Apple or Google, your backend cannot cancel it — only the user can, in the store’s subscription settings. If you delete the account but the subscription keeps renewing, the user is charged for a service they can no longer reach, and you will receive refund requests and complaints.

Apple’s guidance is to inform users that the store subscription continues until they cancel it, and to show them how. Do this on the confirmation screen, and repeat it in the confirmation email. Some services also check at deletion time whether a store subscription is active and show a stronger warning in that case.

For subscriptions you bill directly, cancel the recurring payment as part of the deletion job and stop any retry or dunning schedule, so the payment provider does not keep attempting charges against a deleted customer.

Build the web request page

The web page Google requires should be reachable without installing the app, should name the app and the developer as they appear on Google Play, and should explain the steps. The simplest version asks the user to sign in and then offers the same Delete Account action as the app. A version that works for users who cannot sign in collects the account email and sends a verification link, so nobody can delete another person’s account by typing their address.

Make the page part of your main website, link it from the privacy policy, and keep the URL stable. If you change domains or restructure the site, redirect the old URL. A deletion link that returns “page not found” during review is treated as a missing feature.

Decide what to delete and what to keep

Write down, per table or data store, what happens to each kind of data. This list is also what your privacy policy should summarize, so both say the same thing.

• Delete: profile names and avatars, watch history and continue-watching positions, favorites or “My List”, search history, device registrations, push tokens, active sessions, and marketing preferences.
• Delete or anonymize: the account record itself. Many services replace the email and name with a random value and keep a minimal stub, so that historical records referring to the user ID stay consistent without identifying anyone.
• Keep for the legal period: invoices, tax records, payment and refund records, and records needed for chargebacks or fraud disputes.
• Keep in aggregate only: analytics that have been aggregated and no longer identify the person, such as total viewing minutes per title.
• Outside your control: data already sent to an ad provider or analytics vendor, which is retained under their policies. Mention this in your policy.

Also cover backups. Deleted data will persist in backups until they expire; state your backup retention period and make sure restored backups do not bring deleted accounts back to life.

Make requests visible to your team

A deletion request that disappears into a log file is a compliance risk. Route every request into a place a person checks — typically your support or helpdesk system — with its own issue type such as “account deletion”, a high priority, and a target completion date. If you automate the deletion itself, the ticket still serves as the audit trail: who asked, when, when it was completed, and by which job.

Give support staff a filter for these tickets and a short runbook: verify the request came from the account holder, confirm whether a store subscription is active, run or confirm the deletion job, and close the ticket with a note. Send the user a confirmation once deletion is complete.

Watch the volume. A sudden spike in deletion requests is an early warning — often of a billing problem, a bad release, or a content change that upset a community.

Test it the way a reviewer will

Reviewers create a fresh account, sign in, and delete it. Do the same before every submission, on the exact build being submitted, against production.

1. Register a new test account with a real mailbox you control, and verify it.
2. Sign in on two devices, so you can confirm the second device is signed out after deletion.
3. Start deletion in the app and confirm the warning about store subscriptions appears when relevant.
4. Check that the request appears in the helpdesk with the right issue type, and that the account can no longer sign in.
5. Repeat the flow through the web deletion page.
6. Confirm the privacy policy describes the same steps and time frame you just observed.

A working deletion flow is one of the clearest signals to a reviewer — and to users — that a service takes their data seriously. It is worth getting right once and testing every release.