Quick answer
Google's Data safety form and Apple's App Privacy labels both appear on your store page. You declare them yourself, you are solely responsible for accuracy, and a wrong declaration can block updates or remove the app.
What are these, in plain terms?
> Quick answer: Both stores show a privacy summary on your product page, above or beside your screenshots. You fill it in yourself. Nobody checks it for you, and getting it wrong can get your app removed.
Google calls it the Data safety section. Apple calls them App Privacy labels.
They ask similar things in different shapes, and both are part of your listing whether you think of them that way or not.
Google calls it the Data safety section. Apple calls them App Privacy labels.
They ask similar things in different shapes, and both are part of your listing whether you think of them that way or not.
Why a design site cares about a form
Because it sits on the same page as your screenshots and readers see it.
You can spend a week on caption copy and lose the install to a privacy card that says you collect precise location when you do not.
It's listing surface. Same page, same visitor, same decision.
It's also the one part of the listing that can get the whole app pulled, and none of your images can do that.
So it belongs in the same checklist as everything else. Our Play listing asset checklist covers the visual half.
You can spend a week on caption copy and lose the install to a privacy card that says you collect precise location when you do not.
It's listing surface. Same page, same visitor, same decision.
It's also the one part of the listing that can get the whole app pulled, and none of your images can do that.
So it belongs in the same checklist as everything else. Our Play listing asset checklist covers the visual half.
What Google's form actually asks
Eight data groups, and you declare each one.
Location, split into approximate and precise. Personal info. Financial info. Health and fitness. Messages. Media. App activity. Device IDs.
For each one, Google's documentation asks whether the data is collected, shared, or both.
Then whether it is processed ephemerally, meaning held in memory and never stored.
Then whether collection is required or optional for the user, and what the purposes are.
Location, split into approximate and precise. Personal info. Financial info. Health and fitness. Messages. Media. App activity. Device IDs.
For each one, Google's documentation asks whether the data is collected, shared, or both.
Then whether it is processed ephemerally, meaning held in memory and never stored.
Then whether collection is required or optional for the user, and what the purposes are.
The two questions people answer wrong
Two of Google's questions catch almost everybody out.
Encryption in transit. If your app talks to any server over plain HTTP anywhere, you cannot claim it. Most teams answer yes without checking every call.
Data deletion. You are asked whether users can request deletion of their data. If you say yes, there has to be a real route for them to do it.
Both of those are verifiable by anybody who looks, which is what makes them risky.
Answer them from your actual code, not from what you intend to build.
Encryption in transit. If your app talks to any server over plain HTTP anywhere, you cannot claim it. Most teams answer yes without checking every call.
Data deletion. You are asked whether users can request deletion of their data. If you say yes, there has to be a real route for them to do it.
Both of those are verifiable by anybody who looks, which is what makes them risky.
Answer them from your actual code, not from what you intend to build.
What Apple's labels show
Apple splits the display into three groups rather than one list.
Data used to track you. Data linked to you. Data not linked to you.
The categories underneath cover contact info, health and fitness, financial info, location, sensitive info, contacts, user content, browsing history, identifiers, purchases, usage data, diagnostics and surroundings.
Those three top groups are what the reader sees first, and the order is deliberate. Tracking is at the top because it is the one people react to.
So an app with anything in the tracking box is starting the conversation from behind.
Data used to track you. Data linked to you. Data not linked to you.
The categories underneath cover contact info, health and fitness, financial info, location, sensitive info, contacts, user content, browsing history, identifiers, purchases, usage data, diagnostics and surroundings.
Those three top groups are what the reader sees first, and the order is deliberate. Tracking is at the top because it is the one people react to.
So an app with anything in the tracking box is starting the conversation from behind.
What tracking actually means to Apple
This is the definition worth reading twice, because people guess it.
Apple's own wording is linking data collected from your app about a particular user or device, such as a user ID, device ID or profile, with third party data for targeted advertising or advertising measurement, or sharing that data with a data broker.
So it isn't "do you have analytics". It's specifically about joining your data to somebody else's for advertising, or handing it to a broker.
Plenty of apps declare tracking when they do not track, because they read the word rather than the definition.
Read the definition. It may cost you nothing to declare nothing.
Apple's own wording is linking data collected from your app about a particular user or device, such as a user ID, device ID or profile, with third party data for targeted advertising or advertising measurement, or sharing that data with a data broker.
So it isn't "do you have analytics". It's specifically about joining your data to somebody else's for advertising, or handing it to a broker.
Plenty of apps declare tracking when they do not track, because they read the word rather than the definition.
Read the definition. It may cost you nothing to declare nothing.
Your SDKs count as you
The line most teams miss, and it is stated plainly.
Apple's wording is that you need to identify all of the data you or your third party partners collect.
So an advertising SDK, an analytics SDK, a crash reporter and a payment provider all become your declaration.
You cannot answer this form by reading your own code alone. You have to read what every library you shipped collects.
That is the actual work in this task, and it is why it takes a day rather than an hour.
Apple's wording is that you need to identify all of the data you or your third party partners collect.
So an advertising SDK, an analytics SDK, a crash reporter and a payment provider all become your declaration.
You cannot answer this form by reading your own code alone. You have to read what every library you shipped collects.
That is the actual work in this task, and it is why it takes a day rather than an hour.
Nobody is checking it for you
Both stores put the responsibility on you in almost identical language.
Google's wording is that you alone are responsible for making complete and accurate declarations.
Apple's is that you are responsible for keeping your responses accurate and up to date, and that if your practices change you update them.
So there's no approval that protects you. A form that passed review isn't a form that was verified.
I read both pages rather than a summary of them, because this is the one part of a listing where a paraphrase can cost you the app.
Google's wording is that you alone are responsible for making complete and accurate declarations.
Apple's is that you are responsible for keeping your responses accurate and up to date, and that if your practices change you update them.
So there's no approval that protects you. A form that passed review isn't a form that was verified.
I read both pages rather than a summary of them, because this is the one part of a listing where a paraphrase can cost you the app.
What happens when it is wrong
Google states the consequence directly, so there is no ambiguity to manage.
Apps that do not become compliant are subject to policy enforcement, like blocked updates or removal from Google Play.
Blocked updates is the one that actually hurts. You keep your listing and you can't fix anything.
That can happen while a real bug is live, which is the worst version of this problem.
So the cost of a careless answer isn't a warning email. It's your release pipeline stopping.
Apps that do not become compliant are subject to policy enforcement, like blocked updates or removal from Google Play.
Blocked updates is the one that actually hurts. You keep your listing and you can't fix anything.
That can happen while a real bug is live, which is the worst version of this problem.
So the cost of a careless answer isn't a warning email. It's your release pipeline stopping.
The independent review option
Google offers an optional extra and its limits are worth knowing.
You may declare that your app has been independently validated against a global security standard, which involves a third party assessment.
But Google's own page says this independent review may not be scoped to verify the accuracy and completeness of your Data safety declarations.
So the badge says somebody checked your security. It doesn't say anybody checked your form.
Useful signal for users, not a shield for you. Do not treat it as one.
You may declare that your app has been independently validated against a global security standard, which involves a third party assessment.
But Google's own page says this independent review may not be scoped to verify the accuracy and completeness of your Data safety declarations.
So the badge says somebody checked your security. It doesn't say anybody checked your form.
Useful signal for users, not a shield for you. Do not treat it as one.
Keep the two stores consistent
A practical rule that saves rework.
Fill in one store, then translate it to the other rather than starting fresh. The categories do not match exactly, but the underlying facts about your app do.
If your Apple labels say no tracking and your Google form says data's shared for advertising, one of them's wrong.
Anybody can compare the two pages in a browser, and competitors do.
Write the facts down once, in a document, and fill both forms from that. Not from memory.
Fill in one store, then translate it to the other rather than starting fresh. The categories do not match exactly, but the underlying facts about your app do.
If your Apple labels say no tracking and your Google form says data's shared for advertising, one of them's wrong.
Anybody can compare the two pages in a browser, and competitors do.
Write the facts down once, in a document, and fill both forms from that. Not from memory.
Update it when the app changes, not when the store asks
Both forms go stale silently and nothing prompts you.
The moment that breaks it is adding an SDK. A new analytics tool or ad network can change your declaration without a single line of your own code touching user data.
So put the privacy form on your release checklist beside the version number.
It'll take two minutes when nothing changed, which is most releases.
I counted the SDKs in one of my own builds while writing this and found eleven, four of which I'd forgotten were in there.
Our change screenshots without an update post covers which listing parts you can edit between releases, and the privacy answers are among them.
The moment that breaks it is adding an SDK. A new analytics tool or ad network can change your declaration without a single line of your own code touching user data.
So put the privacy form on your release checklist beside the version number.
It'll take two minutes when nothing changed, which is most releases.
I counted the SDKs in one of my own builds while writing this and found eleven, four of which I'd forgotten were in there.
Our change screenshots without an update post covers which listing parts you can edit between releases, and the privacy answers are among them.
It affects your conversion, measurably
Worth saying because teams treat this as pure compliance.
The privacy card is on the page. A reader deciding between two similar apps can see that one tracks and one does not.
For a utility, a calculator, a converter, a photo tool, declaring nothing is a genuine selling point and it costs you nothing to have.
So if you are carrying an ad SDK that earns very little, the label is part of what it costs you.
That is a business decision, not a legal one, and it belongs with the people who own the listing.
The privacy card is on the page. A reader deciding between two similar apps can see that one tracks and one does not.
For a utility, a calculator, a converter, a photo tool, declaring nothing is a genuine selling point and it costs you nothing to have.
So if you are carrying an ad SDK that earns very little, the label is part of what it costs you.
That is a business decision, not a legal one, and it belongs with the people who own the listing.
Localisation does not change it
A small thing that confuses people running many locales.
The privacy declaration is one answer for the app, not one per language.
The labels are translated by the store, so you write them once and every market sees them in its own language.
That is unlike your screenshots and description, which you translate yourself. Our localisation guide covers the parts that do need a per market version.
So this is one job, done once, however many countries you ship to. You can preview how the rest of the page looks around it on the create page.
The privacy declaration is one answer for the app, not one per language.
The labels are translated by the store, so you write them once and every market sees them in its own language.
That is unlike your screenshots and description, which you translate yourself. Our localisation guide covers the parts that do need a per market version.
So this is one job, done once, however many countries you ship to. You can preview how the rest of the page looks around it on the create page.
How long it actually takes
Budget a working day the first time, and be surprised if it takes less.
Most of that day is not the form. It is listing every SDK you ship and reading what each one collects.
After that, every subsequent update is a five minute review.
Teams that treat it as a fifteen minute job on submission day are the ones who answer from memory and get it wrong.
Our rejection reasons post covers the same pattern on the image side, where rushing the last step costs a week.
Most of that day is not the form. It is listing every SDK you ship and reading what each one collects.
After that, every subsequent update is a five minute review.
Teams that treat it as a fifteen minute job on submission day are the ones who answer from memory and get it wrong.
Our rejection reasons post covers the same pattern on the image side, where rushing the last step costs a week.
A checklist you can use today
Five steps, in order.
List every third party SDK in your build. All of them.
For each, find its own published statement of what it collects.
Write your app's facts into one document, once.
Fill both stores' forms from that document, and check the two results say the same thing.
Then add one line to your release checklist: did anything change. That is the whole system, and it survives staff turnover, which is the real test.
List every third party SDK in your build. All of them.
For each, find its own published statement of what it collects.
Write your app's facts into one document, once.
Fill both stores' forms from that document, and check the two results say the same thing.
Then add one line to your release checklist: did anything change. That is the whole system, and it survives staff turnover, which is the real test.
Frequently asked questions
What is the Google Play Data safety section?
A form you complete that becomes a summary on your store listing. It covers location, personal info, financial info, health and fitness, messages, media, app activity and device IDs, and asks whether each is collected, shared, required, encrypted in transit, and deletable on request.
Does Apple check my privacy labels?
No. Apple's own wording is that you are responsible for keeping your responses accurate and up to date. Passing review is not verification. The same is true on Google's side, where the documentation says you alone are responsible for complete and accurate declarations.
Do third party SDKs count as data I collect?
Yes. Apple states you need to identify all of the data you or your third party partners collect. So your ad network, analytics, crash reporter and payment provider all become part of your declaration, which is why this takes a day rather than an hour.
What happens if my data safety declaration is wrong?
Google's documentation says apps that do not become compliant are subject to policy enforcement, like blocked updates or removal from Google Play. Blocked updates is the one that hurts most, because you keep the listing and lose the ability to ship fixes.
Does declaring no tracking help my conversion?
It can. The privacy card sits on the same page as your screenshots, and a reader comparing two similar apps can see which one tracks. For utilities it is a genuine selling point. Our [custom product pages guide](/blog/custom-product-pages-app-store) covers tailoring the rest of that page for different audiences.
Build the mockup in your browser.
Drop a screenshot into a real device frame and export at the exact store size — free, no signup.