App Store Compliance

iOS privacy nutrition labels: what each of Apple's 14 data categories actually means

A category-by-category guide to Apple's App Privacy Details. What counts as 'Identifiers' vs 'Usage Data', when an analytics SDK becomes 'Diagnostics' vs 'Other Data', and the SDK-specific gotchas that get nutrition labels wrong.

· 12 min read

When Apple introduced privacy nutrition labels in late 2020, the framing was helpful for users and confusing for developers. The form in App Store Connect asks 14 questions about data categories with names that sound similar but mean specific things — and the wrong answer can get your privacy policy flagged for inconsistency, or worse, your app pulled for misrepresentation.

After helping a lot of teams fill these in correctly, the patterns that trip people up are consistent. This is a category-by-category guide to what each one actually covers, with the SDK-specific gotchas that most affect indie iOS developers.

How the form is structured

App Store Connect’s App Privacy section groups your declarations along three axes:

  1. Data category (14 buckets, listed below) — what kind of data.
  2. Data type (~30 sub-types) — the specific data within a category. “Email Address” under Contact Info, “Precise Location” under Location, etc.
  3. Use purpose (6 buckets) — why you collect it: Third-Party Advertising, Developer’s Advertising, Analytics, Product Personalization, App Functionality, Other Purposes.

For each data type you declare, you also answer:

  • Linked to identity? Can you (or anyone you share with) tie this data to a real person?
  • Used for tracking? Is it linked to data from third parties for ad targeting or shared with a data broker?

These two questions are where label-vs-policy mismatches happen most often. Get the categories right and these are the next-most-flagged.

The 14 categories

1. Contact Info

What it covers: name, email, phone number, physical address, other user contact info.

Common gotcha: the email address you collect for “we’ll email you a receipt” is Contact Info. Even if you only use it for transactional email, you still declare it. Whether it’s “linked to identity” depends on whether you store it tied to the user record (almost always yes).

2. Health & Fitness

What it covers: HealthKit data, fitness data, heart rate, sleep, etc.

Common gotcha: even read-only HealthKit access counts as “collecting” if your app sends summary statistics to a server. Local-only HealthKit reads that never leave the device do not.

3. Financial Info

What it covers: payment methods, credit/debit card info, bank account, financial credit history, “other financial info.”

Common gotcha: if you use Stripe (or any third-party payment processor), the card info is collected by Stripe, not by you. Most developers correctly declare “no” here — but if you collect billing addresses tied to the payment, that goes under Contact Info.

4. Location

What it covers: precise location (GPS coordinates), coarse location (city-level).

Common gotcha: geocoded IP addresses count as coarse location. Most analytics SDKs do this by default. If you use Mixpanel, Amplitude, or Segment, you’re probably collecting coarse location even if you didn’t intend to.

5. Sensitive Info

What it covers: race/ethnicity, sexual orientation, pregnancy/childbirth, disability, religious beliefs, trade union membership, political opinion, genetic info, biometric data.

Common gotcha: Face ID / Touch ID auth does not count — Apple handles biometrics locally and your app never sees them. But if you use a third-party biometric SDK that processes face data on your servers, that does count.

6. Contacts

What it covers: the user’s address book.

Common gotcha: if you ask for Contacts permission for a “find friends” feature, you’re collecting Contacts even if you only upload hashes. Apple’s stance is that hashed contact data is still collected.

7. User Content

What it covers: emails or text messages, photos, videos, audio, gameplay content, customer support data, “other user content.”

Common gotcha: crash report screenshots count as User Content if they include UI captures. Sentry and Bugsnag’s session-replay features collect this.

8. Browsing History

What it covers: content the user has viewed that’s not part of the app’s content (e.g., a web view tracking visited URLs).

Common gotcha: if your app embeds a WKWebView for a third-party site and you log which pages users visit, that’s Browsing History. Internal app navigation (which screens the user sees within your app) is not — that’s Usage Data.

9. Search History

What it covers: information about searches performed in the app.

Common gotcha: queries against your own search box count if you persist them. App Store search queries do not (you don’t have access to those anyway).

10. Identifiers

What it covers: User ID (your internal ID for the user), Device ID (IDFA, IDFV).

Common gotcha: this is the most-misunderstood category. The IDFA (Identifier for Advertisers) is only collected if you call ATTrackingManager and the user grants tracking permission. The IDFV (Identifier for Vendor) is more fluid — Apple considers it less sensitive but third-party SDKs sometimes collect it too. If you use Firebase Analytics, you’re collecting IDFV by default.

11. Purchases

What it covers: purchase history.

Common gotcha: in-app purchase history that you store on your server (e.g., to gate features behind subscriptions) counts. The App Store transaction history Apple owns does not.

12. Usage Data

What it covers: product interaction (taps, screen views), advertising data, “other usage data.”

Common gotcha: this is the biggest and fuzziest category. Most analytics SDKs (Mixpanel, Amplitude, Segment, Firebase Analytics, etc.) collect Usage Data. If you do anything with analytics, you almost certainly need to declare this.

13. Diagnostics

What it covers: crash data, performance data, “other diagnostic data.”

Common gotcha: Crashlytics, Sentry, and Bugsnag all collect Diagnostics. The line between Diagnostics and Usage Data is whether the data is about the app (crashes, performance) or the user (which screens they used).

14. Other Data

The catch-all. If something doesn’t fit the above categories but you collect it, declare it here.

Linked to identity vs. tracking

These two flags are where most label-vs-policy mismatches happen.

“Linked to identity”

Means: can the data be tied to a specific person, by you or anyone you share it with?

  • A user account with email + Usage Data → linked. (You can identify which user did what.)
  • An anonymized analytics event with no user ID → not linked.
  • Diagnostic data sent to Apple’s MetricKit → not linked (Apple aggregates).
  • Crash logs with the user’s email in the breadcrumbs → linked (even if accidentally).

Common gotcha: if your analytics SDK tags every event with the user ID, all of that data is linked, even if you don’t think of it as personally identifying. Most SDKs default to this.

“Used for tracking”

Apple’s specific definition: data linked across apps or websites owned by other companies for the purpose of advertising or sharing with data brokers.

  • Mixpanel events used only for your own analytics → not tracking.
  • Facebook SDK events used for FB ad targeting → tracking.
  • Branch attribution links → tracking.
  • Adjust, AppsFlyer, Singular → all tracking SDKs, even if you “only use them for your own data.”

Common gotcha: if you have a third-party SDK that can be used for tracking, even if you’re not using that feature, App Review treats it as tracking. The safest test: would removing the SDK break ad attribution somewhere? If yes, declare it as tracking.

Third-party SDK gotchas

Most rejections involve third-party SDKs you forgot to declare. Common offenders:

SDK Categories you probably need to declare
Firebase Analytics Usage Data, Identifiers, Diagnostics
Crashlytics Diagnostics, possibly Identifiers
Mixpanel / Amplitude / Segment Usage Data, Identifiers, Location (coarse, via IP)
Sentry Diagnostics, possibly User Content (session replay)
RevenueCat Purchases, Identifiers
Branch / Adjust / AppsFlyer Identifiers (linked, tracking), Usage Data
Stripe Financial Info (collected by Stripe, not you)
Apple Pay None (Apple owns the data)
Sign in with Apple Contact Info (email, optionally)

For each SDK in your app, check its App Privacy reference (most major SDKs publish one) and add their declarations to your own. Apple holds you responsible for what your SDKs collect, even if you didn’t write the SDK.

Keeping the label and the privacy policy in sync

The most common App Review rejection in this area is inconsistency between your privacy policy and your nutrition label. Examples:

  • Label says “no Location collected.” Privacy policy says “we use your IP address for analytics.” → flagged (IP-derived geocoding is coarse Location).
  • Label says “no Identifiers.” Privacy policy describes “device identifiers used for crash reporting.” → flagged.
  • Label says “Usage Data, not linked to identity.” Privacy policy says “we tie all events to your user account.” → flagged (events tied to user ID are linked).

OrbitKit’s privacy wizard generates both the privacy policy and a nutrition-label preview from the same source data, so they can’t drift. Walk through the 12 steps once, both outputs update together. The nutrition-label preview lives at https://your-domain.com/privacy-labels for users to reference and for App Review to spot-check against your App Store Connect entries.

Quick checklist before you submit

  1. Audit every third-party SDK in your Podfile / Package.swift. For each, find their App Privacy reference and add their declarations to yours.
  2. For every analytics event you log with a user ID, declare Usage Data as “linked to identity.”
  3. If you have any tracking SDK in the bundle (Branch, Adjust, AppsFlyer, Facebook SDK), declare data as “used for tracking” — and ensure ATT prompt fires before any tracking call.
  4. Re-read your privacy policy and verify every category in the policy is also declared in the label, and vice versa.
  5. Run Apple’s transparency report tool (the form itself) and walk through every question carefully. The page that shows your final label preview is what users will see — make sure it matches reality.

If anything in step 4 or 5 doesn’t line up, fix the policy and the label together. The iOS Privacy Policy Generator does this automatically; if you’re not using OrbitKit, manually keep both in sync every time you add or remove a data practice.

Further reading