App Privacy Details in 2026: The Data Collection Checklist for App Store Connect

App privacy details are the answers you give in App Store Connect about what your app and its third-party SDKs collect, and they are published verbatim on your product page under App Privacy. Apple reads them as a declaration, not as marketing copy: if the label says no data is collected and the app ships an advertising SDK that sends a device identifier, that is a misrepresentation finding under the App Store Review Guidelines, not a typo you fix after release.

This checklist walks the whole surface as it stands in 2026: where the questionnaire lives, how the data-type groups map to the label users actually see, how purposes, linking and tracking are decided, what the privacy manifest files from SDKs do and do not fill in for you, the specific answers that get apps rejected, and the review you should run before every submission that adds or removes an SDK.

Two separate things live in App Store Connect and get confused with each other. The first is the privacy policy URL, set in App Information for each language the app supports; it is required for every app, including apps that collect nothing. The second is the App Privacy questionnaire, which produces the "Data Used to Track You", "Data Linked to You" and "Data Not Linked to You" blocks on the product page.

The questionnaire is per app, not per account, and it follows the app across versions. You can revise the answers without uploading a new build, which is exactly why accuracy drifts: a build ships with a new mediation SDK, the questionnaire is never touched, and the label keeps describing last year's app. Apple treats the published label as a statement to users, so the revision has to happen on the same day as the build decision, not in the next release cycle.

Apple classifies collectable data into a fixed set of groups: contact info, health and fitness, financial info, location (precise and coarse are separate answers), sensitive info, contacts, user content, browsing history, search history, identifiers, purchases, usage data, diagnostics, and surrounding environment. Each group expands into subtypes — identifiers into user ID and device ID, usage data into product interaction, advertising data and other, diagnostics into crash data, performance data and other.

The rule that trips everyone is what "collect" means. Data is collected when it leaves the device and is retained beyond the moment of the request in a way that lets you or your partners access it for longer than what is needed to service the request in real time. Processing that stays on device, and data that is discarded immediately, is not collection. Under that definition:

• A crash reporter is collection. Crash logs are transmitted and stored, even when they are aggregated afterwards.
• A local-only analytics counter is not. Nothing is transmitted, nothing is retained off-device.
• An ad SDK is collection, and usually tracking. The SDK transmits identifiers, usage and diagnostics to a party whose advertising you do not control.
• On-device personalization that never uploads is not — but the account data behind it probably is.

Every data type you declare must be assigned at least one purpose. The published list is short and the temptation is to tick everything: third-party advertising, developer's advertising or marketing, analytics, product personalization, app functionality, other purposes. Tick only what is true, because each purpose is an assertion about actual data flow:

• App functionality covers what the feature needs to work — an account email used for sign-in, a photo uploaded for editing.
• Analytics covers measurement of how the app is used, including by a third-party analytics SDK.
• Developer's advertising or marketing covers first-party promotion, including retargeting your own users.
• Third-party advertising must be selected whenever an ad network other than you receives the data.
• Product personalization covers tailoring content or recommendations from collected data.
• Other purposes is not a catch-all for uncertainty — it exists for legitimate uses that do not fit the five above.

Declaring "app functionality" only, while an SDK quietly resells the same identifier for advertising, is the single most common mismatch we see in audits. The questionnaire is not the place to minimise; it is the place to describe.

For each declared type you answer whether the data is linked to the user's identity. Linked means the data is tied to an identity you can trace — an account, an email, a persistent user ID, or a device identifier that resolves to one. Not linked means it is collected without any such connection: a random session identifier rotated frequently, aggregate counters with no join key.

Two practical tests. First, could you answer a support request by looking up that user's records? If yes, the data is linked. Second, does a partner hold a key that lets them re-identify the user across your app and theirs? If yes, the data is linked in their hands even if your own database stores it anonymously — and it is very likely tracking as well.

Apple does not grade you on intent here; it compares your answer to what the binary and its SDKs actually do. A hashed email is still linked. A device advertising identifier is linked and usually tracking.

Tracking has a narrow definition: linking data collected from your app with third-party data for targeted advertising, or sharing it with a data broker. If any declared type is used for tracking, three things must be true at the same time:

1. The questionnaire marks the type as used for tracking, and the product page shows it under "Data Used to Track You".
2. The app implements App Tracking Transparency: the system prompt, the NSUserTrackingUsageDescription string in Info.plist explaining what the tracking is for, and a check of the authorization status before any identifier is read.
3. The behaviour matches on both paths — users who decline must not receive tracked ads, and the SDK must be configured to respect that, not merely paused in your own code.

Declaring tracking without ATT is a rejection. Implementing ATT while declaring no tracking is a credibility problem that surfaces the moment a reviewer inspects the SDK list. The two artefacts are checked against each other, which is why the questionnaire review belongs in the same checklist as the Info.plist review.

Third-party SDKs ship a privacy manifest (PrivacyInfo.xcprivacy) that declares the data the SDK collects and the required-reason APIs it touches. Apple aggregates the manifests of the SDKs in your build to help pre-fill parts of the App Privacy questionnaire, and the SDK's declared data types appear in the flow so you can confirm or adjust them.

That is assistance, not absolution. Three gaps remain yours to close:

• Your own code. Manifests describe SDKs. Data types collected by first-party code — accounts, uploads, analytics you wrote yourself — have no manifest and are easy to forget.
• Configuration. An SDK that can collect more than it does in your build still declares the maximum. Your answer has to describe your configuration, and you should be able to explain why an unflagged type is not actually collected.
• Aggregation. The pre-filled answers are a starting point assembled from many sources; Apple still holds you responsible for the final label. Confirm each type, purpose and linking flag rather than accepting the defaults.

Six patterns account for nearly every privacy-label rejection we see:

1. "Data Not Collected" on an app with an ad SDK. The label claims nothing is collected while the binary loads an SDK that transmits identifiers. This is treated as inaccurate metadata.
2. Tracking declared, ATT missing. No prompt, no usage-description string, identifier read anyway.
3. ATT implemented, tracking not declared. The prompt appears, the questionnaire says no tracking — the two artefacts contradict each other.
4. Third-party SDK data omitted. Only the first-party data was declared; the mediation, analytics and crash SDKs were not.
5. Purpose mismatch. Data declared for app functionality while the SDK uses it for advertising.
6. Stale label after an SDK swap. The questionnaire still describes the SDK removed two releases ago while the new one collects two more types.

All six are avoidable with one discipline: the questionnaire is part of the release checklist, reviewed against the resolved dependency list, not a one-time setup task performed when the app was first created.

Build the evidence first, then edit the questionnaire. Export the resolved dependency list for the release build, list every SDK that touches identifiers, location, contacts or usage data, and open each one's privacy manifest. Compare that list with the current App Privacy answers. Only then modify the answers, and record what changed and why in the release notes for the team.

For apps that ship the same product on both stores, the exercise has a second half: the Google Play Data safety form asks closely related questions with different categories and a different definition of sharing. The two declarations must agree on substance — an app that tells Apple it shares identifiers with advertising partners cannot tell Google Play that nothing is shared. Keep a single internal data-flow sheet and derive both declarations from it, or the two stores will eventually describe two different apps.

We help developers prepare and submit accurate privacy declarations: reading the resolved SDK list out of the build, mapping each SDK's manifest to the data types Apple expects, aligning the App Privacy answers with the ATT implementation and the Info.plist strings, and cross-checking the result against the Play Data safety form so the two stores tell the same story. We describe what the platforms actually require and help you state it correctly — we do not promise approval, and we never advise declaring less than the app does. If a submission was rejected over privacy metadata, send the rejection text and the SDK list, and we will point at the exact answer that does not match the binary.

• Resolved dependency list exported from the release build, not from memory.
• Every SDK with a privacy manifest opened and its declared types recorded.
• First-party collection listed separately from SDK collection.
• Each declared type assigned the purposes that are actually true.
• "Third-party advertising" selected wherever an ad network receives data.
• Linking answer justified by whether you could look the user up.
• Tracking answer matches the ATT prompt, the usage-description string and the runtime check.
• Declined-ATT path verified to stop tracked requests, including inside SDKs.
• No data broker or cross-app advertising sharing left undeclared.
• Label describes the build being submitted, not a previous release.
• Play Data safety form re-read and consistent with the Apple label.
• Change log entry written: which SDK, which data type, which purpose, who verified.

• App privacy details on the App Store — Apple Developer
• Privacy manifest files — Apple Developer Documentation
• App Tracking Transparency — Apple Developer Documentation
• App Store Review Guidelines (5.1 Privacy) — Apple Developer