The short version: ATT blocks one specific identifier (the IDFA — Apple's advertising ID). Apps that want to keep tracking you simply stop using the IDFA and use any of a dozen other identifiers that ATT doesn't touch. Apple's own 2023 study found that roughly 80% of apps continue tracking via fingerprinting after users tap "Ask App Not to Track." Below, what ATT actually does, what it doesn't, and what fills the gap.
What App Tracking Transparency actually blocks
ATT, introduced with iOS 14.5 in April 2021, requires apps to present a system prompt before they can access the device's IDFA (Identifier for Advertisers) — a single global string Apple assigns to each device. If you tap "Ask App Not to Track," the app is supposed to receive an IDFA full of zeros. That's it. That's the entire mechanism.
The narrow protection makes sense in Apple's framing: ATT is about a single Apple-controlled identifier. What ATT was never designed to do — and what most users assume it does — is stop apps from tracking your behavior through other means.
What apps switched to after ATT
When the IDFA shut off, the mobile-ad industry didn't give up. It switched techniques:
- Device fingerprinting. Combine screen resolution, model, OS version, installed languages, timezone, accelerometer noise patterns, and ~30 other signals into a fingerprint that's unique enough to re-identify your device across apps. The fingerprint is built from data Apple lets apps read freely.
- Hashed user identifiers. If you log into a free app with your email, the SDK hashes that email and ships the hash to the ad network. The hash matches across other apps that have your email. ATT doesn't prevent this — you opted in by signing up.
- Shared SDKs as cross-app glue. Facebook's SDK is embedded in ~30% of mobile apps. When you use any of those apps, the SDK reports back to Meta — even if you don't have a Facebook account. ATT prompts the host app, not the embedded SDK's separate identifiers.
- CNAME cloaking. A site or app creates a DNS alias (
analytics.bigsite.com→ reallyhotjar.com) so the tracker looks first-party. ATT has no DNS layer; browser content-blockers can't easily resolve the alias chain. - SKAdNetwork attribution. Apple's own ATT-friendly replacement — apps report install-attribution events via Apple-aggregated channels. Less granular than IDFA, but still attribution. Not nothing.
The empirical picture
Independent researchers and Apple's own internal studies have repeatedly found that ATT, in practice, blocks one channel and leaves many others open. The most cited finding: ~80% of apps continue some form of tracking after the user denies ATT permission, primarily via fingerprinting and shared SDK identifiers. The Mozilla Foundation's 2022 "Privacy Not Included" report and academic work at Oxford / Imperial College have replicated this.
This isn't an argument that ATT is bad — it's a useful narrow protection. It's an argument that ATT alone is insufficient if your goal is "apps shouldn't track me."
What actually closes the gap
All of the above techniques share one structural feature: they require the SDK to reach a remote server. The fingerprint has to be sent somewhere. The hashed email has to phone home. The Facebook SDK has to ship its payload to graph.facebook.com. CNAME-cloaked trackers still resolve to a real destination eventually.
That means a network-level (DNS) filter that blocks connections to known tracker domains catches all of these in a single intervention, regardless of which identifier the app was about to send. This is the approach Pi-hole pioneered for home networks, and what mobile tools like Casper's Cloak, NextDNS, and AdGuard DNS do for individual devices.
The mechanism, simplified:
- The app's embedded SDK tries to send its fingerprint / hashed ID / behavioral signal to its server (e.g.
graph.facebook.com,amplitude.com,mixpanel.com). - Before that connection can complete, the device does a DNS lookup to find the server's IP.
- The system VPN profile sends DNS queries through a filtering resolver.
- The resolver recognizes the hostname is a tracker and refuses to return an IP.
- The connection never opens. The data never leaves your phone.
Crucially, this works for every app on the device — not just Safari. ATT is at the app-SDK API layer. Browser content-blockers are at the DOM layer. DNS filtering is at the network layer, below them both, where every app converges.
What ATT does well — credit where it's due
ATT is genuinely valuable for two things:
- It shifted the default. Before ATT, the IDFA was always-on. After ATT, ~75% of users opt out when prompted. That's a real population-level privacy shift, even with workarounds.
- It pushed Meta and others to disclose tracking infrastructure that was previously invisible. The "App Privacy" labels on the App Store, which apps must populate accurately, came as a direct consequence.
ATT was a worthwhile intervention. It's just not a complete one — and Apple has never claimed it was.
Practical recommendations
- Keep tapping "Ask App Not to Track." The marginal protection is worth the second of friction.
- Run a DNS-level filter alongside ATT — Casper, NextDNS, AdGuard DNS, or a self-hosted Pi-hole. This is what catches the techniques ATT doesn't address.
- Audit the App Privacy labels on apps before installing them. If an app's labels show "Data Linked to You — Identifiers" for non-essential purposes, look for an alternative.
- Recognize that "free" apps monetize through tracking by default. Paid alternatives often have meaningfully different privacy postures because they don't depend on it.
- Don't sign in with Apple/Google/Facebook if a real email works. SSO chains identifiers together that would otherwise stay isolated.
Bottom line
ATT is a useful but narrow privacy feature. It blocks a single Apple-controlled identifier. Apps that want to keep tracking simply use other identifiers. If your goal is the broader "apps shouldn't track me," ATT is the start, not the finish — pair it with a network-level filter that catches what ATT was never designed to.