App privacy labels are short, standardised summaries on an app's store page that show what data the app collects, what it uses that data for, and whether it is linked to you or used to track you. Users read them before they download. Developers write them, and they carry the responsibility for getting them right. This guide covers both sides: how to read a label, and how to build an accurate one if you commission or run an app in the UK.
TL;DR
- A privacy label is a developer-reported summary shown on the app's store page. It is not an audit, and the privacy policy holds the fuller detail.
- Apple's label sorts data by category, purpose, and whether it is "linked to you" or "used to track you". Google Play has a similar Data safety section.
- Third-party SDKs count. If an analytics or advertising library collects data in your app, it belongs on your label.
- You can change your Apple answers at any time in App Store Connect without releasing a new build.
- A label does not replace your UK GDPR duties. You still need a proper privacy notice, given when you collect the data.
Table of Contents
- What app privacy labels are and where to find them
- How to read a privacy label
- What labels do not tell you
- How to build an accurate label as a developer
- The SDK problem
- Privacy labels versus your privacy policy and UK GDPR
- Perspective: treat the label as a design decision
- Common mistakes to avoid
- Get a second pair of eyes on your app
- FAQ
- Sources
What app privacy labels are and where to find them
Apple's labels are standardised summaries of an app's data practices, reported by the developer. You find them in the App Privacy section of an app's product page on the App Store, and Apple also publishes labels for its own apps on a dedicated privacy page. Apple often calls them "nutrition labels" because the idea is the same as food packaging: a consistent format, so you can compare apps at a glance.
Google Play has its own version. Its Data safety section shows users whether and how an app collects, shares and protects data before they install it. Developers complete a form in Play Console, and the answers appear on the store listing.
So when someone searches for app store privacy labels, they usually mean one of two things: the Apple label or the Google Play equivalent. The logic is close, though the wording and categories differ. Most of this article uses Apple's model, because its definitions are the most precise, and notes where Google differs.
How to read a privacy label
A label is built from a few simple ideas. Once you know them, you can read any app's page in under a minute.
Data types and purposes
The label lists the categories of data an app may collect. Apple's examples include location, contacts, health information and identifiers. Each category is tied to the purposes the data is used for, such as app functionality, analytics or advertising.
"Linked to you"
Data is "linked to you" when it is collected in a way that connects it to your identity, for example through your account, your device or your contact details. A missing name does not make data anonymous. If the data can still be connected back to you, it counts as linked.
"Used to track you"
This is the label users worry about most. Data is "used to track you" when information from the app is combined with data from other companies' apps, websites or offline properties for advertising, or shared with a data broker. An app that only measures its own usage, on its own, is not tracking in this sense.
A quick reading checklist
- Check whether anything is listed under "Data Used to Track You". If so, ask yourself why a utility or business app needs it.
- Look at "Data Linked to You" and compare it with what the app actually does. A torch app asking for contacts is a flag.
- Notice the purposes. Data used for app functionality is different from data used for third-party advertising.
- Open the privacy policy for the detail the label cannot give.
What labels do not tell you
Labels are useful, but they are limited. Apple describes them as self-reported summaries of some practices, and says the developer's privacy policy may give more detail on how practices vary, for example by feature or by user choice.
In practice that means three things:
- They are reported, not verified line by line. Accuracy depends on the developer's own diligence.
- They are a snapshot. An app that adds a new analytics tool and forgets to update the label is out of date.
- They do not show your rights. The label says nothing about how long data is kept, who your data is shared with by name, or how to ask for deletion. That belongs in the privacy policy.
For businesses, the flip side matters. An inaccurate label is a trust problem the moment a user or journalist spots the mismatch, and it can cause trouble in App Review. Treating the label as a product feature, not a form, pays off.
How to build an accurate label as a developer
The hard part is not the form. It is knowing what your app really collects. Here is the process we recommend.
Step 1: inventory every data flow
List everything your app collects and everything your partners collect through it. Apple's guidance is that you must account for data collected by your app and by every third-party partner, including SDKs, analytics and advertising vendors. Collection normally means data leaves the device in a way that lets you or your partners access it beyond real-time servicing of a request.
Step 2: classify each data type
For each item, record three things:
| Question | Examples of answers |
|---|---|
| What category is it? | Location, contact info, identifiers, usage data, purchases |
| Why do you collect it? | App functionality, analytics, personalisation, advertising |
| Is it linked to the user, and does it track? | Linked to account; combined with third-party ad data |
Step 3: check the optional-disclosure rule carefully
Apple allows some data to be left off the label, but only when it meets every one of the optional-disclosure conditions. If you are unsure whether a data type qualifies, declare it. Over-declaring is safer than under-declaring.
Step 4: enter it in App Store Connect
The route is straightforward. In App Store Connect you select the app, open App privacy, edit the relevant data types and purposes, then save and publish. Published changes update the product-page information.
Two details trip teams up:
- Responses apply at app level and should represent practices across platforms. Where platforms differ, Apple tells developers to answer comprehensively and inclusively.
- The privacy policy URL sits in the same area: select Privacy Policy, click Edit, enter the URL and save. A privacy-choices URL is optional.
Step 5: keep it current
Developers must update their responses if practices change, and Apple lets you change answers at any time without an app update. Make it a release checklist item: any new SDK, new permission or new data field triggers a label review.
The SDK problem
Most label errors we see in the market come from third-party code. An app team writes a tidy data model, then adds a crash reporter, an attribution tool and a social login. Each of those can collect identifiers or usage data on its own account.
Google is explicit about it: its form covers data collected and handled through any third-party libraries or SDKs in your app, and it suggests checking your SDK providers' own published Data safety information. Apple takes the same line.
A practical routine:
- Keep a living list of every SDK and its version.
- Read each provider's data documentation at every upgrade.
- Configure tools to collect the minimum you need, then declare what remains.
- Where analytics set-up is complex, for example server-side tagging, get specialist Google Analytics implementation help so you know exactly what is sent and to whom before you describe it on the label.
On iOS, this connects directly to Apple's technical requirements for SDKs. We cover those in our guide to the privacy manifest for iOS.
Privacy labels versus your privacy policy and UK GDPR
A common misunderstanding is that a completed label means the privacy job is done. It does not.
Apple requires both a label and a privacy policy for App Store compliance. Its App Review Guidelines say the policy must explain what data the app collects, how it collects and uses it, relevant third-party sharing, retention and deletion, and how users can revoke consent or request deletion.
UK law sets a separate standard. The UK GDPR requires personal data to be processed lawfully, fairly and transparently. The ICO says privacy information must be provided when personal data is obtained from the individual. That means purposes, lawful basis, retention, sharing and individual rights, none of which a label can carry on its own.
Layered notices suit mobile
The ICO recommends layered notices and just-in-time explanations alongside a privacy notice, rather than one large document. For an app that works well: the store label is the first layer, a short in-app summary at onboarding is the second, a permission prompt with a plain-English reason is the third, and the full policy sits behind them all.
Children's apps need extra care
If children are likely to use your app, the ICO's Children's Code guidance expects privacy information to be concise, prominent and in age-appropriate language, with bite-sized explanations when a feature or data use is activated. Speak to a data protection professional before launch. Our article on children's apps and data collection rules shows how often this goes wrong.
Perspective: treat the label as a design decision
We have built more than 300 apps for brands across retail, charity, healthcare and consumer engagement, and the same pattern repeats. Privacy gets handled at the end, by whoever has time, in the week before submission. That is when labels go wrong.
Our view is simple. The label is a reflection of your architecture, so decide what you collect during discovery, not at submission. In our discovery workshops we ask what each feature needs to know about the user, and whether it needs to know it at all. Every field you do not collect is a line you do not have to declare, secure or explain.
The second habit is to be technology-agnostic about tooling. We recommend the platform and the third-party services that fit the project, and we weigh their data appetite as part of that choice. A cheaper analytics SDK that tracks across apps can cost you more in user trust than it saves in build time.
Finally, write the label in the same room as the product team and the person responsible for data protection. For a deeper look, see our developer guide to privacy in apps and our piece on the human side of app privacy.
— Paul
Common mistakes to avoid
- Forgetting SDK data. The most frequent gap, covered above.
- Calling data "not linked" because there is no name. If it connects back to an account or device, it is linked.
- Declaring tracking inconsistently. If you ask for tracking permission in the app, your label should say you track.
- Never revisiting the label. Every release with a new data practice needs a check.
- Copying a competitor's label. Your app collects what your app collects.
- Treating permissions as separate. A well-timed prompt supports the label. See our push notification opt-in guide for how to ask well.
Get a second pair of eyes on your app
If you are planning a new app, or you suspect your current one has drifted from its label, we can help. Our Mobile App Clinics give you an expert review of an existing app, and our discovery, design, development and deployment process builds data decisions in from the start. To talk through a new project, start at our page on developing your business app.
FAQ
Where can I find an app's privacy label?
Open the app's page in the App Store and scroll to the App Privacy section. On Google Play, look for the Data safety section on the listing. Both appear before you install.
Are app privacy labels always accurate?
Not necessarily. They are self-reported by developers and summarise some practices, so the privacy policy may give more detail. If a label looks out of step with what the app does, read the policy and think twice before sharing sensitive data.
Do I need to update my label when I add a new SDK?
Yes. Developers must update their responses when practices change, and SDK data counts as your data for this purpose. On Apple platforms you can change the answers in App Store Connect without releasing a new version.
Does a privacy label replace a privacy policy?
No. Apple requires both, and UK data protection law requires fuller privacy information than a label can carry, including purposes, lawful basis, retention and rights. Treat the label as the summary and the policy as the full account.
Where do I enter my privacy policy URL?
In App Store Connect, choose your app, open App privacy, select Privacy Policy, click Edit, enter the URL and save.
Sources
- About privacy information on the App Store, Apple Support
- App Privacy Details, Apple Developer
- Manage app privacy, App Store Connect Help
- App Review Guidelines, Apple Developer
- Provide information for Google Play's Data safety section
- When should we provide privacy information? ICO
- UK GDPR, legislation.gov.uk
- How should we tell people what we're doing? ICO
- Children's Code guidance, mobile gaming app, ICO