Deleting a user and their data is one job, and a disabled login is not it.
If your app lets people create an account, both stores make you let them delete it, and deleting it means the account record plus the data attached to it. Apple requires the option inside the app. Google requires the same thing inside the app and a web page where the request can also be made. Neither accepts a switch that hides the account and keeps the rows. Every requirement below comes from Apple's and Google's own documentation, read on 16 October 2026. Build the delete path at the same time as the sign-up path, because retrofitting it means finding every table that holds a user id, and that is the kind of work that shows up in what an app costs to maintain.
What follows is what each store actually says, what counts as the user's data, what you are allowed to keep, and how to build the path so it does not leave half a person behind in your database.
Start hereThe short version
One button in the app, and a real cascade behind it.
The store-facing part is small. A person signed into your app has to be able to start the deletion from inside the app, in a place that is easy to find, which in practice means account settings. Apple adds that you may link out to a web page if the process finishes there. Google requires the web route whether or not your process needs it, and wants the URL in the Data safety form.
The expensive part is behind the button. The account record goes. So does the profile, the content, the uploads, the copies sitting in your email tool and your analytics, and anything a processor holds on your behalf. What you may keep is narrow: data the law requires you to keep, or data you need for security, fraud prevention or regulatory compliance, and in both cases you have to tell people. A delete that only removes the login is the version that fails.
What does Apple actually require?
The rule sits in App Store Review Guideline 5.1.1(v), Account Sign-In, and the detail sits on Apple's own guideline reference page for it. Apps submitted to the App Store that support account creation must also let people initiate deletion of their account within the app. Apple's definition of deleting is worth reading twice: it removes the account from the developer's records, along with any data associated with the account that the developer is not legally required to maintain. Apple's developer news, dated 24 May 2022, said the requirement starts on 30 June 2022, a deadline it had already extended once, so this has been enforced at review for years rather than months.
Three sentences on that page kill three popular designs. Only offering to temporarily deactivate or disable an account is insufficient, so the soft switch is out as the only option. The option has to be easy to find in the app, typically in account settings, so burying it is out. And apps outside highly regulated industries should not require people to make a phone call, send an email, use a chat support flow or go through other support flows, so the contact-us answer is out. Apple does allow a web finish: if people need to visit a website to complete the deletion, link directly to that page, and on tvOS present a static URL or a QR code that goes straight there.
The documented exception is a process, not an exemption. Apps in highly regulated industries, as described in guideline 5.1.1(ix), may use additional customer service flows to confirm and facilitate deletion. That guideline names banking and financial services, healthcare, gambling, legal cannabis use, air travel and crypto exchanges. The account still has to be deletable. Apple is also explicit that there is no regional carve-out: everyone should be able to delete their accounts regardless of where they are located. Automatically generated guest accounts count too, which surprises people who thought a silent account was not an account.
Two implementation details come straight from the same page. If your app offers Sign in with Apple, use the Sign in with Apple REST API to revoke user tokens, and use server-to-server notification endpoints to process changes. And if the person has an auto-renewable subscription, tell them billing will continue through Apple and ask them to cancel before continuing. You may offer to schedule the deletion for when the subscription expires, as long as deleting immediately is also on the screen. Confirmation steps and identity checks are fine, including a code sent to an email or phone already on the account, but an app that makes deletion unnecessarily difficult will not pass review. Getting this wrong is a plain rejection, which is one of the more avoidable entries in why apps get rejected.
Check yours
What a delete has to reach
Tick every place your app keeps something about a person. Each one is a separate piece of work, and the last one is the easy case.
Nothing ticked. An app that stores nothing about a person has no account to delete and no form to fill in.
Does Google Play want a web page too?
Yes, and this is the difference people miss when they port an iOS app across. Google's User Data policy asks for two routes. If your app allows users to create an account from within the app, you provide an in-app path to delete the account and its associated data, and you provide a web link resource where users can request account and data deletion. The in-app path alone does not satisfy it. The web link has three conditions: it has to work, it has to be relevant, with the deletion route easy to find on the page it opens, and it has to reference the app or developer name as it appears on your store listing.
The link is not a loose promise either. It goes into the Data safety form in Play Console, where the Data deletion questions live, and Google surfaces the answer publicly: once the form is approved, a Data deletion area appears on your store listing. The timeline is worth knowing because it explains why older apps already have this. Google announced the requirement in April 2023 and added the Data deletion questions to the form then, set 7 December 2023 as the deadline to answer them with an extension available to 31 May 2024, and started showing the badge on listings in early 2024. Apps that are still not compliant may face enforcement, up to removal from Google Play.
Google's exemption list is short and specific, and unlike Apple's it does exempt some apps from the requirement itself: permanently private apps and enterprise device management apps. Non-mobile apps do not have to offer deletion from inside the app, but still need a discoverable route outside it and still enter the URL in the designated field in Play Console. And accounts that are created and operated offline are not app accounts, so they fall outside the policy entirely. If your app keeps a profile on the device and never sends it anywhere, you are in that last category.
Two more clauses change how you design the screen. Partial deletion is allowed, because the policy covers requests to delete the account and other data where applicable, so you can offer to clear a history without closing the account. And if a person has to do something before deletion can go ahead, such as cancelling a subscription, that step must be clearly outlined and a support flow must be available for them to start. In other words you may have prerequisites, as long as you spell them out and someone is there when the person gets stuck.
What counts as their data, and what can you keep?
Each store answers this from a different direction, and running both answers together gives you the real scope. Apple describes it by expectation: people expect that all data associated with their account will be deleted when the account is deleted, and that includes user-generated content shared with others, such as photos, videos, text posts and reviews. Google describes it by your own disclosure: delete the user data associated with that app account, and the scope is the data you marked as collected in the Data safety section. So the Data safety form you filled in last year is now a checklist for the delete job.
The shared-content line is the one worth arguing about internally before review does it for you. A review the person wrote, a photo in a group feed and a comment on someone else's post are all in scope by Apple's wording. If removing them would break what other people see, decide now whether you delete the content or unlink it and strip every identifier from it, and write that into your privacy policy. Hiding a post and deleting a post look identical to the author and different to anyone reading your database.
The retention side is narrower than most privacy policies imply. Apple's position is that the account and its associated personal data go, except data you are legally required to maintain, and that if local laws or regulations require you to keep some of it you let people know what will and will not be retained. Google allows retention for legitimate reasons such as security, fraud prevention or regulatory compliance, and requires you to tell users about those practices clearly, for example in the privacy policy. Both of those are exceptions you can point to a reason for. Neither is a licence to keep the profile because deleting it is awkward.
Then there are the copies you do not control. Google is explicit that you delete the data from your own servers and ask your service providers to do the same. Read your own integration list and you will usually find four or five: the transactional email service, the support inbox, the analytics project, the crash reporter, the warehouse somebody set up to answer a question once. Each one needs a documented route, and a few of them only offer a manual one. This is why the delete feature is never a one-day job, however small the button looks.
How do you build the delete path without breaking the app?
Start from the data, not the screen. Write down every table that holds a user id and every bucket prefix that holds their files. Order them so that children go before parents. Then decide, per table, whether the row is deleted or anonymised, and whether anonymised means the user id becomes null or the whole record is replaced by a counter. An order history that has to survive for tax reasons is a different decision from a step count, and both belong in the same document.
Make the server the thing that deletes, and make it safe to call twice. The app sends one request and shows a confirmation; the server works through the list, writes down where it got to, and can resume. Deletions time out in the middle more often than anything else in this feature, and a half-finished delete that cannot be retried is the worst state to be in, because the person has already been told it happened. Revoke sessions and tokens first, so nothing signs back in while the cascade is running, and for Sign in with Apple make the token revoke call part of the job rather than a step somebody remembers.
Then test it like a feature, because it is one. Create an account, fill it with content, upload a file, start a subscription in the sandbox, delete it, and go looking for leftovers in every store you own, including the search index and the cache. Sign up again with the same email and check that nothing from the old account comes back. Do this on a build you are about to ship rather than on your laptop, and keep the result next to your release notes so the next person knows which version numbers the behaviour changed in.
Finally, write the words on the screen as carefully as the code behind it. Apple asks you to say how long the deletion will take, confirm when it is complete, explain what happens to billing, and list what you are legally required to keep. Google asks you to outline any prerequisite step and to offer a support route for it. That is four or five sentences in the app and one page on your website, and between them they answer almost every support ticket this feature produces. The screen is cheap. The honesty is what keeps it out of a review rejection.
The same requirement, written two different ways
| The question | App Store, guideline 5.1.1(v) | Google Play, User Data policy | Same on both |
|---|---|---|---|
| Where the delete option lives | Inside the app, usually in account settings | An in-app path, and a web link as well | No |
| A web page is required | No | Yes | No |
| The account's data goes too | Yes | Yes | Yes |
| Documented exemptions | None published for offering it at all | Permanently private and enterprise device management apps | No |
| What you fill in outside the app | No form, the option in the app is the requirement | The Data deletion questions in the Data safety form | No |
| Keeping data the law requires | Allowed, and you tell people what is kept | Allowed for security, fraud prevention or regulatory compliance, disclosed to users | Yes |
Where this lands if a builder generated your app
The requirement does not move because an AI wrote the code. Review looks at the app, and the app either has a delete option in account settings or it does not. The part that matters is whether you can read the code well enough to know what the delete actually touched, because no tool can tell you which of your tables you consider personal data.
Newly is an AI app builder. You describe an app in plain English and it generates a real React Native and Expo project that you own, with two-way GitHub sync, so the project is in your repository and you can search it for every place a user id appears. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It does not submit to the App Store for you, because Apple requires the owner of the content to submit, which means you are the person whose app is tested against guideline 5.1.1(v). It costs from $25 a month and there is no free tier, which is part of what it costs to publish an app.
The practical advice for a generated app is the same as for a handwritten one, in a different order. Ask for the delete screen in the same sentence as the sign-up screen, so the two arrive together and the cascade is written while the schema is small. Then read what it produced. An agent will happily delete the rows it knows about, and the leftovers are always in the places that were added later: the storage bucket, the email list, the analytics project. Keep the app local-first for as long as you can, with the data on the phone and no accounts at all, and the whole requirement does not apply to you yet.
Questions people ask about deleting a user and their data
If it lets them create one, yes, on both stores. Apple's account deletion page states that apps submitted to the App Store that support account creation must also let people initiate deletion of their account within the app. Google's account deletion policy says an app that allows users to create an account from within the app must provide an in-app path to delete the account and its associated data, and a web link where the same request can be made. Read on 16 October 2026. An app with no accounts has neither requirement.
Build the delete path with the sign-up path
Ask for both screens at once, while the schema is four tables and the cascade is obvious. It is an afternoon now and a fortnight of archaeology later.
Start building