Privacy & permissions
App Tracking Transparency on Mac: How It Actually Works
App Tracking Transparency on Mac controls cross-app tracking. Here's what it does, what it doesn't, and how to set it up properly.
App Tracking Transparency (ATT) is the framework Apple introduced on iOS in 2021 that lets users explicitly approve or deny cross-app tracking. It’s been quietly available on macOS for a while now too, though it gets less attention because the Mac advertising ecosystem is smaller than iOS’s. Still, it’s a real privacy feature with real implications, and most Mac users haven’t checked their setting.
Here’s what ATT does on Mac, what it doesn’t, and how to set it up.
What ATT actually controls
When ATT is enabled and an app respects the user’s choice, the app:
- Asks permission before using your IDFA (identifier for advertisers)
- Asks permission before tracking you across other apps and websites owned by other companies
- Must respect a “no” answer — using alternative identifiers as a workaround violates Apple’s developer agreement
What “tracking” specifically means in Apple’s framework:
- Linking user data collected from the app with user data from other companies’ apps
- Linking user data with browsing data from third-party websites
- Sharing user data with data brokers
- Combining data with email lists or analytics from outside the app to target ads
What it doesn’t include:
- An app collecting analytics about its own use within itself
- An app reading data you explicitly provided in that app
- A first-party advertising relationship — Apple’s own advertising on the App Store, for example
So ATT is specifically about cross-context tracking, not about apps measuring their own usage.
How to find the setting
Open System Settings → Privacy & Security → Tracking. You’ll see two things:
-
Allow Apps to Request to Track — the master switch. When off, no app can even ask. When on, individual apps can request, and you can grant or deny per-app.
-
A list of apps that have requested permission, with toggles. Each toggle is the per-app grant.
If “Allow Apps to Request to Track” is off, the list will be empty (no apps can ask). If it’s on, every app that has prompted you will appear with its current status.
How the master switch behaves
If “Allow Apps to Request to Track” is off:
- Apps can’t show the ATT prompt
- Apps automatically receive a “no” response if they query the system
- Existing per-app grants are essentially ignored — apps act as if denied
If you flip the master switch off after granting some apps, those apps will start behaving as denied. They typically won’t show error messages — they’ll just stop using cross-app tracking.
This is a useful “all off” approach if you don’t want to think about per-app decisions.
What the prompt looks like
When you launch an app for the first time and it requests tracking, you see a system-styled dialog with two options:
- “Ask App Not to Track” (denial)
- “Allow”
The app developer can customize the description string between those options. Apple requires the description to be specific and honest about what the app would do with the tracking permission. Generic “for a better experience” copy doesn’t fly.
You can change your decision later for any app via System Settings → Privacy & Security → Tracking.
What about apps that don’t show the prompt?
Two reasons an app might never prompt:
-
It doesn’t track you. Many apps genuinely don’t need cross-app tracking and never ask. This is common for productivity tools, paid apps, and apps with no advertising business model.
-
It uses workarounds. Some apps use techniques that don’t strictly require IDFA — fingerprinting, probabilistic matching, on-device targeting. These technically don’t go through ATT, though Apple’s policy says they should.
If an app you’d expect to track you never asks, it might be category 1 (good) or category 2 (sketchy). Hard to tell from the outside.
How “Ask App Not to Track” actually behaves
When you tap “Ask App Not to Track”:
- The app receives a denial response
- The app’s IDFA returns as zeros (effectively useless for tracking)
- The app is supposed to honor the denial in its analytics SDKs
- Apple’s policy prohibits the app from using alternative identifiers
The “supposed to” and “Apple’s policy” are doing some lifting. Apple enforces this through App Store policy, but enforcement isn’t perfect. A few apps over the years have been caught using workarounds and have been required to change. Most apps comply.
For users, the practical takeaway: ATT is meaningful but not a perfect shield. Combined with iCloud Private Relay (for IP-based tracking) and Safari’s ITP (for web tracking), it’s a serious dent in cross-context profiling.
What’s the IDFA, anyway?
The IDFA (identifier for advertisers) is a string that Apple’s frameworks expose to apps for the purpose of attributing ads. Before ATT, every app could read your IDFA and use it to associate your activity across ad networks. With ATT, your IDFA only returns to apps you’ve allowed; for everyone else, it returns zeros.
Each Mac and iPhone has its own IDFA. You can also reset it (effectively, get a new one) under System Settings → Privacy & Security → Apple Advertising → Reset Advertising Identifier. Resetting is roughly equivalent to clearing your ad-tracking history — apps see a different ID after the reset and have to start over building a profile.
What about Apple’s own advertising?
Apple sells ads in the App Store and in News. Those use Apple’s first-party advertising platform, which is governed by separate settings under System Settings → Privacy & Security → Apple Advertising. The toggles there control whether Apple personalizes the ads it shows you.
Personalized Apple ads are based on data Apple holds about you (App Store searches, Apple News reading, etc.) and don’t share it with third parties. So even with personalization on, Apple isn’t a data broker. But you can still turn it off if you’d prefer non-personalized ads.
Sandbox containers and ATT
ATT operates at the framework level — it’s about which APIs return what data. Sandbox containers are about file system reach. They’re orthogonal. An App Store app and a non-App Store app both go through ATT the same way for cross-app tracking; both should respect a denial; both can request the prompt.
The sandbox does help with what an app can do after getting a “yes.” A sandboxed app’s network access is bounded by declared endpoints, so the data exfiltration surface is narrower. Direct-download apps from outside the App Store have no such limit.
The “skip the prompt” question
Some users prefer to set “Allow Apps to Request to Track” off and never see prompts. This is a defensible choice — cross-app tracking is rarely worth allowing, and the prompts can be repetitive.
The trade-off: a few apps use the prompt in ways that affect functionality. A handful of free apps make tracking-derived revenue that subsidizes the free tier; denying tracking might reduce features or surface pestering “consider upgrading” messages. This is rare on Mac; far more common on iOS.
For most Mac users, “Allow Apps to Request to Track” off is fine.
Audit checklist
A one-time setup, then occasional review:
- Open
System Settings → Privacy & Security → Tracking - Decide on master switch (recommended: off)
- If on, audit the per-app list — toggle off anything you can’t justify
- Open
System Settings → Privacy & Security → Apple Advertising - Toggle off Personalized Ads if you prefer
- Combine with Private Relay, Mail Privacy Protection, and Safari ITP
App Tracking Transparency on Mac is the same machinery as on iOS, just with fewer apps using it. The sensible default is to keep “Allow Apps to Request to Track” off — you give up almost nothing and you opt out of an entire category of cross-context tracking. For the rare app that genuinely needs it for a feature you want, flip the master switch on temporarily, grant that one, and switch back.