App Privacy Labels: App Store Privacy Details and Google Play Data Safety

Quick answer: App privacy labels are the data disclosures shown on your store page: App Privacy on the App Store and Data safety on Google Play. You declare every type of data your app and its third-party SDKs send off the device, why you collect it, whether it is linked to the user and whether it is used for tracking or shared. Both stores require them, even if you collect nothing.

Both stores turn your answers into a summary on the product page, but they group the data differently.

Google also requires a privacy policy link to complete the form, and Apple requires a privacy policy URL for every app. Your policy, your labels and your app's real behavior should all tell the same story.

Most mistakes come from misreading four words. Read the official definitions, but here is the gist.

• Collect. Apple counts data as collected when it is transmitted off the device in a way that lets you or a partner access it for longer than needed to handle the request in real time. Google defines it as transmitting data from your app off the user's device. Data processed only on the device is not collected.
• Linked to the user. On Apple's label, data is linked when it is tied to the user's identity through an account, device or other details. Apple treats personal data under privacy laws as linked.
• Tracking. Apple's term for linking data from your app with third-party data for targeted advertising or ad measurement, or sharing it with a data broker. If you track, you also need App Tracking Transparency permission.
• Shared. Google's term for transferring data to a third party. Google lists some exceptions, such as transfers to service providers acting on your behalf, so check the help page before you decide.

Before you open either form, make an honest inventory. This takes an afternoon and saves a rejection or an enforcement email.

1. List your own endpoints. What does your app send to your servers? Account details, content, purchase receipts, logs?
2. List every SDK and service. Check your package manager files, not your memory. Crash reporting, analytics, ads, attribution, sign-in, subscriptions and support chat all count.
3. Read each SDK's disclosure. Many vendors publish a page mapping their data to Apple's and Google's categories.
4. Check privacy manifests on iOS. Apple requires many common SDKs to include a privacy manifest. In Xcode, you can generate a privacy report from an archive in the Organizer to see what the manifests declare.
5. Note purposes for each item: app functionality, analytics, product personalization, advertising and so on.
6. Decide linked or not, and tracking or not, for each data type.

As a starting point, these are data types that common SDK categories often involve. Your real answer depends on the specific SDK and how you configure it.

1. Open your app, then App Privacy in the sidebar, and add your privacy policy URL.
2. Click Get Started and answer whether you or your third-party partners collect data from this app.
3. Select every data type you collect, from contact info and location to identifiers, usage data and diagnostics.
4. For each type, choose the purposes, whether it is linked to the user and whether it is used for tracking.
5. Review the preview of your label and click Publish.

You cannot submit a new app or update until this is complete. Apple says you can change your answers at any time without submitting a new version, so fix mistakes as soon as you find them. The full submission flow is in our App Store Connect guide.

1. In Play Console, go to App content and open Data safety.
2. Answer the data collection and security questions: do you collect or share required data types, is all data encrypted in transit, and can users request deletion?
3. Select the data types collected or shared.
4. For each type, describe usage and handling: collected, shared or both, whether processing is ephemeral, whether it is required or optional, and why.
5. Preview and submit.

All apps published on closed, open or production tracks must complete it. Only apps that are exclusively on internal testing are exempt, so new personal accounts need it before their closed test begins.

• Forgetting SDK data. The crash reporter or analytics library sends device data even if your own server does not.
• Choosing "no data collected" by default. If anything leaves the device and is kept, it is collected.
• Marking account data as not linked. If it is tied to a login, it is linked.
• Different answers on iOS and Android for the same app and the same SDKs, without a technical reason.
• Not updating after adding an SDK. A new ads or attribution SDK can change your tracking answer.
• Ignoring account deletion. Both stores expect apps that offer account creation to let users delete their account, and Google's form asks about it directly.

Privacy answers that do not match the app can lead to rejection on iOS or enforcement on Google Play. Our list of App Store rejection reasons covers how Apple flags these issues.

Labels drift because apps change. Make privacy part of your release routine:

• Add "Does this change what data we collect or share?" to your pull request template.
• Review both forms whenever you add, remove or update an SDK.
• Re-read the labels at every major release, alongside the rest of your App Store submission checklist.
• Keep your privacy policy in sync with the labels.