App privacy labels and data safety forms: what they ask and how to answer

The short answer

Apple's App Store shows privacy details and Google Play shows a Data safety section. Both are declarations you make about what data your app collects, why and whether it is shared. Build an inventory of your own code and every third-party SDK, answer from that inventory, and update it whenever the app changes.

What these forms are

On the App Store, you provide privacy information about your app in App Store Connect, and it appears on your product page as a summary that shoppers can read before downloading. Google Play has an equivalent: the Data safety section, completed in Play Console and shown on the store listing.

Neither form is your privacy policy. A privacy policy is a legal document hosted at a web address, and both stores ask for a link to one. The labels are a structured summary that must agree with it. If the label says one thing, the policy another and the app a third, you have a problem with users, with regulators and with the stores.

For the underlying questions of what an app should request and why, see app permissions and privacy basics for founders.

Start with a data inventory

Do not begin with the form. Begin with a list of everything the app collects or sends off the device. A simple table is enough.

This table is an example of the layout, not a list for your app. Fill yours in from the code, the server and your settings in each service. Ask the developer to go through the dependencies, because the app's own code is only part of the picture.

Do not forget the third-party code

Analytics tools, advertising libraries, crash reporters, login providers and payment services are code written by others that runs inside your app. Both stores treat you as responsible for what that code collects, not only what you wrote yourself.

For each one, read the provider's documentation on what it collects and which settings change that. Many tools let you switch off advertising identifiers or limit what is sent. Where a provider publishes guidance for the store forms, use it as a starting point, but verify it against your actual configuration. Our guide to APIs and third-party integrations explains why each one is a dependency you have to manage.

Apple's privacy information also covers whether data is used to track people across other companies' apps and sites. If any tool you use does that, read Apple's current definition and the rules that go with it before you answer.

How the two forms think

The stores group answers differently, but the questions are similar: what data types, why, whether it is shared, and whether it is optional or required.

• Apple asks you to select the data types you collect and say how each is used, whether it is linked to the user's identity, and whether it is used for tracking. Check Apple's current documentation for the exact categories and definitions.
• Google asks whether you collect or share data, which types, the purposes, whether collection is optional, and whether data is encrypted in transit and users can request deletion. Check the current help pages for definitions of collecting and sharing, because they are specific.

Google's own documentation notes that an app available only on an internal testing track does not need the form until it moves to other tracks; see app beta testing for the tracks.

Terms such as "collect" and "share" carry defined meanings in each store's guidance, so a word that sounds harmless in daily speech may count. When in doubt, read the definition on the official page, and where a question is still unclear, take legal advice.

Common mistakes

1. Answering from memory instead of from the code and the settings.
2. Ignoring SDKs added by a developer or an agency months ago.
3. Declaring no data collection while crash logs or analytics identifiers are in fact sent.
4. Not updating the form after adding a feature that uses the camera, contacts, location or sign-in.
5. Copying a competitor's answers. Their app is not yours.
6. Writing a privacy policy that does not match the form.

Reviewers and users can compare what you say with what the app does, and a mismatch can lead to a rejected update or a removed app. The guide to why apps get rejected from app stores includes privacy issues among the common reasons.

Who should fill the form in

A common mistake is to leave the declaration to whoever is submitting the app. That person may be a project manager or designer without full knowledge of what is inside the code.

Split the work among three people. A developer lists what the app and its SDKs collect and send. A business owner or product manager explains the purpose of each item and whether it is needed. Someone responsible for legal or privacy matters, inside the company or as an adviser, checks the wording against the privacy policy and the laws that apply to your audience.

Then ask one person to complete the form from the agreed list, and keep the list on file. When something is unclear, choose the more cautious answer and ask for advice. If a user or regulator asks what the app collects, you want a single, dated document that matches both the store pages and the policy.

Keep it current

Treat the forms as part of the release process. Add a line to your release checklist: has anything changed in what we collect, which SDKs we use, or how we use data? If so, update the declaration and the policy together before submitting the build. This is especially relevant when you add monitoring; crash reporting and monitoring tools send data off the device.

Keep a dated copy of each answer set so you can show what you declared at any point. The store pages are also a good moment to check the screenshots and description against the real app, as covered in app store screenshots and previews.

This guide is general information, not legal advice. For help with the engineering side, including dependency review, see our mobile app development service.

Related guides

• Mobile app development
• App Store Screenshots and Previews: How to Make Them
• App Crash Reporting and Monitoring Basics
• App store optimisation basics
• Ecommerce website vs mobile app for your store
• What to build in the first version of your app

Questions and answers

Is a privacy label the same as a privacy policy?

No. The label or Data safety section is a structured summary shown in the store. The privacy policy is a full legal document at a web address. Both stores ask for the link, and the two must agree with each other and with the app.

Do I have to include data collected by third-party SDKs?

Yes. You are responsible for what the code inside your app collects, whether you wrote it or not. Review each SDK's documentation and your own settings for it.

What if my app collects no data?

Verify it first. Analytics, crash reports, login services and advertising tools often collect something. Declare no collection only when the code and every dependency confirm it.

When should I update the answers?

Whenever the app begins to collect new data, adds or removes an SDK, or uses data for a new purpose. Make the check part of every release.

Can a wrong answer cause a rejection?

It can. The stores can reject an update or take action if the declaration does not match the app's behaviour. Accurate, current answers lower that risk.