Neither store tells you how long to keep customer data. Both make you publish the answer you chose.
Apple and Google require you to have a retention policy, to publish it where people can read it, and, if your app has accounts at all, to delete an account and the data attached to it when the person asks. Neither one names a number of days, months or years. The only figure either of them prints is 90 days, and it sits in an optional Google Play badge rather than in a limit. So the answer is the unsatisfying one: keep customer data as long as you have a reason you can say out loud, and no longer than that. The law where your business is registered sets the real clock, and it is the only party here that can fine you. Every rule and quote below comes from Apple's and Google's own documentation, read on 16 October 2026.
What follows is what each store actually requires, what has to disappear when a customer asks, which records normally survive that request, and what the policy you publish has to contain. It is an afternoon of work once, then two minutes in your release checklist.
Start hereThe short version
Keep what you can justify, delete the rest on request.
Retention is left to you and to the law where your customers are. Apple's App Store Review Guidelines, at guideline 5.1.1(i), make your privacy policy explain your data retention and deletion policies and describe how a user can revoke consent or request deletion of their data. Google Play's User Data policy lists the developer's data retention and deletion policy as required privacy policy content. Both sentences assume you already chose a period. Neither of them tells you what it should be.
The test that survives both stores is simple enough to do with a pen. For every table in your database, write down why the data is still there. A reason like the customer may book again is fine. A reason like we might need it one day is how you end up explaining a breach that covered four years of orders nobody was using. Apple says apps should only collect and use data that is required to accomplish the relevant task, at guideline 5.1.1(iii). Google says to only collect and use data that is necessary for your app's functionality. Deleting data you stopped using is the cheapest security work available to you.
Do Apple or Google set a retention period?
No. Both were read on 16 October 2026 and neither one publishes a period. What they publish is a duty to disclose yours. Apple's guideline 5.1.1(i) requires the privacy policy to explain its data retention and deletion policies, and to describe how a user can revoke consent or request deletion of their data. Google's User Data policy puts the developer's data retention and deletion policy on the list of things a privacy policy has to contain, then goes one step further on the why: if you need to retain certain data for legitimate reasons such as security, fraud prevention or regulatory compliance, you must clearly inform users about your data retention practices.
One number does appear, and it is worth understanding before you quote it at anyone. Google Play Console Help, on the Data safety section, says you may select the data deletion badge if you automatically initiate deletion or anonymization of collected data within 90 days of collection. That is a claim you are allowed to make, not a deadline you have been handed. The same page defines processing data ephemerally as accessing and using it while it is only stored in memory, retained no longer than necessary to service the specific request in real time. Those two sentences are the only retention standards either store writes down, and one of them is a badge.
Which leaves the figure where it always was. Sales records, tax records and anything you hold to defend a chargeback are governed where your business is registered, not by an app store. Ask whoever files your returns, write the answer down, and put it in the policy. What both stores require is that the policy exists, that people can reach it, and that it describes what your app actually does. Neither of them audits the number you chose.
Apple, App Store Review Guidelines, guideline 5.1.1, read 16 October 2026
Go table by table
What you keep, and what goes on request
Tick what your app stores. For each one, the reason it is still there and what happens when a customer asks you to delete them.
Nothing ticked. An app that keeps everything on the phone has no retention policy to write and nothing to delete on request.
What has to go when a customer asks?
The account, and the data attached to it. Apple's guideline 5.1.1(v) is one sentence long: if your app supports account creation, you must also offer account deletion within the app. Apple's App Review Help page on offering account deletion, read on 16 October 2026, spells out what that means. Deleting an account 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. Offering only to temporarily deactivate or disable an account is insufficient. And the deletion covers user generated content shared with others, which Apple spells out as photos, videos, text posts and reviews.
Google asks for the same thing twice over. Its User Data policy says an app that lets users create an account must let them request deletion of it, available both from inside the app and externally through a designated web resource, with a link to that resource entered in a designated URL field in Play Console. When you delete an account on request you must also delete the user data associated with it, and temporary deactivation, disabling or freezing the account does not qualify as account deletion. An app on both stores therefore needs the in app route Apple wants and the public web page Google wants, pointing at the same process.
Read against retention, the request is the only deadline either store hands you, and it is not a period: it is whenever somebody asks. That has two consequences for how you store things. Apple says that if the deletion takes time to complete you should tell the person how long and confirm when it is done, so a nightly job is acceptable and silence is not. And automatically generated accounts, the guest ones nobody finished, have to be deletable too, which means the rows with no owner to ask are the ones to stop creating. A table you cannot delete a single person from is a retention problem with a deletion label on it.
One trap before you ship it. If the person has an auto renewable subscription, Apple tells you to notify them that billing will continue through Apple and to ask them to cancel before continuing. Deleting their row does not stop the money, and a charge after a deletion is a refund request with a bad story attached. The screen itself is an ordinary app update, so it can go out behind a phased release while you watch who taps it and whether anyone taps it by mistake.
Google Play Console Help, User Data policy, read 16 October 2026
Which records survive a deletion request?
The ones you can point at a law for, and that is the whole carve out. Apple's wording deletes any data associated with the account that the developer is not legally required to maintain, which by definition leaves what you are required to maintain. Google's version allows data retained for legitimate reasons such as security, fraud prevention or regulatory compliance, as long as you clearly inform users about those retention practices. Neither store lists the laws. Neither gives you a period. Both put the burden of explaining it on your privacy policy.
In a small business app the survivors are usually the same three things. The sale, because your tax authority wants the record of it. A fraud or abuse record, because the whole point of it is the person you stopped serving. And whatever your payment provider holds, which was never yours to delete in the first place. The design decision that makes all of this easier is separating the invoice from the account. A receipt can carry a name and an amount without dragging along a login, an address book and two years of session history.
The payment layer settles a lot of this before you write a line of policy, because the record of a purchase lives wherever the purchase happened. A store subscription is on the store's books. A card payment is on your processor's. If that is still open, then which payment layer to use is the decision sitting upstream of your retention policy, and it is worth making in that order.
Then write the survivors down before anyone asks. Apple is explicit about this: if you are legally required to retain some user information, let people know what information will and will not be retained. A deletion confirmation that lists what stayed and why reads as competence. The same sentence produced three weeks later, after a complaint, reads as an excuse. The text costs you ten minutes and it is the only part of this whole subject a customer will ever actually read.
What does your retention policy have to say?
Apple asks for three things in the privacy policy, and the link to it goes in both your App Store Connect metadata and inside the app in an easily accessible manner. Identify what data the app or service collects, how it collects it, and all uses of that data. Confirm that any third party you share user data with will provide the same or equal protection of user data as your policy states and the guidelines require. And explain your data retention and deletion policies, with how a user can revoke consent or request deletion of their data. The third one is the sentence this page exists for, and it is the one most templates leave as a placeholder.
Google's list is longer and more mechanical. The policy has to be clearly labelled as a privacy policy, for example with privacy policy in the title. It needs developer information and a privacy point of contact or a mechanism to submit inquiries. It has to disclose the types of personal and sensitive user data the app accesses, collects, uses and shares, and the parties it is shared with. It needs your secure data handling procedures. And it needs the developer's data retention and deletion policy. A policy that answers Apple's three points but has no contact route still fails Google's.
The hard part is the third party line, because it is a promise about other companies. Apple makes you confirm that any third party you share user data with, and it names analytics tools, advertising networks and third party SDKs along with parent and subsidiary entities, will provide the same or equal protection as your policy states. You cannot write that honestly without knowing how long each vendor keeps what you send it. Check the vendors first, then write the policy. Doing it the other way round is how a template ends up making a claim you cannot support.
Then put the review on a date. A retention policy goes stale the first time somebody adds an SDK or a table, and a policy that no longer describes what the app does is no longer the policy either store asked for. The cheap version of the habit: when you cut a release, ask what new data it stores and for how long. Two minutes, in the same checklist as the screenshots and the release notes.
Apple, App Store Review Guidelines, guideline 5.1.1(i), read 16 October 2026
The same question, answered differently by each store
| On retention and deletion | App Store | Google Play | Same answer on both |
|---|---|---|---|
| Names a retention period | No | No | Yes |
| Any figure at all | None | 90 days, and only as an optional Data safety badge | No |
| Where the delete option must live | Inside the app, with a link out if a website finishes the job | Inside the app and on a web page, URL filed in Play Console | No |
| Freezing the account instead | Not deletion | Not deletion | Yes |
| Retention you keep must be disclosed | Yes | Yes | Yes |
| Who decides how long | You and the law where your customers are | You and the law where your customers are | Yes |
Where this lands if a builder generated your app
Nothing here changes because an agent wrote the code. The retention policy is yours, the delete option is yours to ship, and on iOS you are the one who presses submit. App Store Review Guideline 4.2.6 is the reason: apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. The privacy answers and the retention promise come with that signature.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own, with two way GitHub sync, so nothing above is locked inside a tool. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It is $25 a month, with no free tier. The part that matters for retention is where a new app starts: data on the phone, no accounts and no server. An app that stores nothing off the device has no retention period to choose and nothing to delete on request.
That changes the moment it needs accounts, bookings you can see from a laptop, or payments. From then on you own a database with other people's names in it and every rule above applies exactly as it would to hand written code. Most of the data worth arguing over arrives with the money, so if you are still choosing how the app earns, app monetisation covers the options. Storing less is not a saving worth chasing either, since storage is pennies: what it costs to publish an app shows where the money actually goes. Keep less because it is less to lose, not because it is cheaper.
Questions people ask about keeping customer data
As long as you have a reason you can name out loud, and no longer. Neither Apple nor Google sets a period, so the clock comes from the law where your business is registered and your customers live. The practical method: go table by table, write down why each one is still there, and delete the tables whose reason is that it might be useful one day. Keep the sale because your tax authority wants the record. Keep the fraud record because the point of it is the person you banned. Everything else is a choice you have to be able to defend.
Describe the app, then decide what it keeps
Build the delete option in with the accounts rather than after the first request arrives, and write the retention lines while you still remember which tables exist. Both jobs take an afternoon at the start. Left until someone asks, they take a week and an apology.
Start building