App privacy labels: what gets checked, and how RN apps get them wrong

The audit that catches it

Do this on a dependency change rather than before a release:

# what is actually in the tree that collects
grep -riE 'firebase|amplitude|mixpanel|segment|sentry|bugsnag|datadog|appsflyer|adjust|branch|facebook|onesignal|posthog|intercom|smartlook|fullstory' package.json | head -30

# transitive: what pulled in what
npm ls --all 2>/dev/null | grep -iE 'analytics|tracking|attribution|advert' | head -20

# does anything ask for the tracking permission
grep -rn 'NSUserTrackingUsageDescription' ios app.json app.config.js 2>/dev/null
grep -rn 'requestTrackingPermission\|AppTrackingTransparency' src app 2>/dev/null | head

Then, for each collector, open its own privacy documentation and read what it says it collects by default. Defaults matter: several SDKs collect identifiers or coarse location unless told otherwise, and the label has to describe the configuration you shipped.

The four questions per data type

For each category Apple lists, answer:

1. Do we collect it? Including through any SDK.
2. Is it linked to the user's identity?
3. Is it used for tracking, as Apple defines tracking?
4. What is it used for, in Apple's purpose categories?

Write the answers down with the reason. When the label is questioned, six months later, the useful artefact is a table saying which dependency produced which declaration. Reconstructing that from memory is where teams get it wrong twice.

Where the label meets other requirements

The two store forms must also agree with each other. Declaring no collection on Apple and collection on Google, for one codebase, is a discrepancy that an interested party can see from the outside.

The specific ways RN apps get it wrong

Crash reporting counts. Sentry, Bugsnag, Crashlytics collect diagnostics, often with identifiers, and "we only use it for crashes" is a purpose, not an exemption.

A push SDK collects identifiers. Device tokens and the identifiers around them are collection.

Support chat collects contact info and content. An in-app messenger is a data collector.

Attribution SDKs are usually tracking, in the specific ATT sense, which means the permission prompt and the label both change.

An analytics call left in a debug path still ships. If the code is in the binary and it runs, it collects.

Before you submit

Reconcile three things and make them say the same story: what the code does, what the label says, and what the privacy policy says. A reviewer can read two of those in a minute, and a policy that contradicts the label is a finding without anyone opening a debugger.

Then check the manifest side separately, because it is a different mechanism with its own upload-time failures. The privacy manifest, for React Native. · Which RN SDKs need one.

shipcheck enumerates the collectors actually present in your dependency tree, including transitive ones, and lists what each vendor documents itself as collecting, so the label is filled in from the tree rather than from memory. What it checks. · The first-submission checklist.

Questions and answers