Apple’s App Privacy details, often called privacy labels or nutrition labels, appear on your product page and summarise what your app does with user data. You answer a questionnaire in App Store Connect, and Apple publishes the result. Like the Google Play form, the labels are only useful if they are accurate, and they are only accurate if someone owns the process. This guide explains the vocabulary, the questions that cause trouble, and how to keep labels current across a set of apps.
Apple adjusts the questionnaire and the surrounding rules over time. Where this article touches a requirement, confirm the current wording in App Store Connect and Apple’s developer documentation before you submit.
What the labels cover
The questionnaire asks you to declare the data your app and its integrated third-party code collect, and what happens to that data afterwards. For each data type you collect, you describe three things:
- Whether it is linked to the user’s identity.
- Whether it is used for tracking.
- The purposes for which it is used.
The result is a set of short statements shown to people before they download. Because these statements are public and persistent, treat the questionnaire as a published commitment, not a form to clear quickly.
Key terms in plain language
Data types
Apple groups data into categories such as contact information, identifiers, usage data, diagnostics, location, and others. Within each category are specific types. Read Apple’s list in App Store Connect rather than relying on memory, since the groupings can change.
Collection
In general, data counts as collected when it leaves the device and is stored or processed in a way that lets you or your partners access it beyond real-time servicing of a request. Apple’s help text defines the nuances, including limited exceptions. If you are unsure, read the definition, then decide.
Linked to the user
Data is linked to the user when it is tied to an identity, for example through an account, a device identifier, or another attribute that can be connected to a person. Analytics events tied to a user ID are linked. Truly anonymous counters may not be, but be sceptical: many identifiers that feel anonymous can still be used to connect events to a person or device.
Tracking
Tracking has a specific meaning in Apple’s materials. It generally refers to combining data collected in your app with data from other companies’ apps, sites, or properties for targeted advertising or advertising measurement, or sharing user or device data with data brokers. Read Apple’s definition carefully, because many publishers declare tracking when an advertising SDK is present. If your app declares tracking, you will also need to handle Apple’s app tracking permission prompt as described in the current developer documentation.
Inventory before you answer
As with Google Play, begin with an inventory. List every piece of data your app handles, where it goes, which service receives it, and why. Our Google Play Data safety guide describes the same method, and one inventory can feed both stores. Separate the following:
- Data your own backend receives.
- Data sent to analytics, crash reporting, and attribution services.
- Data sent to advertising networks.
- Data that stays on the device.
Fill in the labels from that list, line by line. Skipping the inventory and answering from memory is how apps end up with labels that contradict their own network traffic.
Third-party SDKs
Apple expects you to account for what SDKs in your app collect. For each SDK:
- Find the vendor’s documentation on data collection and on how to answer the privacy questionnaire. Many vendors publish exactly this.
- Check the SDK’s configuration options. Disabling identifier collection or limiting data sharing can change your answers.
- Check whether the SDK ships its own privacy manifest, and read the current Apple documentation on privacy manifests and required-reason declarations, since these requirements have evolved.
- Test with a network proxy on a debug build to see what really leaves the device.
Mediation setups deserve special care. Each ad network adapter is a separate piece of code with separate data practices, and adding one network can change your whole label.
The privacy policy URL
App Store Connect asks for a privacy policy URL. A few practical rules:
- Use a page specific to the app, or a clearly organised section of a shared policy, not a generic homepage.
- Host it on a stable address that will not move when you redesign your website. See what to include in an app privacy policy for the content.
- Make sure the page loads on mobile and without logging in.
- Keep the policy’s description of data consistent with your labels. If the two disagree, users and reviewers will notice.
Check the current requirement for the URL, and whether any additional links apply to your app type, in App Store Connect.
Common answers that need a second look
- Crash and diagnostic data. Crash reporting counts. Declare diagnostics if an SDK sends them off the device.
- Identifiers. Device identifiers and advertising identifiers are separate from user IDs. Declare each that your app or its SDKs use.
- Purchases. If you use a third-party service to validate purchases, think through what it receives.
- Account data. Sign-in with an email or social account means contact information is collected and linked.
- Optional features. Data collected only when a user opts into a feature is still collected. Describe it, even if only some users trigger it.
Review and rejection risk
Apple reviews apps against its guidelines, and inaccurate privacy information can lead to a rejected submission or a request for corrections. The specifics are Apple’s to set, so read the current App Review Guidelines on privacy and respond to review messages with concrete changes. Do not argue the point from memory; open your inventory and check what the app does.
Keeping labels updated
Labels are not a one-time task. Build the following into your release routine:
- Compare the dependency list of each release against the last one. Added or upgraded SDKs trigger a re-read of their disclosures.
- Check whether the release adds new permissions or new data fields.
- If either has changed, revise the labels and the privacy policy on the same day. Apple lets you update privacy details independently of a binary submission, per the current App Store Connect behaviour; verify this before relying on it.
- Log the review date in your portfolio sheet. The portfolio management checklist shows how to track this across many apps.
Special categories
If your app deals with health, reproductive, or other sensitive information, extra care is warranted. Declare conservatively, collect the minimum, and avoid sharing sensitive data with advertising services. Our write-ups on FTC lessons for fertility apps and the cycle tracking privacy checklist show how regulators and users think about this category.
A short pre-submission checklist
- The inventory is current and dated.
- Every SDK has been checked against its vendor documentation.
- Tracking is declared only if Apple’s definition applies, and the permission flow matches.
- The privacy policy URL loads and matches the labels.
- Someone other than the person who built the app has read the labels against the product page.
For related reading on running a publishing operation, visit the publishers hub.