The App Privacy section on every product page looks like something Apple works out on its own, and a lot of developers we talk to seem to assume it is. It isn't. It's a questionnaire in App Store Connect that we fill in ourselves, and the answers are only as accurate as the person entering them makes them. Nothing in the binary is scanned to produce it. If our answers drift from what the app actually does, the label is wrong, and that's a compliance issue we'll discover later rather than a metadata typo an App Review engineer catches for us on the way in.
At Olnesta Ltd we treat the label the same way we treat entitlements or a signed provisioning profile: something to review deliberately on every release, not something to click through. It's a small habit, and it's saved us from shipping a label that quietly stopped matching reality after an SDK update.
The three buckets are not interchangeable
The questionnaire sorts every piece of data collected by the app into one of three buckets, and it's worth being precise about which is which because they are not the same claim.
The first is data used to track a user, in the sense Apple uses the word tracking: linking data from our app to data about that user or device collected elsewhere, typically for advertising or shared with a data broker. This bucket is the one that triggers the App Tracking Transparency prompt, and it's the one where a wrong answer is most visible.
The second is data linked to the user's identity: data we collect that is tied, in our systems or a vendor's, to an account, device identifier, or anything else that identifies the person. Analytics keyed to a stable user ID sits here even if we never use it for advertising.
The third is data collected but not linked to identity. To claim this bucket honestly, the data has to genuinely not be tied to a user or device identifier, and it has to stay that way downstream. If a crash report includes an install ID that a vendor can join back to a user record, it isn't unlinked, whatever we intended.
Getting the bucket right matters more than getting the exhaustive list of data types perfect. A data type in the wrong bucket changes the meaning of the label; a missing minor field is easier to correct.
Third-party SDKs are the part people forget
The questionnaire asks about data collected by the app, and the app includes everything we linked into it. Analytics, crash reporting, ad networks, attribution, push providers, feature flag services, in-app messaging: each of these has its own data collection practices, and each has to be reflected in our answers. It's our label, but we're answering for their behavior too.
In practice this means every SDK we add is a small privacy review, not just a dependency decision. Most reputable vendors publish a page describing what their SDK collects and how it maps onto Apple's categories, and some now ship a privacy manifest that declares this in a machine-readable form. We read those, and we keep a short internal note per SDK recording what we agreed it does. When the SDK updates, especially across a major version, that note is what we check the release notes against.
The failure mode we watch for is quiet scope creep. A crash reporter adds session replay as an opt-in feature; an analytics library starts collecting a new identifier by default in a point release; an ad network expands what it considers tracking. None of those changes prompt us in App Store Connect. If we don't reread the vendor's disclosures on upgrade, our label keeps saying what it said last year while the app has started doing something new.
Keeping the label honest over time
Our working rule is that the label is reviewed whenever any of three things changes: we add or remove an SDK, we ship a feature that collects something new from the user, or a vendor tells us their collection practices have changed. That's usually enough to catch drift before it becomes a problem.
We also try to keep the label conservative rather than clever. If we're not sure whether a piece of data is linked to identity in a vendor's backend, we assume it is and answer accordingly. Overstating collection slightly is a smaller problem than understating it, and it removes the temptation to argue ourselves into the answer we'd prefer.
The label is one of the few pieces of App Store metadata that describes an ongoing promise about behavior rather than a fact about the current build. Treating it as living documentation, reviewed on the same cadence as the code it describes, is what keeps it accurate release after release.