App Store Privacy Labels: iOS & Google Play Data Safety (2026)
When someone taps your app in the App Store or on Google Play, the first thing many shoppers read isn't your screenshots — it's a summary of what data the app collects and why. Those summaries, called app store privacy labels, have moved from a novelty transparency feature in 2020 to a full gatekeeping signal for install decisions and compliance reviews. Get them wrong and you risk rejection, forced updates, or a public mismatch between your label and your privacy policy that regulators can cite as a deceptive practice.
This guide walks through what the labels on Apple's App Store and Google Play actually ask you to disclose in 2026, where developers most often get them wrong, and how to keep your labels, your privacy policy, and your app's real behavior in sync.
What Are App Store Privacy Labels?
App store privacy labels are standardized disclosures that summarize how your app collects, uses, and shares user data. They live on the store listing itself, not inside your app, so a prospective user can see them before they even install. Both Apple and Google require these disclosures for virtually every app in their marketplaces, and both rely on the developer's self-declaration. That means the accuracy of the label is entirely on you — the platforms perform spot checks, but they don't audit every app line-by-line.
Apple's App Privacy (the "Nutrition Label")
Apple introduced its App Privacy section on the App Store in December 2020. Developers submit the disclosures through App Store Connect, and they appear on iOS, iPadOS, macOS, tvOS, visionOS, and the web-based App Store under the heading "App Privacy." Apple sorts every data type into one of three buckets: Data Used to Track You, Data Linked to You, and Data Not Linked to You. Developers must also identify the purposes for which each data type is collected.
Google Play Data Safety
Google Play's equivalent is the "Data safety" section, which launched for all Android apps in mid-2022. Developers complete a structured questionnaire in the Play Console covering what data they collect, what they share with third parties, why they need it, whether users can request deletion, and whether the data is encrypted in transit. Google also asks whether the app follows the Families policy and commits to the Play User Data policy.
Why App Privacy Labels Matter More in 2026
Labels started out as transparency features but have quietly become compliance checkpoints. App reviewers cross-reference what you declare against the runtime behavior of your binary and against the privacy policy URL you link. Mismatches get flagged, builds get rejected, and repeat offenders can see listings temporarily pulled from the store.
Beyond app review, regulators use the labels as evidence. A label is a public representation of your data practices, and public representations are enforceable under consumer protection laws. The U.S. Federal Trade Commission has repeatedly signaled that false or misleading claims on app listings can constitute deceptive practices under Section 5 of the FTC Act. European data protection authorities likewise cite app store disclosures when applying the GDPR's transparency obligations, and U.S. state attorneys general have brought cases where an app's label contradicted what the product actually did.
The practical upshot: a sloppy label is no longer just a UX problem. It is legal surface area.
The Three Apple Privacy Categories Explained
The single most common stumbling block is figuring out which Apple bucket a given data type belongs in. The difference is not academic — "tracking" triggers the App Tracking Transparency prompt, while "linked" and "not linked" do not.
Data Used to Track You. Data that is linked to the user or device and is then combined with third-party data for targeted advertising, cross-app/cross-site measurement, or sharing with a data broker. If your app uses the IDFA after an ATT opt-in, you almost certainly land here. So do most attribution SDKs.
Data Linked to You. Data tied to an identified user — an account, email, phone number, persistent device ID, or similar — but not used for tracking as Apple defines it. Examples: a username tied to your in-app profile, purchase history tied to an account, a support ticket history.
Data Not Linked to You. Data collected but stripped of any identifiers that could re-tie it to a specific person or device. Apple's bar is strict: if the data could be re-linked — including via a pseudonymous ID you hold on your server — it is not unlinked.
Google Play's Data Safety Questionnaire, Field by Field
Google's form is more question-heavy than Apple's. For every data type you handle, you'll answer:
- Do you collect this data? Do you share it with third parties?
- What is the purpose — app functionality, analytics, developer communications, fraud prevention, personalization, account management, advertising or marketing, or compliance with laws?
- Is collection optional for the user?
- Is the data encrypted in transit?
- Can users request deletion?
- Do you follow the Google Play User Data policy and, if relevant, the Families policy?
Google treats "sharing" as sending data to a third party that gets independent control over it, and "processing" as sending data to a third party that handles it on your behalf under instructions. The distinction matters: handing raw event data to an ad network is typically sharing; sending a crash payload to a processor that only stores it for you can be processing. Get this wrong and your declaration will be out of sync with what your SDKs actually do.
Common Data Types You Must Declare
Nearly every mobile app — even a simple utility — collects more data types than the developer initially realizes. Here is a quick cross-walk of common categories and where they land on each store.
| Data type | Apple category | Google Play category |
|---|---|---|
| Email address | Contact Info (Linked) | Personal info → Email |
| Full name | Contact Info (Linked) | Personal info → Name |
| Precise location | Location (Linked or Tracking) | Location → Precise |
| Coarse location | Location (Linked) | Location → Approximate |
| Device identifier (IDFA / GAID) | Identifiers (Tracking if cross-app) | App info and performance → Device or other IDs |
| IP address | Usage Data or Identifiers | App activity / Device IDs |
| Crash logs | Diagnostics (Not Linked, if truly anonymous) | App info and performance → Crash logs |
| Purchase history | Purchases (Linked) | Financial info → Purchase history |
| Photos or videos | User Content (Linked) | Photos and videos |
| Contacts | Contacts (Linked) | Contacts |
This is a shortlist, not the full catalog. Both stores break user content and health data into finer sub-categories, and both have specific rules for financial data, health data, and data about children.
Step-by-Step: Filling Out Apple's App Privacy Details
Before you open App Store Connect, build a data inventory. You need one row per distinct data flow — including every SDK, every ad framework, and every backend endpoint your app calls. Without that inventory, you will almost certainly miss something.
- Inventory every data flow: first-party collection plus every SDK and network endpoint.
- For each, answer three questions: is it linked to a user? Is it used for tracking? What is the purpose (Third-Party Advertising, Developer's Advertising or Marketing, Analytics, Product Personalization, App Functionality, or Other Purposes)?
- In App Store Connect, open your app and go to the "App Privacy" section under the app information panel.
- Answer the questions Apple presents per data type. Apple lets you update the labels out-of-band — you do not have to wait for a new release.
- Re-check before every submission that touches data handling.
Typical pitfalls: mislabeling analytics as App Functionality, forgetting to include IP addresses collected by your HTTP backend, and marking data Not Linked when it's tied to a user ID on your servers.
Step-by-Step: Filling Out Google Play's Data Safety Form
- In the Play Console, open your app and navigate to Policy → App content → Data safety.
- Declare whether you collect or share any data. "Sharing" to an ad network counts even if the data leaves the device for only a few seconds.
- For each data type, answer the full chain: purpose, optional vs. required, encryption in transit, and deletion.
- Link your privacy policy URL. Google compares its contents against your answers.
- Submit; Google re-evaluates on each new release and can reject updates whose behavior contradicts the declared labels.
Typical pitfalls: SDK data collection you didn't realize was happening, confusing "processing" with "sharing," and declaring collection "optional" when the user has no meaningful way to opt out.
Third-Party SDKs: The Most Common Mistake
Academic studies of app store privacy labels have repeatedly found that a significant share disagree with the app's actual runtime behavior, and the most common reason is underreported SDK collection. Your label must reflect all data collection that happens from your app binary, including data collected by SDKs you did not write.
- Analytics SDKs (Firebase Analytics, Amplitude, Mixpanel, PostHog): usage events, device identifiers, IP address, sometimes user properties.
- Crash and error reporting (Crashlytics, Sentry, Bugsnag): device model, OS version, stack traces, sometimes breadcrumb data that can be sensitive.
- Ad networks (AdMob, AppLovin, Unity Ads, Meta Audience Network): device identifiers, IP address, ad interaction data. Almost always counts as "shared" on Google and "tracking" on Apple.
- Attribution (AppsFlyer, Adjust, Branch, Kochava): device identifiers, IP, install events, click data. Tracking in most Apple cases.
- Authentication (Sign in with Apple, Google Sign-In, Facebook Login): authentication tokens and, depending on scopes, profile data.
- Payments (Stripe, RevenueCat, Braintree): purchase events, billing identifiers, sometimes email.
Ask every SDK vendor for a written data-handling statement. Apple's SDK "privacy manifests" requirement and Google's SDK data declaration program have both pushed vendors to publish these proactively, but the accountability still sits with you as the publisher of the app.
Aligning Your Privacy Policy with Your App Store Labels
Your store label and your privacy policy are the two most visible statements about your data practices, and they need to agree. Review teams and regulators treat a divergence as a red flag.
Three practices keep them in sync:
- Maintain a single data inventory. One document that lists every field you collect, the source, the lawful basis (if GDPR applies), the purpose, the retention window, every recipient, and whether it leaves the EEA. Generate both the label disclosures and the privacy policy from that inventory.
- Treat data changes as release blockers. Any change to data collection is a three-artifact change: code, store label, privacy policy. Add a checkbox to your release template.
- Show a real "last updated" date. If your privacy policy's date is two years old, reviewers and regulators will assume it does not reflect current practice. Update it when anything substantive changes.
If you need a drafting starting point, our privacy policy generator asks the same data-inventory questions that the store labels ask, so answering it once gives you a draft privacy policy you can then cross-reference against your App Store Connect and Play Console entries. For category-specific language, see the mobile app privacy policy template, and for deeper treatment of mobile-specific disclosures see our earlier post on privacy policies for iOS and Android apps. If your app uses AI or ML features, pair this with the AI privacy policy guide.
Frequently Asked Questions
Are app store privacy labels required by law?
The labels themselves are platform requirements imposed by Apple and Google, not statutes. However, once you publish a label, it functions as a public representation of your data practices, so an inaccurate label can trigger consumer protection claims under laws such as Section 5 of the FTC Act, state unfair-and-deceptive-practices statutes, or the GDPR's transparency obligations.
Do I still need a privacy policy if I have filled out the store labels?
Yes, and both Apple and Google require a privacy policy URL. A store label is a summary; the privacy policy is the authoritative, detailed disclosure. Regulators read both, and they expect them to match.
What happens if I get my privacy labels wrong?
In the short term, your app can fail review, be forced to submit a corrected label, or be temporarily removed from the store. In the longer term, a mismatch between your label, your policy, and your app's actual behavior is the kind of evidence that regulators and class-action plaintiffs use to allege deception.
Do third-party SDKs count toward my disclosures?
Yes. Data collected by an SDK that ships inside your app counts as data collected by your app. Apple and Google both require you to cover SDK behavior in your labels, even when the SDK was written by someone else.
Do enterprise or internal-distribution apps need privacy labels?
Public App Store and Google Play apps do. Apple's Enterprise Program, Apple Business Manager custom distribution, and Google's managed-Play private app channels have their own rules — check the specific program documentation, and apply the spirit of the labels (disclose what you collect and why) internally regardless.
How often should I review my privacy labels?
At a minimum, any release that touches data handling should trigger a label review, and you should do a full pass annually even if nothing changed. Add it to your release checklist alongside changelog and screenshots.
Can users dispute or report my privacy labels?
Yes. Apple and Google both accept reports from users (and from competitors) that an app's label does not match its behavior. Store teams can force edits, require updates, or remove apps whose labels are persistently inaccurate.
This article is for informational purposes only and is not legal advice. Consult a qualified attorney for your specific situation.
Authoritative references: Apple Developer — App Privacy Details on the App Store, Google Play — Provide information for Google Play's Data safety section, FTC — Mobile Apps guidance for businesses, UK ICO — Guidance on apps.