HN Debrief

Apple's App Tracking Transparency treated its own apps better than rivals

  • Regulation
  • Privacy
  • Mobile
  • Competition
  • Apple

The regulator’s announcement is not a broad finding that Apple secretly used the same third-party tracking mechanism it banned for everyone else. It is narrower and more structural. Apple’s App Tracking Transparency regime forced third-party apps to use a tightly constrained prompt to access the Identifier for Advertisers and track users across other companies’ apps and websites, while Apple’s own personalized ads relied on first-party data from its ecosystem and therefore sat under a different consent flow. Germany’s Bundeskartellamt says that difference mattered because Apple controls the operating system, the App Store, and its own ad inventory at the same time. Apple has now committed to making its own prompts and third-party prompts much closer, and to giving publishers more room to explain why they want personalized ads.

If you build on iOS, treat this as another sign that regulators are targeting Apple’s dual role as platform owner and app competitor, not just App Store fees. If you care about privacy UX, watch the implementation closely because "equal treatment" can easily turn into more room for ad-tech to persuade users rather than less tracking overall.

Discussion mood

Mostly skeptical and cynical. People were unsurprised that Apple gave itself a better position, but many were equally unhappy that the remedy appears to equalize downward by making ad consent easier for everyone rather than improving privacy for users.

Key insights

  1. 01

    Competition law can lower the privacy bar

    Leveling the playing field is the whole job here, and that produces a very different outcome from a privacy case. The regulator only needed Apple to stop using a better consent path for itself. That leaves Apple free to relax constraints on rivals instead of accepting stricter prompts for its own ads. The result can be more symmetry and less user protection at the same time. One commenter tied that directly to weak GDPR enforcement against big platforms, which makes Apple’s stricter ATT design look less like a privacy baseline and more like selective pressure on competitors.

    Do not assume a competition win will improve user privacy. If your product depends on consent flows, model both outcomes in advance because regulators may force parity without choosing the privacy-maximizing version.

      Attribution:
    • rad-b #1
    • kmeisthax #1
  2. 02

    The deeper issue is missing third-party system hooks

    ATT is just one visible example of a broader platform design choice. The bigger competitive edge comes from Apple deciding which apps are treated as part of the system and which are forever outsiders. Several comments made the same point through different examples: no equivalent photo library integration for alternative photo apps, no user-grantable rights for app installation flows like Steam, and no way to swap in third-party components that get the same OS-level standing as Apple’s own. That shifts the argument from "should built-in apps prompt for permission" to "why can users not delegate those capabilities to competitors at all."

    If you are building an iOS app that competes with a built-in Apple experience, the real constraint may be lack of extension points and entitlements, not prompt wording. Track where Apple withholds user-delegable capabilities because those are stronger sources of lock-in than any single privacy dialog.

      Attribution:
    • AnthonyMouse #1 #2
    • dwaite #1
  3. 03

    Many permission prompts exist for good reasons

    A useful corrective was that some prompts people find annoying are still doing real work. Even when an app’s purpose seems obvious, blanket exemptions create bad defaults. Google Meet is a good example. It is clearly a camera app in practice, but a user may still want it installed without camera access most of the time. The same goes for photo access. Apps often ask for full library permission just to render a custom picker, even though the system picker can avoid that entirely. That distinction matters because "obvious functionality" is not the same thing as "unconditional access."

    When designing app permissions, separate user intent from app category. Prefer OS-provided pickers and narrow-scoped access where possible, because many users want the function without granting permanent broad permissions.

      Attribution:
    • whstl #1
    • tpmoney #1
  4. 04

    Developers felt pressure to soften consent language

    One firsthand account claimed Apple pushed a health-data app team toward more favorable wording in data-sharing requests. If accurate, that suggests the issue was not just formal rule design but a culture of steering consent UX in ways that benefit platform goals while developers have little room to push back. That makes the regulator’s focus on prompt design feel less cosmetic than it first appears.

    If your app depends on regulated or sensitive permissions, document any platform guidance around consent copy and screenshots. Those interactions can become material if regulators start looking at how platform policy is enforced in practice, not just what the written rules say.

      Attribution:
    • bleakcrate #1

Against the grain

  1. 01

    Apple was not accused of third-party style tracking

    The cleanest defense of Apple was that ATT was built around access to the Identifier for Advertisers and cross-company tracking, while Apple’s own ad system used first-party data from its own ecosystem. On that reading, Apple did not exempt itself from the exact same rule it imposed on others. It operated under a different data model, which is why it was under a different prompt in the first place. The regulator’s problem was unequal competitive impact, not proof that Apple secretly broke its own tracking rule.

    Keep the legal distinction straight between first-party data use and cross-company tracking. If you comment on or plan around ATT-style rules, the competitive question and the privacy question are related but not identical.

      Attribution:
    • Despegar #1 #2
  2. 02

    Built-in apps should not prompt like strangers

    A few comments pushed back on the idea that first-party apps and third-party apps should be treated identically at the permission layer. The practical argument is simple: a phone should work out of the box, and users reasonably expect the bundled camera or photo viewer to access the camera and photo library without turning the experience into Windows Vista-era prompt spam. That view does not excuse hidden access to extras like location, but it rejects pure formal equality as a design goal.

    When evaluating platform remedies, distinguish between baseline device functionality and adjacent data uses. Forcing identical prompts everywhere can create noise that teaches users to click through instead of making more informed choices.

      Attribution:
    • labcomputer #1
    • cedilla #1

In plain english

App Tracking Transparency ↩
Apple’s iOS policy and prompt system that requires apps to ask users for permission before tracking them across other companies’ apps and websites.
ATT ↩
App Tracking Transparency, Apple’s framework for asking permission to track users across other companies’ services.
entitlements ↩
Special permissions on Apple platforms that let an app use restricted capabilities not available to all apps by default.
first-party data ↩
Data collected and used by the same company within its own products and services, rather than shared across separate companies.
GDPR ↩
General Data Protection Regulation, the European Union's privacy law governing personal data handling.
Identifier for Advertisers ↩
A device-level identifier on Apple platforms that advertisers can use to recognize a user or device across apps and services.
third-party tracking ↩
Tracking a user across apps or websites run by different companies, usually for advertising or measurement.

Reference links

Regulator documents

Related reporting and prior cases

Technical examples and side references