Guide · 7 min read
App Store Privacy Labels: What to Declare, What's Exempt, and What Triggers Rejection
Apple's privacy labels look like a simple checkbox form — they're not. Since iOS 17, Apple cross-checks your self-reported declarations against privacy manifests bundled with third-party SDKs, and a mismatch triggers rejection before a human reviewer ever sees your submission. Most indie developers fill in the form honestly but incompletely, because they don't account for what their analytics, attribution, and crash-reporting libraries are quietly sending. Here's what to declare, what's genuinely exempt, and where the common traps are.
Privacy labels are self-reported — until Apple's manifest pipeline catches the gap
Apple required privacy manifests for high-impact third-party SDKs starting with iOS 17, with enforcement reaching full effect through 2024 and 2025. By 2026, any SDK on Apple's required manifest list that ships without one triggers an automated rejection before the review team touches the submission. The libraries on that list include the ones most indie apps actually use: Firebase Analytics, Crashlytics, Adjust, Branch, Amplitude, and AppsFlyer.
The cross-check works like this: each SDK's privacy manifest declares which APIs it accesses and why. Those APIs map to data types in the App Store privacy label form. If your label says 'Data Not Collected' while a bundled SDK manifest declares it reads device identifiers for analytics, the declarations contradict each other and the automated pipeline flags the submission. The label and the manifests must be internally consistent — one overrides the other only in the direction of rejection.
The practical consequence: filling in the privacy label in App Store Connect is step two, not step one. Step one is auditing every dependency in your build — Podfile, Package.swift, or build.gradle — and checking each against Apple's required manifest list at developer.apple.com. What each SDK declares in its manifest sets a floor for what your label must declare. The App Store Connect submission walkthrough covers where the privacy section lives in the form, but the SDK audit has to happen before you open it.
"Data Used to Track You" is narrower than it sounds — most analytics doesn't qualify
Apple's privacy label has four buckets: Data Not Collected, Data Not Linked to You, Data Linked to You, and Data Used to Track You. The last one is the most frequently miscategorized — almost always in the direction of over-declaration. 'Tracking' in Apple's specific definition means using data to link a user's behavior across apps or websites owned by other companies, or sharing data with data brokers. Standard first-party analytics — counting sessions, logging feature use, measuring retention within your own app — is not 'tracking' by this definition, even if it involves user data.
This distinction matters because incorrectly declaring data as 'Used to Track You' triggers App Tracking Transparency prompts that reduce conversion on new installs. Apps that show ATT prompts unnecessarily are paying a conversion cost they don't owe. Attribution SDKs that track the source of an install across ad networks — Adjust, AppsFlyer, Branch — are the correct candidates for the tracking category. Analytics tools you configure to analyze only your own app's funnel are not.
The distinction between 'Data Linked to You' and 'Data Not Linked to You' is where most remaining subtlety lives. Data is 'Linked to You' if it's connected to a user identity — account email, user ID, or any persistent identifier tied to a specific person. Data is 'Not Linked to You' if it's aggregated or stripped of identifiers before leaving the device. When genuinely uncertain, declare the more specific (Linked to You) category. Apple penalizes under-declaration, not over-declaration, so the conservative choice is the one that names more.
Every SDK in your build is your declaration liability — not just code you wrote
The dominant pattern in privacy label rejections is not false claims — it's omissions. A developer fills in the form based on what their own app code collects directly, without accounting for what SDKs collect silently. Third-party analytics, attribution, ad mediation, and crash-reporting libraries can send device model, OS version, IP address, app usage patterns, and persistent identifiers to their servers without a single line of your own code being responsible.
Adjust and AppsFlyer — the most common attribution SDKs for indie apps — nearly always require declaring device identifiers and usage data under 'Data Used to Track You,' because their core function is linking an ad impression on another app or website to an install in yours. That's tracking under Apple's definition. Having either library in your build without the tracking category declared in your label is one of the specific patterns Apple's automated manifest checks look for.
Pure analytics tools like Mixpanel or Amplitude, used only to analyze your own app's funnel, typically fall into 'Data Linked to You' when tied to a User ID, or 'Data Not Linked to You' for anonymous configurations. The SDK behavior — not the brand name — determines the category. Check each SDK vendor's own App Store privacy documentation; Adjust, Firebase, and Amplitude all publish maintained breakdowns of what to declare, and those documents are the correct reference, not the SDK's general marketing copy.
Crash reporters and diagnostics: the configuration determines the category
Crash reporters sit at an intersection that catches developers off-guard. Crashlytics and Sentry collect device diagnostics — device model, OS version, exception stack traces — that typically qualify as 'Data Not Linked to You' under the crash analytics category. That part is usually fine. The trap is breadcrumbs: both tools allow you to log custom events and user-state information as context leading up to a crash. If your code passes a user ID or email address into a breadcrumb or custom log, that data is now 'Data Linked to You.' The label should reflect your configuration, not the library's minimum possible scope.
Apple's guidelines list a small number of genuine exemptions from disclosure. Data used only for technical functions that happen entirely on-device — local ML inference, iCloud sync that doesn't route through your own servers, on-device processing that never transmits — may qualify for narrower declarations. Optional disclosure, where data is collected only when a user explicitly enables a feature they can turn off, is treated differently from mandatory collection. These exemptions are real, but they're narrower than developers typically assume. 'Our privacy policy says we don't share it' is not an exemption. 'We encrypt it in transit' is not an exemption. If it leaves the device for any destination, it belongs in the label.
Privacy label errors don't always surface at submission — post-launch removal is also a risk
App Store review has two moments to catch privacy label problems: the automated pipeline at submission (which checks manifest consistency and required-reason API violations) and human review afterward (which catches behavior that contradicts declarations, like an app claiming 'Data Not Collected' while prompting for email access). Common App Store rejection reasons include privacy label mismatches as one of the leading metadata-level causes — distinct from functional rejections and easier to fix, but no faster to resolve.
Post-launch catches are also possible. Apple can re-review an app and flag privacy label inaccuracies if a user report comes in, or during periodic policy sweeps. A label that was accurate at launch but became inaccurate after you added a new SDK without updating it is a violation, even if review passed at submission. Updating your privacy label in App Store Connect when you add or remove any third-party SDK is mandatory, not optional. The update follows the same metadata submission pathway as any other App Store Connect change and takes effect without a full app resubmission.
How to audit your privacy label in under an hour
A structured audit takes under an hour and covers most of the rejection surface. Start with your build files: list every third-party dependency. For each one, check Apple's required privacy manifest list and the vendor's published App Store privacy disclosure. Build a simple table with three columns — SDK name, what it collects, which Apple privacy category that maps to. That table becomes your ground truth for the App Store Connect form, and it's also your evidence if Apple questions a declaration during review.
When you open the privacy details section in App Store Connect, treat each question as a checklist item from your SDK table, not a memory exercise about your own code. Go category by category — contact info, usage data, diagnostics, identifiers, location — and for each data type you declare, answer whether it's linked to user identity and whether it's used for tracking across apps. With the table ready, the form takes 20 minutes. Without the audit, it takes guessing — and guessing is what generates the rejection cycles that delay launch by days.
Privacy labels as a submission risk, not a formality
Privacy label errors are almost entirely preventable with a dependency audit done before submission. The pattern that generates delays — treating the label as a 30-second checkbox at the end of an App Store Connect session — is the same pattern that sends apps back for revision after days in the review queue. Do the SDK inventory first, do the form second.
If you're building out your full App Store listing at the same time, the editor has structured prompts for the metadata fields that sit alongside your privacy label in App Store Connect — subtitle, keywords, and screenshots — so you can approach the entire submission as one organized pass.
Build your App Store listing in the editor →
Frequently asked questions
app store privacy labels
App Store privacy labels (also called App Privacy Details) are the structured data disclosures shown on every App Store product page, introduced by Apple in December 2020. They're self-reported by developers in App Store Connect under the App Privacy section. Since iOS 17, Apple cross-checks these declarations against privacy manifests bundled with third-party SDKs. Every app — including apps that claim to collect no data — must complete the privacy details form before submission.
what data do i need to declare in app store privacy labels
Declare every type of data your app and its third-party SDKs collect, send, or use — including data collected by analytics, attribution, crash-reporting, and ad mediation SDKs even if you didn't write that code. Categories include contact info, usage data, diagnostics, identifiers, location, and more. If an SDK on Apple's required privacy manifest list is in your build, its manifest sets a minimum floor for what your label must declare.
what happens if my app store privacy label is wrong
Inaccurate privacy labels cause App Store rejection during automated pipeline checks (especially when SDK manifests contradict label declarations), rejection during human review if app behavior doesn't match what's declared, and potential post-launch removal during Apple policy sweeps. The typical outcome is a rejection with a request to correct and resubmit — the cycle can cost several days per round during busy review periods.
do i need to declare what firebase or crashlytics collect in my privacy label
Yes. Firebase Analytics and Crashlytics are both on Apple's required privacy manifest list. Firebase Analytics typically requires declaring usage data and device identifiers under 'Data Linked to You' if tied to a User ID, or 'Data Not Linked to You' for anonymous configurations. Crashlytics typically requires declaring diagnostic data under 'Data Not Linked to You.' Google publishes and maintains detailed App Store privacy disclosures for both SDKs — use those documents as your reference rather than guessing.
is app store privacy label the same as a privacy policy
No, they're separate requirements. Your privacy policy is a legal document hosted at a URL you provide. The App Store privacy label is a structured disclosure Apple generates on your product page from the form you fill in at App Store Connect — it's not the policy document itself. Both are required. Apple checks that your privacy policy URL points to a live document, but the label form must be completed independently in App Store Connect regardless of what your policy says.