App privacy nutrition label guide (2026)

What the App Privacy label is

Apple shows users a summary of your data practices before they download, grouped into categories like "Data Used to Track You," "Data Linked to You," and "Data Not Linked to You." You produce that summary by answering questions in App Store Connect, not by writing it yourself.

For each data type, for example contact info, identifiers, usage data, or location, you state:

• Whether your app or its third-party code collects it.
• What it is used for, such as app functionality, analytics, or advertising.
• Whether it is linked to the user's identity.
• Whether it is used to track the user across other companies' apps and sites.

The label is separate from your privacy policy. You need both: a real privacy policy URL and accurate label answers. They should agree with each other.

Filling out your data collection answers

Work from what the app actually does, including the SDKs you embed:

1. List every piece of data the app touches. Include account info, content users create, device identifiers, location, and anything sent to analytics or crash reporting.
2. Account for third-party SDKs. An analytics, ads, or crash SDK often collects data on your behalf. That collection counts as yours for the label.
3. For each type, set the purpose. Be specific: app functionality, analytics, product personalization, or advertising.
4. Decide linked vs not linked. If the data can be tied to an account or identity, it is linked.
5. Answer the tracking question honestly. Tracking has a specific meaning: linking user data with data from other companies for advertising or sharing with data brokers. If you do that, you must also use App Tracking Transparency to ask permission.

If your app genuinely collects nothing, you can declare that, but only if no embedded SDK collects anything either.

Privacy manifests and required reason APIs

Beyond the label, Apple requires technical declarations inside the app:

• A privacy manifest, the PrivacyInfo.xcprivacy file, lists the data types your app collects and the reasons it uses certain APIs. Many third-party SDKs are also required to ship their own manifest, and Apple aggregates them.
• Required reason APIs are specific system APIs, for example certain file timestamp or device access calls, that you must declare an approved reason for using. Failing to declare one can produce an automated rejection such as ITMS-91053, "missing API declaration."

These declarations are why an app can be rejected even when the listing looks complete. The fix is to add the manifest and the correct reason codes, which is covered in the linked ITMS-91053 guide.

How AppFlight helps

AppFlight generates the native Swift app and wires in the integrations you choose, so it knows which data-collecting SDKs are present, for example analytics through PostHog or crash reporting through Sentry. When Apple returns a rejection tied to privacy, such as a missing API declaration or a privacy policy issue, AppFlight reads the rejection reason, works on the fix, and resubmits. You remain responsible for honest answers and a real privacy policy, since only you know your full data practices. Apple reviews every app, and submitted is not approved, so treat the privacy label as something to get right the first time.