Does Your Analytics SDK Require the ATT Prompt? A 2026 Decision Tree for iOS Developers

Apple's App Tracking Transparency framework requires user permission before an app tracks them. Apple's definition of tracking is specific: linking user or device data collected in your app with user or device data collected by other companies' apps, websites, or offline properties, for targeted advertising or advertising measurement — or sharing that data with data brokers.

Two things follow from the definition. First, the word 'analytics' never appears in it. Measuring feature usage, funnels, retention, or crashes inside your own app — even at scale, even with a third-party analytics vendor processing the data on your behalf — is not tracking, provided the data is not linked with other companies' data for advertising purposes. Second, the enforcement mechanism is concrete: the advertising identifier (IDFA) returns all zeros unless the user has granted ATT permission, and App Review looks for tracking behavior without a prompt. If nothing in your app reads the IDFA and nothing shares user-level data into the ad ecosystem, ATT is simply not your framework.

Walk your app through these questions in order. The first 'yes' tells you where you stand.

The table below reflects each vendor's publicly documented default behavior as of July 2026. Configurations change and many SDKs have optional ad-related features that change the answer — always verify against the SDK's current documentation and its bundled privacy manifest before submission.

Since Apple began requiring privacy manifests, every SDK that qualifies as third-party must ship a PrivacyInfo.xcprivacy file declaring three things you care about here: NSPrivacyTracking (a boolean: does this SDK engage in tracking as Apple defines it), NSPrivacyTrackingDomains (network domains that only operate with ATT consent), and NSPrivacyCollectedDataTypes (what it collects and whether it is linked to identity).

This gives you a fast audit method: search your derived data or SPM checkouts for PrivacyInfo.xcprivacy files and read the NSPrivacyTracking value for each dependency. An analytics SDK declaring NSPrivacyTracking true in default configuration is telling you it does something beyond first-party measurement. Note the flag describes the SDK's behavior, not your obligations — an SDK with tracking false can still become tracking if you feed its data into an ad platform yourself. Your app's ATT answer is the union of every SDK's behavior plus your own data flows.

Misconception one: 'I use analytics, so I need the ATT prompt to be safe.' Showing the prompt when nothing tracks is not harmless — you are asking users a scary question for no benefit, opt-in rates hover low, and you have now declared tracking behavior your app may not actually have. Show the prompt only when something genuinely requires it.

Misconception two: 'No ATT prompt means no privacy label disclosures.' Wrong direction — the App Store privacy label declares collection regardless of tracking. Anonymous analytics still typically declares usage data collection, just marked as not linked to identity and not used for tracking. Misconception three: 'ATT consent equals GDPR consent.' They are unrelated legal frameworks; an EU app can need a lawful basis under GDPR while requiring no ATT prompt, and vice versa. Data-minimal analytics helps both cases, but they are separate analyses.

Misconception four: 'The prompt is required for crash reporting or push notifications.' Neither tracks across companies in default configurations. The recurring pattern in App Review rejections is the opposite case: an app reads the IDFA somewhere — often via a stale ad or attribution SDK — without showing the prompt, or shows the prompt while its privacy label claims no tracking.

If you want the simplest possible compliance story, choose analytics that never touches the question: anonymous or on-device-hashed identifiers, no IDFA, no ad-ecosystem data sharing, and a privacy manifest declaring NSPrivacyTracking false. Your ATT analysis then reduces to the SDKs that actually do advertising work, your privacy label shrinks, and your App Review surface gets smaller.

That is the design position AppMetricsKit takes — no advertising identifiers, no cross-app tracking, payload guardrails that catch accidental PII, and privacy label helpers generated from the events you actually send. But whichever stack you choose, the decision tree above is the same: find every IDFA read, check every manifest, and let the answer follow from what your app actually does rather than from folklore.