Most developers filling in the App Privacy questionnaire answer it about the code they wrote. Apple is asking about the code that ships.
This is not an interpretation. From App Privacy Details on the App Store:
"You need to identify all of the data you or your third-party partners collect, unless the data meets all of the criteria for optional disclosure listed below."
And Apple defines the term on the same page, leaving no room to read it narrowly:
"'Third-party partners' refers to analytics tools, advertising networks, third-party SDKs, or other external vendors whose code you've added to your app."
Analytics. Ad networks. Third-party SDKs. Any external vendor's code in your binary. Whatever those collect, you declare — under your name, on your product page.
This is not legal advice, and nothing here can see your app, your dependency graph or your network traffic. What follows is what Apple documents and where the answers tend to go wrong.
Why the SDKs are where it breaks
A typical shipping app carries several vendors' code, and each of them is there precisely because it collects something:
- Analytics — usage data, device identifiers, sometimes screen contents
- Advertising and attribution — identifiers, and by Apple's definition frequently tracking
- Crash and performance reporting — diagnostics, device state, sometimes user identifiers
- Authentication and social login — contact info, identifiers
- Push and messaging — device tokens, identifiers, engagement data
- Payments and subscription management — purchase history, identifiers
Six categories, and that is a modest app. The developer who answers the questionnaire honestly about their own code and forgets these has produced a label that is wrong, and the label is a public statement.
Note that this post names no vendor and states what no specific SDK collects. What a particular library gathers is a fact about someone else's software, it changes between versions, and it is often configurable. The only reliable source is that vendor's own current documentation, read against the version you actually shipped.
The two questions that must never have a default
For each data type you collect, Apple asks two follow-ups. Both are traps if you treat them as booleans.
Linked to the user. Apple's definition:
"You'll need to identify whether each data type is linked to the user's identity (via their account, device, or other details) by you and/or your third-party partners. Data collected from an app is often linked to the user's identity, unless specific privacy protections are put in place before collection to de-identify or anonymize it."
Read the second sentence carefully. Apple's stated default is that data is linked unless you took specific steps before collection to de-identify it. Not after collection. Before.
Tracking. Apple's definition is narrower and more specific than the everyday word:
"'Tracking' refers to linking data collected from your app about a particular end-user or device, such as a user ID, device ID, or profile, with Third-Party Data for targeted advertising or advertising measurement purposes, or sharing data collected from your app about a particular end-user or device with a data broker."
Two limbs: combining your data with third-party data for advertising purposes, or sharing it with a data broker. An app can collect a great deal and not track. An app can collect very little and track, if it hands that little to an ad network.
| What Apple is asking | Apple's default position | Wrong answer costs | |
|---|---|---|---|
| Collected | Does this data leave the device, by you or a partner? | — | A missing data type on a public declaration |
| Linked | Is it tied to the user's identity? | Linked, unless you de-identified it before collection | Understating what your label says about you |
| Tracking | Combined with third-party data for ads, or shared with a data broker? | — | A label that omits the section users look at first |
The design consequence for any worksheet covering this is that both answers must be three-state — unanswered, yes, or no — never a boolean. A boolean silently files every data type you have not looked at yet as "not linked", which is the most consequential wrong answer available and one you never actually gave. Appstro's privacy label planner keeps unanswered types in their own section, in no bucket at all, until you answer them.
The public buckets, in Apple's own capitalisation
Your answers roll up into three groupings shown on the product page. Apple writes them in sentence case, on its own Privacy Definitions and Examples page:
- Data used to track you
- Data linked to you
- Data not linked to you
Not Title Case. It is a small thing, and it is the kind of small thing that reveals whether a document was copied from Apple or from another blog.
How many data types are there?
Apple's current App Privacy Details page lists 15 data type groupings: Contact Info, Health & Fitness, Financial Info, Location, Sensitive Info, Contacts, User Content, Browsing History, Identifiers, Purchases, Usage Data, Diagnostics, Surroundings, Body, and Other Data.
That list has changed over time — Surroundings and Body are recent additions, and older write-ups quote different counts. If you built a worksheet against an earlier version of the page, it is worth re-reading the current one; this figure was counted from Apple's page on 20 August 2026 and it is not the number several widely-cited articles give.
Apple also asks for the purpose of each collection. Those purpose categories are a real dimension of the questionnaire and this post does not enumerate them, because they were not part of what was verified here — they are on the same Apple page if you need them.
Why there is no score
You will not find a compliance percentage anywhere in Appstro's planner, and that is deliberate.
A score over a legal questionnaire is the most dangerous output a tool like this could produce. It invites the reading that 80% is a pass, that a high number means you are covered, and that the remaining fifth is somebody else's problem. None of those are true of a declaration you are personally responsible for.
What a worksheet can honestly do is: hold Apple's definitions next to each question, keep unanswered items visibly unanswered, prompt you through the SDK categories you would otherwise skip, and show which public bucket each answer lands in. Bucket membership and counts. Nothing that resembles a grade.
What this cannot tell you
- Not legal advice. Said once, meant plainly. Your obligations under GDPR, the CCPA, the DPDP Act and everything else are separate from Apple's questionnaire and are not covered by answering it.
- Not what your app collects. No tool here can see your binary, your SDKs or your network traffic. The questionnaire is a declaration, and only you can make it.
- Not what a specific SDK collects. That is the vendor's documentation, for the version you shipped.
- Not whether your label affects conversion or ranking. Apple documents no such effect, and this post does not invent one.
- Not the App Tracking Transparency prompt. The privacy label and the ATT permission are two separate obligations. Answering one does not discharge the other.
The work
Open your Package.swift, your Podfile, your Gradle file — whatever lists what you actually ship — and walk it vendor by vendor before you touch App Store Connect. Then use the privacy label planner as the worksheet, and leave anything you have not verified genuinely unanswered rather than guessing "no". The age rating planner is its sibling for Apple's other questionnaire, and follows the same rule: it never computes the answer Apple's system is there to produce.