Does Your Analytics SDK Require the ATT Prompt? A 2026 Decision Tree for iOS Developers
Analytics does not automatically require Apple's ATT prompt. A decision tree covering when ATT applies, NSPrivacyTracking, and per-SDK defaults.
Summary
Short answer: measuring how people use your own app does not automatically require the App Tracking Transparency prompt. ATT governs tracking, which Apple defines as linking app data with data from other companies for targeted advertising or advertising measurement, or sharing data with a data broker. Accessing the advertising identifier (IDFA) also requires permission. An analytics SDK does not require the prompt when neither the SDK nor your data flows perform that tracking. This guide provides a decision tree and explains what to check in each SDK's current documentation and privacy manifest. It is a practical developer guide, not legal advice.
ATT is about cross-company tracking for advertising, advertising measurement, or data-broker sharing. First-party product measurement does not automatically trigger it.
Any code path that accesses the IDFA needs ATT authorization first, but tracking can also occur without the IDFA.
Advertising, attribution, and analytics SDKs all require configuration-specific review because optional integrations can change their data use.
A privacy manifest's NSPrivacyTracking value records the SDK vendor's declaration. Review it together with your own data flows and App Store privacy answers.
What ATT actually governs
Apple's App Tracking Transparency framework requires permission before an app tracks someone. Apple's definition is specific: tracking includes linking user or device data from your app with data from other companies for targeted advertising or advertising measurement. It also includes sharing user or device data with a data broker.
Measuring feature usage, funnels, retention, or errors inside your own app is not automatically tracking. The analysis changes if an SDK repurposes the data for advertising, joins it with data from other companies, or sends identifiers into an advertising ecosystem. Access to the IDFA also requires ATT authorization. Review the behavior of every SDK and every destination that receives your analytics data.
The decision tree
Walk your app through these questions in order. The first 'yes' tells you where you stand.
- 1. Does any SDK in your app read the IDFA (AdSupport / ASIdentifierManager)? → ATT prompt required before that read. This includes attribution SDKs configured for IDFA-based attribution.
- 2. Do you link app data with data from other companies for targeted advertising or advertising measurement? → ATT prompt required, even if the IDFA is not used.
- 3. Do you share user or device data with a data broker? → ATT prompt required.
- 4. Do you only measure your own app with pseudonymous identifiers, no IDFA, and no advertising or data-broker linkage? → ATT is not required for the analytics itself. Your privacy label must still disclose the data you collect.
- 5. Unsure about an SDK? → Read its PrivacyInfo.xcprivacy file and current documentation, then verify your enabled integrations. NSPrivacyTracking is useful evidence, but it does not replace reviewing your app's complete data flow.
How common SDK configurations affect the answer
The table summarizes publicly documented behavior reviewed in July 2026. Package choices and optional advertising features can change the answer. Verify the exact SDK version, package, configuration, privacy manifest, and connected destinations before submission.
Analytics and adjacent SDKs compared with ATT requirements, reviewed July 2026
| SDK | IDFA behavior | ATT for ordinary analytics use | Review notes |
|---|---|---|---|
| AppMetricsKit | Does not access IDFA | No | Uses pseudonymous account hashes when identify is enabled; does not share data for advertising |
| TelemetryDeck | Vendor documents no advertising identifier use | No | Vendor describes anonymized usage signals and no cross-app tracking |
| Firebase Analytics | Package and configuration dependent | Not automatically | FirebaseAnalytics can include IDFA collection capability; FirebaseAnalyticsCore removes it. Google Ads use changes the analysis |
| Mixpanel | Review current SDK and configuration | Not automatically | Advertising or destination integrations can change the result |
| Amplitude | IDFV by default; IDFA is optional | No for the documented default | Enabling advertising identifier collection or advertising destinations requires another review |
| PostHog | Review current SDK and configuration | Not automatically | Autocapture and replay create additional collection and disclosure questions |
| AppsFlyer / Adjust / Branch | Configuration dependent | Yes for tracking flows | Privacy-preserving attribution configurations may avoid IDFA access |
| Meta SDK with advertising features | Feature dependent | Yes for tracking features | Review every enabled advertising and measurement feature |
NSPrivacyTracking and privacy manifests: the paper trail
Privacy manifests provide useful evidence about an SDK. The relevant keys are NSPrivacyTracking, NSPrivacyTrackingDomains, and NSPrivacyCollectedDataTypes. Together they describe whether the SDK declares tracking, which domains are used for tracking, what data categories it collects, and whether those categories are linked to a user.
Search your archive, derived data, or Swift Package Manager checkouts for PrivacyInfo.xcprivacy files and review every dependency. An SDK that declares NSPrivacyTracking false can still participate in tracking if your app forwards its data to an advertising destination. Your ATT answer depends on the combined behavior of your code, SDKs, and connected services.
Common misconceptions that cause App Review problems
Misconception one: 'I use analytics, so I need the ATT prompt to be safe.' ATT permission is required for tracking, not for every analytics use case. Ask only when your enabled behavior meets Apple's tracking definition.
Misconception two: 'No ATT prompt means no privacy label disclosures.' The App Store privacy label describes data collection independently of ATT. Product interaction, purchase history, identifiers, and diagnostics may still need disclosure. Stable account-associated hashes can be classified as linked data even when the raw identifier never leaves the device.
Misconception three: 'ATT consent equals GDPR consent.' They are separate analyses. ATT is an Apple platform requirement, while GDPR requires a lawful basis for processing personal data. An app can require one, both, or neither.
Misconception four: 'Crash reporting or push notifications always require ATT.' The answer depends on the actual data use. These functions do not automatically constitute tracking, but an SDK or connected advertising destination can change the result.
What this means for choosing an analytics stack
For a simpler compliance review, prefer analytics with pseudonymous identifiers, no IDFA access, no cross-app advertising linkage, narrow payloads, and a privacy manifest that matches the shipped SDK. This does not make privacy disclosures disappear, but it makes the collection easier to describe accurately.
AppMetricsKit follows that approach with no advertising identifiers, no cross-app tracking, on-device hashing for optional account IDs, payload guardrails, privacy findings, and draft store disclosure helpers. Those helpers are not legal determinations. Reconcile them with the SDK privacy manifest, every event you send, and every other SDK in your app.
Sources
Primary sources
FAQ
Common questions
Does using an analytics SDK require the App Tracking Transparency prompt?
Not by itself. ATT applies when data is linked across companies for targeted advertising or advertising measurement, shared with a data broker, or when the app accesses the IDFA. First-party product measurement without those uses does not automatically require the prompt.
Does Firebase Analytics require the ATT prompt?
Not for every configuration. Google's current Apple-platform guidance distinguishes FirebaseAnalytics, which can include IDFA collection capability through AdSupport, from FirebaseAnalyticsCore, which removes that capability. Advertising features, Google Ads links, installed frameworks, and actual data use determine whether ATT is required.
What is NSPrivacyTracking in a privacy manifest?
It is a boolean in PrivacyInfo.xcprivacy that declares whether the app or SDK engages in tracking as Apple defines it. Review it with NSPrivacyTrackingDomains, the collected data declarations, the SDK configuration, and your app's connected destinations.
If my analytics needs no ATT prompt, is my App Store privacy label empty?
No. The privacy label declares collection independently of tracking. Usage data, purchase history, identifiers, and diagnostics may still need disclosure. Whether data is linked depends on the identifier and your use; a stable account-associated hash can be linked data.
Is ATT consent the same as GDPR consent?
No. ATT is Apple's platform rule about tracking, while GDPR is EU law governing the processing of personal data. An app can require one, both, or neither. Data minimization can simplify both reviews, but it does not merge them.