A customer asking what you hold on them is answered from a list you already wrote.
The list is the privacy declaration you filled in to get the app published, and it names every place a person's data goes. Start there, not in your database. Two things surprise people when the first email arrives. Neither Apple nor Google asks you to hand over a copy of anybody's data: the only user request either store documents is deletion. And the hard part is not finding the data, it is proving that the stranger in your inbox is the customer whose data they are asking for. Everything quoted below comes from Apple's and Google's own documentation, read on 16 October 2026. Most people meet their own declaration for the first time while publishing to the App Store.
What follows is who actually obliges you, how to identify the person asking, what you assemble and from whom, and what to do when the request turns up in a review or a support inbox instead of a form. An afternoon of work the first time, twenty minutes after that.
Start hereThe short version
Identify the person first. Then read your own declaration.
A data request is three jobs in order, and people usually do them in the wrong order. First, tie the email to an account you can point at, because sending the wrong person a file is a worse outcome than answering late. Second, work out which of the places you declared actually hold something about that account. Third, write back in plain language, including the places where the answer is nothing.
The declaration matters because it is the only complete map of your own app that you are obliged to keep accurate. If your App Privacy answers list purchase history and coarse location, then purchase history and coarse location are two of your answers to the customer. If the declaration is out of date, the request has just found that out for you, which is an uncomfortable but useful thing to learn on a Tuesday.
Does either store make you hand over a copy?
No. This is worth being precise about, because getting it backwards sends people hunting for a store rule that does not exist. Apple publishes app privacy details as a disclosure exercise. You tell Apple what you collect, and Apple shows it to customers: on each app's product page, users can learn about some of the data types the app may collect, and whether that data is linked to them or used to track them. Apple adds that the information is required to submit new apps and app updates to the App Store. Nowhere in that documentation is there a route for a person to ask you for a copy of what you hold.
Google's side reads the same way. The Data safety form asks whether or not you provide a way for users to request that their data is deleted. Deleted. There is no matching question about producing it, and the only export the help page describes is you exporting your own form answers to a CSV file. Google's account-level requirements are about deletion too, in the app and through a web link. So across both stores the single documented customer request is removal, not disclosure.
Which does not mean you can ignore the email. It means the obligation, where there is one, comes from the privacy law that applies to your customer and to your business, and that is a question for a lawyer who knows the countries you sell in. Apple's own guidance says to follow applicable legal requirements and, if you have questions about your legal obligations, to check with your legal counsel. The useful consequence is that you stop looking for a guideline number to comply with, and start deciding what kind of business you want to be when somebody asks a fair question. Most small teams answer, because answering takes an hour and arguing takes a week.
Apple, app privacy details on the App Store, read 16 October 2026
How do you know the person asking is the customer?
You do not, until you check. A request arrives as an email address and a first name. Your app knows people by a user ID, and joins everything else to it. So the whole job is getting from the thing in your inbox to the thing in your database, without guessing. Your own Data safety answers tell you which identifiers you hold, because you had to select every user data type the app collects and then answer how each one is used and handled. Whichever identifier is the join key is the one the request has to resolve to.
The safe procedure is boring on purpose. Look up the account whose email address matches the sender exactly. Reply to the address on the account, never to a different address supplied in the message, and never to a forwarding address added during the conversation. If the person is signed in, the better route is to answer inside the app, where identity is already settled. If no account matches, say that you hold no account under that address and stop. Do not search by name, do not match on a partial, and do not helpfully look for nearby accounts. Guessing which stranger owns which account is exactly how one customer receives another customer's data.
Two cases need a decision in advance rather than in the moment. Someone asking on behalf of another person, such as a parent or an employer, which you should not answer without evidence you can keep. And an account the app created on its own, with no email address attached, where there may be nothing you can tie to a human at all. Write both answers down once, in whatever passes for your support notes, so the second request does not restart the argument.
What do you actually have to assemble, and where does it sit?
Start with the test that decides whether you hold anything at all. Apple's wording is the clearest in either store: collect refers to transmitting data off the device in a way that allows you and/or your third-party partners to access it for a period longer than what is necessary to service the transmitted request in real time. Read that twice before you panic. If your app writes to the phone and nothing else, you have no copy of anybody, and the honest reply is short.
The moment anything does leave the device, the data is in more places than your own tables, and the word that does the damage is partners. Apple defines third-party partners as analytics tools, advertising networks, third-party SDKs and other external vendors whose code you have added to your app. That is the list of people you now have to ask. A crash reporter you never open holds stack traces with a user ID in them. An analytics SDK holds a timeline of what that person did. Payment records sit wherever you decided which payment layer to use, and the card detail itself is held by the processor or the store, not by you.
Two things stop this becoming infinite. Write the query once and keep it, because the second request will arrive and so will the third, and a saved query turns an afternoon into twenty minutes. And answer for what you hold, not for what the world holds. You are not obliged to reconstruct a person's life from the internet. You are obliged not to leave out a store of data because remembering it was inconvenient.
Apple, app privacy details on the App Store, read 16 October 2026
Build the list
Where their data actually sits
Tick what your app has. Each one is a place to look and a person to ask before you reply to the customer.
Nothing ticked. An app that never sends anything off the phone holds no copy of anybody, and that is a complete and honest answer to the email.
What if it arrives in a review or a support inbox?
It will, and you chose the channel yourself without noticing. Google is explicit that the Data safety section provides a surface for you to share if you provide a mechanism to receive data deletion requests from your users, and that there is no prescribed mechanism. Its own examples of an acceptable one are in-app features, contact forms, or a dedicated email alias. Whatever you declared is what customers will read on your listing, and it is where they will go. A dedicated alias is the version that survives contact with a real support inbox, because it does not depend on anybody noticing the word data in a thread about a crash.
A store review is the channel you did not choose. A reply to a review is published on your product page where every future customer reads it, so no account detail, no email address and no file goes in there. Post one line pointing at the route you declared, then handle the request privately. The request counts from the day you saw it, not from the day it reached a tidier queue, so log it immediately. The same goes for a request that arrives through social media or in a reply to a marketing email.
One rollout detail catches teams who build an in-app request screen rather than using an alias. If the screen shipped in a phased release, most of your installed base cannot see it yet, and the people on the old build will email you instead. Keep the alias alive alongside the screen, and keep answering both until the release is fully out.
The same request, as each store documents it
| The point | App Store | Google Play | Same on both |
|---|---|---|---|
| The user request each store provides for | Deletion of the account and its data | Deletion of the account and its data | Yes |
| A documented route for a copy of the data | None in the documentation | None in the documentation | Yes |
| Where your own inventory of the data lives | App Privacy, in App Store Connect | Data safety, on the App content page | No |
| Data your SDKs collect counts as yours | Yes | Yes | Yes |
| What the customer can read before asking | Data types, and whether they are linked or used to track | Collected, shared, and whether you take deletion requests | No |
| Who is answerable for those statements | You, the developer | You, the developer | Yes |
Where this lands if a builder generated your app
It lands on you, and the fact that an agent wrote the code makes it easier rather than harder, because you can read the project. Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project you own, with two-way GitHub sync, so the schema and the queries are sitting in a repository you can open. 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. None of that changes what it costs to publish an app, and none of it answers an email for you.
Where a generated app starts is the part that matters here. A new app is local first: data on the phone, no accounts, no server. By Apple's own test that is nothing collected, so the first data request you ever get has a one paragraph answer. That changes the moment the app needs accounts, shared data, syncing or payments. The agent then adds a backend with sign-in, an API service, a Postgres database per environment and file storage, and from that point there is a real list to assemble.
The practical move is to ask the agent for the request path while you are still building, not after the first email. A screen that pulls everything keyed to the signed-in user, a saved query you can run by hand, and an alias on your domain that goes somewhere a human reads. The honest limit is the same as everywhere else in this job: no tool knows which of your vendors holds what, because only you know what you added and why.
Questions people ask about a customer data request
Not from Apple or Google. Both stores document one request a person can make of you, which is deletion of their account and the data attached to it. Neither Apple's app privacy documentation nor Google's Data safety documentation contains any route for a person to ask for a copy, an export or a download of what you hold, read on 16 October 2026. Whether your customer has that right comes from the privacy law that covers them and your business, which is a question for a lawyer and not for App Review. Treat the store rules as the floor and the law as the ceiling.
Build the answer before anybody asks the question
One query, one alias, one page of notes on who holds what. Do it in the week you launch and the first request becomes a twenty minute job instead of a bad weekend.
Start building