# App Store privacy labels: audit your analytics SDKs first (2026 checklist)

> Audit analytics and third-party SDKs before answering App Store privacy questions: map their data, check tracking, avoid 5.1.2 and ITMS-91061.

Canonical: https://makeyourapp.live/blog/app-store-privacy-labels-analytics-sdk-audit
Last updated: 2026-10-27

By [Yagyesh Bobde](https://www.bobdeyagyesh.in) · Store submission · Published Oct 13, 2026 · Updated Oct 27, 2026 · 7 min read

List every analytics and third-party SDK in your build, record the data each one sends off the device, and answer App Store privacy questions from that list before review does it for you.

## Short answer

App Store privacy labels have to cover the data your analytics and other third-party SDKs collect, as well as what your own code sends. Before you answer App Privacy in App Store Connect, list every SDK in the build, map the data each one sends off the device to Apple's data types, and decide whether any of it counts as tracking. You can change your answers at any time without a new build. Listed SDKs such as FirebaseCrashlytics must also ship privacy manifests.

## Key takeaways

- Apple counts analytics tools, ad networks and any third-party SDK whose code is in your app as partners whose data collection you must declare.
- Data counts as "collected" when it leaves the device and is kept longer than needed to service the request in real time.
- A non-ad SDK, such as a login SDK, makes your app a tracking app if it reuses your users' data for ads in other developers' apps.
- Privacy label answers go live when you click Publish, and Apple says you do not need to submit an app update to change them.
- SDKs on Apple's commonly used list need a privacy manifest in a new app or an update that adds them, or upload shows ITMS-91061.

Your **App Store privacy labels** must cover what your analytics and other third-party SDKs collect, not only what your own code sends. Before you answer the App Privacy questions in App Store Connect, list every SDK in the release, record the data each one sends off the device, and decide whether any of it is used for tracking. Answer from that list, not from memory.

## Do App Store privacy labels have to include third-party SDK data?

Yes. Apple requires you to declare data collected by third-party partners' code, even when the SDK collects that data for reasons other than analytics or advertising.

Apple's [App Privacy page](https://developer.apple.com/app-store/app-privacy-details/) defines third-party partners as "analytics tools, advertising networks, third-party SDKs, or other external vendors whose code you've added to your app." So a crash reporter or a sign-in library belongs on your list. The collection test is about transmission: "Collect" means "transmitting data off the device in a way that allows you and/or your third-party partners to access it for a period longer than what is necessary to service the transmitted request in real time." Data processed only on the device is not collected.

## How do you build an SDK inventory for privacy labels?

Build the inventory from the resolved dependencies of the release build, including transitive ones, and record each SDK's name and version.

1. Export the resolved dependency list for each platform: `Podfile.lock`, `Package.resolved`, `pubspec.lock`, or your Gradle dependency tree.
2. Keep transitive dependencies. Apple's [third-party SDK requirements](https://developer.apple.com/support/third-party-SDK-requirements/) say you are "responsible for all the code the SDK includes in your app," so a shared module that an SDK pulls in still counts.
3. Record the name and version of each entry. Vendors change how they handle data between versions, so the version belongs in your audit notes.
4. Flag SDKs that appear on Apple's list of commonly used third-party SDKs. For those, Apple requires privacy manifests when you submit a new app or an update that adds them, and signatures when they are binary dependencies. "Any version of a listed SDK, as well as any SDKs that repackage those on the list, are included."

Add this step to your [App Store submission checklist](https://makeyourapp.live/blog/app-store-submission-checklist) so it runs on every release, not only the first one.

## Which App Store privacy data types does each SDK map to?

Each SDK maps to one or more of Apple's fixed data types, such as Crash Data, Performance Data, Product Interaction, Device ID, and Advertising Data. Read the vendor's data documentation and fill in a row for each SDK:

| SDK role | Data types to check | Key question |
| --- | --- | --- |
| Crash reporting | Crash Data, Performance Data | Does crash data leave the device, and is it tied to a user ID? |
| Product analytics | Product Interaction, Other Usage Data, Device ID | Is the device ID shared with other companies or apps? |
| Attribution or ad measurement | Advertising Data, Device ID, Purchase History | Is the data combined with data from other apps for ads? |
| Sign-in | Email Address, User ID | Does the vendor reuse account data beyond your app? |

Apple says collected data "is often linked to the user's identity, unless specific privacy protections are put in place before collection to de-identify or anonymize it," such as stripping direct identifiers like user ID or name. After collection, you also must not link the data back to the user or tie it to other datasets that identify them. If you cannot confirm that an SDK de-identifies data, mark it as linked.

## When does an analytics SDK count as tracking?

An analytics SDK counts as tracking when it links data about your users or devices with data from other companies' apps or sites for targeted ads or ad measurement, or shares that data with a data broker.

Apple's definition is "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." Analytics that stays inside your own app's data is not tracking. Ad measurement that shares an identifier across apps is.

The trap is a partner that isn't an ad SDK. Apple's example is "a login SDK that repurposes the data it collects from your app to enable targeted advertising in other developers' apps," which counts as tracking even if you don't use the SDK for that purpose. If one of your SDKs does this, the usual fix is a configuration change that stops the cross-app use, or a different vendor.

## Can you leave any SDK data off your privacy labels?

Only when a data type meets all four of Apple's optional-disclosure criteria, and analytics and crash data almost never do. The criteria are:

- It is not used for tracking.
- It is not used for third-party advertising, your own advertising or marketing, or other purposes.
- It is collected only in infrequent cases outside the app's primary functionality, and it is optional for the user.
- The user provides it in the app's interface, it is clear to them what is collected, their name or account name is prominently displayed in the submission form, and they affirmatively choose to provide it each time.

Apple adds that "data collected on an ongoing basis after an initial request for permission must be disclosed." Analytics SDKs run continuously and the user does not choose them each time, so they fail the last two tests.

## What does a finished SDK audit look like?

A finished audit gives each SDK one row that states what to declare, whether the data is linked to the user, and whether it is used for tracking. Here is the template for a hypothetical habit-tracking app with three SDKs. The answers depend on each vendor's documentation, so these are not findings about real products.

| SDK | Declare | Linked to user | Used for tracking |
| --- | --- | --- | --- |
| Crash reporter (FirebaseCrashlytics, on Apple's list) | Crash Data, Performance Data | Yes, if tied to a user ID | No, if not combined with third-party data for ads |
| Product analytics | Product Interaction, Device ID | Yes | No, if the vendor does not share data across apps for ads |
| Sign-in | Email Address, User ID | Yes | Yes, if the vendor uses account data to target ads in other apps |

The sign-in row changes the work. It makes the app a tracking app, so the labels must say so and your consent handling must match. Switching to a sign-in vendor that doesn't share data across apps, or turning off that sharing, is far cheaper before submission than after a rejection. Then test the release build with every SDK enabled, as in the [release-build test plan](https://makeyourapp.live/blog/app-store-rejection-2-1-release-build-test-plan).

## What went wrong for other developers?

Publicly reported cases show three failure points: labels that don't match the binary, SDK data the developer didn't know about, and listed SDKs shipped without manifests.

- A developer on the [Apple Developer Forums](https://developer.apple.com/forums/thread/707587) removed tracking from a new build but couldn't remove it from the label. App Store Connect said "Your app contains NSUserTrackingUsageDescription, indicating that you will request permission to track users," and review kept rejecting with "The app privacy information you provided in App Store Connect indicates you collect data in order to track the user… However, you do not use App Tracking Transparency." The developer said the app was approved after they filed an appeal and waited for the response before resubmitting.
- Another developer on the [Apple Developer Forums](https://developer.apple.com/forums/thread/688582) used Firebase Analytics with IDFA and IDFV collection disabled and a "no tracking" label, and got a Guideline 5.1.2 rejection anyway. The message said: "Collecting cookies is a form of tracking." It pointed to cookies on web content the app loaded, not to Firebase. A reply pointed out the mismatch, and no fix was posted.
- Developers in a [RxSwift GitHub issue](https://github.com/reactivex/rxswift/issues/2625) received "ITMS-91061: Missing privacy manifest" for RxSwift, RxRelay and RxCocoa. One user pointed CocoaPods at the 6.8.0 branch, which contains the manifest, and reported shipping the next update "without any warnings from Apple."

The common thread: Apple compares your answers with what the shipped binary and its web content actually do, so an inventory built from the real build catches all three problems before review does.

## How do you publish and update privacy labels in App Store Connect?

Publish privacy labels from the App Privacy section of your app in App Store Connect. The answers go live only after you click Publish, and Apple says you can change them at any time without submitting an app update.

1. In App Store Connect, select the app, click App Privacy in the sidebar, then click Get Started.
2. Say whether you or your third-party partners collect data, select every data type from your audit, and click Save.
3. Answer the follow-up questions for each data type, click Save, and review the Product Page Preview.
4. Click Publish in the top right and confirm the accuracy dialog.

According to [Manage app privacy](https://developer.apple.com/help/app-store-connect/manage-app-information/manage-app-privacy), you need the Account Holder, Admin, or App Manager role. If the product page isn't live yet, your responses publish when it goes live. If the app is already on sale, your responses should reflect the data collected by that version only. Changes to privacy policy URLs "release with your next app version." If review has already flagged privacy issues, start with the [App Store rejection fix guide](https://makeyourapp.live/blog/app-store-rejection-how-to-fix).

> **Rule of thumb:** Every new dependency is a privacy change. Re-run the inventory when you add, remove, or upgrade an SDK, not only before a major release.

## Frequently asked questions

### Do I need to submit a new build to change my App Store privacy labels?

No. Apple's App Privacy page says you may update your answers at any time and do not need to submit an app update to change them. Edit the responses under App Privacy in App Store Connect and click Publish. One exception: changes to your privacy policy URL ship with your next app version. Apple's other caveat is that answers for an app already on sale should match the version that is currently live.

### Does Firebase Crashlytics need a privacy manifest?

Yes. As of October 2026, FirebaseCrashlytics is on Apple's list of SDKs that require a privacy manifest and a signature. The requirement applies when you submit a new app containing it, or an update that adds it. Any version of a listed SDK counts, and so does any SDK that repackages one. Use a current Firebase release and check that the PrivacyInfo.xcprivacy file actually ends up inside the built framework.

### What is the difference between a privacy manifest and a privacy label?

A privacy manifest is a PrivacyInfo.xcprivacy file inside your app or an SDK that describes the data the code collects. When you prepare to distribute, Xcode combines the manifests from your third-party SDKs into one report. The privacy label is the set of answers you publish under App Privacy in App Store Connect, and those answers are what users see on your product page. Use the Xcode report as an input to your answers, not as a replacement for your own audit.

### Do I need an App Tracking Transparency prompt if my privacy label says I track?

In practice, yes. Developers on the Apple Developer Forums report Guideline 5.1.2 rejections that say the privacy information indicates tracking, "However, you do not use App Tracking Transparency to request the user's permission." If you do track, add the ATT prompt before any tracking starts. If you don't, fix the label and remove NSUserTrackingUsageDescription from the build.

### Who can edit App Privacy answers in App Store Connect?

To answer and publish privacy questions you need the Account Holder, Admin, or App Manager role. Editing the privacy policy URL and the optional privacy choices URL is also open to the Marketing role. Developers without one of these roles can still do the SDK inventory and hand the finished answers to an Admin to enter and publish.

## Sources & further reading

- [App privacy details on the App Store - Apple Developer](https://developer.apple.com/app-store/app-privacy-details/) (checked Oct 27, 2026)
- [Manage app privacy - App Store Connect Help](https://developer.apple.com/help/app-store-connect/manage-app-information/manage-app-privacy) (checked Oct 27, 2026)
- [Third-party SDK requirements - Apple Developer](https://developer.apple.com/support/third-party-SDK-requirements/) (checked Oct 27, 2026)
- [Apple Review is rejecting app for having tracking in privacy - Apple Developer Forums](https://developer.apple.com/forums/thread/707587) (checked Oct 27, 2026)
- [App Store Connect rejection due to Firebase Analytics usage - Guideline 5.1.2 - Apple Developer Forums](https://developer.apple.com/forums/thread/688582) (checked Oct 27, 2026)
- [ITMS-91061: Missing privacy manifest - ReactiveX/RxSwift Issue #2625](https://github.com/reactivex/rxswift/issues/2625) (checked Oct 27, 2026)

## Related

- [App Store submission checklist (2026): from Xcode 26 build to Submit for Review](https://makeyourapp.live/blog/app-store-submission-checklist)
- [App Store review demo account: how to set up a reviewer login that passes review (2026)](https://makeyourapp.live/blog/app-store-review-demo-account-setup)
- [All posts](https://makeyourapp.live/blog)