App Account Deletion Requirements: What Apple and Google Actually Check

App account deletion requirements say that any app offering account creation must also let people delete that account and the data behind it. Apple wants the path inside the app. Google wants it inside the app and on the web as well. Miss either one, and your release stops.

You’ve almost certainly shipped a Delete Account screen already. The harder question is whether it satisfies both stores, because the two rules aren’t identical. Teams that solved this once for iOS are routinely non-compliant on Android without ever being told.

Getting it wrong is rarely a one-day fix. A rejection burns a review cycle you’d budgeted for launch. Worse, a live app pulled during a policy rescan costs revenue while you rebuild and resubmit. Neither outcome shows up in a code review, because nothing is technically broken.

This guide covers what each store checks and why a deactivation toggle doesn’t count. It also shows how to confirm your flow works before a reviewer does it for you. If you’d rather hand that verification to a team who runs it every week, that’s what our compliance testing services are for.

What App Account Deletion Requirements Mean, and Who Has to Comply

Strip away the policy language and the rule gets short. If people can create an account in your product, they must be able to remove it without leaving the app. The record disappears, and so does the personal information attached to it.

You’re in scope if any of these describe your app:

• Any App Store or Google Play listing that offers account creation
• Sign-up handled through a social login rather than a native form
• Sign-up that happens on your website instead of in the app
• Onboarding that quietly provisions an account for the user

Apple closes the obvious loophole directly. Where an app sends people to a browser to register, it still owes them in-app deletion, and outsourcing the step changes nothing. Therefore, the App Store Review Guidelines put the duty on the app that offered the account.

Two narrow carve-outs exist on Google’s side, where permanently private apps and enterprise device management tools fall outside the policy. Everybody else is covered, so the app store account deletion requirement applies whether your users pay or not.

Apple vs Google: Where Each Account Deletion Requirement Applies

Most teams assume one implementation satisfies both marketplaces. It doesn’t, and app account deletion requirements diverge in exactly one row of this table.

The Apple account deletion requirement is the simpler of the two. It needs one reachable path, initiated in the app, that removes the record rather than parking it. Our App Store compliance testing work treats that as a behavioral check instead of a screenshot.

Google, though, adds a second obligation on top, and that’s where most cross-platform teams trip up. We compared both rulebooks in full in Apple App Guidelines vs Google Play Policy.

Why the Google Play Account Deletion Requirement Catches iOS-First Teams

Here’s the fact that turns a passing iOS build into an Android rejection. Google requires you to “provide users with an in-app path to delete their app accounts and associated data.” Then it adds a second duty: “provide a web link resource where users can request app account deletion.” You need both routes, so it’s not an ‘either, or’ situation.

The reasoning is practical, because somebody who already uninstalled your app can’t tap a button inside it. That person still has an account on your servers, so Google wants a route that survives uninstallation, which no in-app screen can offer.

This is where a lot of the public advice actively misleads. Several widely-read pages state that Google requires deletion from within the app rather than through an external website, which inverts the policy. In fact, Google’s own account deletion requirements ask for both. You declare the web route in the Google Play data safety form that appears on your listing.

That web link carries its own conditions, and they’re testable. Google expects the page to be “functional (for example, loads without error)” and “prominently featured and easily discoverable.” A form behind a login your uninstalled users can’t pass fails on both counts. So does a support address that a human answers eventually.

A missing endpoint is now a recognized rejection trigger rather than an edge case. We covered that among the current Google Play rejection reasons. As a result, verifying the link is routine in our Google Play compliance testing.

Deactivating an Account Isn't Deleting It

Plenty of shipped flows don’t delete anything. They flip a status column, hide the profile, and keep every record exactly where it was. That reads as deletion to the user, yet as retention to a reviewer. Unsurprisingly, both stores have closed that door in writing.

Google’s User Data policy is blunt: “Temporary account deactivation, disabling, or ‘freezing’ the app account does not qualify as account deletion.” It adds that removing the account obliges you to remove the associated user data as well.

Apple lands in the same place from the other direction. Its guidance on account deletion says that “only offering to temporarily deactivate or disable an account is insufficient.” Apple also counts user-generated content shared with other people as account data. Photos, posts, and reviews are therefore all in scope.

It’s worth being honest about why this pattern is so common. Soft deletion is genuinely good engineering for recovery, billing disputes, and abuse investigations. However, it only becomes a compliance problem when nothing ever finishes the job. That gap is usually a missing background process rather than a bad decision.

One Screen, Five Systems: What Sits Behind the Delete Button

For an executive weighing where QA budget goes, this is the clearest illustration of hidden complexity in the whole submission process. Deletion occupies a single screen in your interface. Underneath, however, it reaches into five systems that were never designed to agree with each other.

• Your identity provider, which may hold a token that outlives the local record
• Active subscriptions, where a canceled account can leave a live billing relationship
• Third-party analytics and crash SDKs holding copies you never wrote yourself
• Records you retain on purpose for fraud, tax, or audit reasons
• The web endpoint, which usually runs on different code from the app path

Each one can succeed alone and still leave the account partly intact. A user deletes their profile, then a push notification arrives two days later because one service never got the message. Nothing errored, and the flow reported success.

The failure that costs most is the quiet one. Data you believed was gone stays reachable through an API that nobody re-checked after the deletion feature shipped. Finding that gap is closer to penetration testing than to functional QA, because it means probing for what should no longer answer.

What Changes If You're in a Regulated Industry

If you run a fintech, healthtech, or medtech product, you’ve probably spotted the tension already. Some records legally have to survive a deletion request, and both stores account for that, though less generously than teams expect.

Apple allows apps in highly regulated industries to “use additional customer service flows to confirm and facilitate the account deletion process.” Read that carefully, because it permits an extra confirmation step and not a replacement. Apps outside those industries get no such latitude. Apple says they “should not require people to make a phone call, send an email, or go through other support flows.”

Google’s allowance is about scope instead of route. You may keep specific data for security, fraud prevention, or regulatory compliance, provided you “clearly inform users about your data retention practices.” Partial deletion is therefore legitimate when it’s disclosed, and quietly retaining everything is not.

The practical takeaway is that regulation changes what you delete, never whether users can ask. Meanwhile, declarations now get cross-checked far more aggressively across both stores. We traced that shift in our look at Apple’s AI data sharing guidelines.

How to Test Whether Your Delete Button Actually Deletes

Almost every guide to app account deletion requirements stops at the policy. Most then tell you to add a clause to your privacy notice. None asks the only question a reviewer cares about, which is whether the button does what the screen promises. Here’s the sequence we run.

1. Delete a real account through the in-app path, then try to log back in with the same credentials.
2. Repeat the whole exercise through the web route, from a device that never had the app installed.
3. Check the identity provider directly and confirm any social login token was revoked, not orphaned.
4. Query your own APIs for the deleted user by ID, not by search, and confirm nothing still answers.
5. Verify an active subscription ends up canceled or clearly explained rather than silently billing.
6. Wait 48 hours, then watch for push notifications, digest emails, or analytics events tied to that user.
7. Load the public deletion page in a private window and time how long finding it takes.

Step 6 catches more real failures than the rest combined, because asynchronous jobs are where deletion usually breaks. Discoverability is the check teams skip most often, yet a reviewer judges it in seconds.

Not all of this will apply to you. If your app has no accounts, none of it does. Adding a deletion flow to a product without sign-up just wastes a sprint.

Enterprise device management tools and permanently private apps sit outside Google’s policy too. Beyond those cases, assume you’re in scope. Treat any claim of exemption as something to verify before submission, not after a rejection notice lands. Rejections cluster around assumptions like this one, as our breakdown of App Store rejection reasons shows.

How QAwerk Verifies Store Compliance Before You Submit

Store compliance is the kind of niche work most QA vendors skip, because it rewards knowing one rulebook deeply rather than testing broadly. We run App Store and Google Play checks as a standing service. That means we already know which claims reviewers verify and which they merely read.

For a blocked release, speed decides the outcome. Our team extension model puts engineers on your submission in days rather than weeks. A rejected build therefore gets diagnosed while the fix window is still open. We test the behavior behind every declaration, then hand back the evidence in a form you can attach to an appeal.

To find out whether your deletion flow would survive review, request a compliance audit from our team.

FAQ

Does my app need an account deletion feature?

Yes, if users can create an account. App account deletion requirements apply to every App Store and Google Play listing that offers sign-up. Social logins and accounts created during onboarding both count. Google exempts only permanently private apps and enterprise device management tools. Everything else needs a working path that removes the account and its data, not one that hides it.

What are Apple's account deletion requirements?

Apple requires apps that support account creation to let people start deletion inside the app, a rule in force since June 30, 2022. The account record and its personal data must go, including content shared with other users. Offering only a temporary deactivation is explicitly insufficient, and non-regulated apps cannot push users into email or phone support instead.

Is deactivating an account the same as deleting it?

No, and both stores say so in writing. Google’s User Data policy states that temporary deactivation, disabling, or freezing an account does not qualify as deletion. Apple calls a deactivate-only option insufficient. If your flow flips a status flag and keeps the underlying records intact, it fails review even though users see a confirmation message.

Do I need a web page for account deletion on Google Play?

Yes, Google requires an in-app deletion path and a web link resource, not one or the other. The web route exists for people who already uninstalled your app and can no longer reach an in-app screen. That page must load without errors and be easy to find. You declare its URL so it appears on your Play Store listing.