# Apple's Secret List and What It Means for Your Safari Revenue
Since iOS 27, Safari refuses to talk to a list of ad tech companies that nobody outside Apple has seen in full. Everyone in ad tech is now checking whether they're on it. Some publishers are already watching bids on their Safari traffic drop, and many are still working out how bad it is ([Digiday](https://digiday.com/media/apples-safari-ad-tech-blocklist-sends-publishers-back-to-iab-tech-labs-trusted-server/)).
The Trade Desk got most of the headlines, and its part is already being fixed. The bigger story for publishers is what stays blocked: much of the identity layer the industry built to replace cookies, switched off on every iPhone that updates. And Apple can now add more companies to the list whenever it likes.
## What Apple actually blocked
The known part of the list is short. The bug report The Trade Desk filed with WebKit names domains belonging to Unified ID 2.0, ID5, LiveRamp, Permutive and Audigent, plus The Trade Desk's own ad server ([PPC Land](https://ppc.land/safari-27-blocks-the-trade-desks-ads-via-11-lines-webkit-merged-in-february/)).
The Trade Desk was the loud part of the story. Apple has since taken its ad server off the list in a test version of iOS ([Digiday](https://digiday.com/media/ad-industry-tallies-early-losses-from-apples-safari-tracking-block/)). That looks like a mistake being corrected.
The identity providers are a different story. They are still blocked, and they look like the actual target. These are the companies whose job was to recognise the same reader across sites once cookies were gone.
Three details make this bigger than it first looks:
- **It's every browser on the iPhone, not only Safari.** Apple makes all iOS browsers run on its WebKit engine, so Chrome on an iPhone follows the same list ([Commerce News Desk](https://commercenewsdesk.com/briefs/apple-blocks-major-ad-tech-firms-in-safari-via-secret-ios-27-lis)).
- **The list can grow without an update.** AdExchanger reports that Apple can now change it remotely, and is working on a far longer version covering hundreds of ad tech, data and identity companies ([Archon](https://archonph.com/article-apple-webkit-remote-blocklist-programmatic-data-2026.html)).
- **Nobody outside Apple can see it.** The code that does the blocking is public. The list itself is not.
## Why this hits harder than it looks
Globally, Safari is about a quarter of mobile browsing, so it's tempting to shrug this off. That number hides where the money is. In the wealthy markets where premium publishers earn most of their revenue, it's close to half.
Sources: TechnologyChecker Q3 2026 (US, Australia, UK, Canada, Japan, global); StatCounter June 2026 (Denmark, Norway, Sweden).
The US is the one large market where Safari beats Chrome on mobile, and the Nordics are right behind it. Japan is climbing too: StatCounter had Safari at almost 47% of Japanese mobile browsing in September ([StatCounter](https://gs.statcounter.com/browser-market-share/mobile/japan)). For a publisher in any of these markets, this isn't a niche browser problem. It's half the mobile audience.
## What publishers actually lose
Safari has blocked third party cookies since 2020, and buyers have priced that in for years. Every study I've seen shows Safari earning well below Chrome for the same kind of impression.
Sources: Raptive via AdExchanger; Mediavine via Index Exchange; Bidswitch via IFS working paper.
Alternative IDs were how publishers clawed some of that back. They let buyers recognise the reader again, and buyers paid for it:
> In one published case, CPMs in cookie restricted browsers more than doubled when an alternative ID was present in the bid request. ([Index Exchange](https://www.indexexchange.com/2022/05/16/mediavine-cpm-lift-cookie-restricted-browsers-globally/))
That lift is what iOS 27 just took away for anyone using the blocked providers. The impression still sells, just without the ID, and buyers bid accordingly.
To be fair, not every study finds effects that big. Pubstack found IDs raised how often buyers bid by 2% to 10%, with prices barely moving ([summary on Medium](https://acfou.medium.com/abstract-2fefd374edb2)). The impact will vary a lot by publisher and by who buys their inventory. Which is exactly why it's worth checking your own numbers rather than trusting anyone's average, including mine.
## What's left when the ID is gone
The page is left. What the article is about, the topics it covers, the kind of reader it attracts. None of that depends on tracking anyone, so there is nothing for Apple's list to switch off.
So the signals that survive are the ones that describe the content, travel in standard fields, and don't need a call from the reader's phone to a third party.
## What Neuwo adds to the bid request
This is the work we do at Neuwo every day. Our [bid enrichment](/solutions/bid-enrichment/) reads the page, classifies it into the standard IAB content and audience taxonomies, and puts those segments into the bid request in the normal OpenRTB fields. No IDs, no cookies, nothing about the person reading. Because it works per page and not per person, it can also run on the publisher's own server instead of the reader's phone.
What we've seen so far in live tests, before any of this Safari news:
> At a Japanese sports publisher, the same buyers paid about 20% more for impressions carrying our signals than for ones without, and 11 of 13 buyer networks paid more.
>
> In a split test with a LATAM news publisher, revenue rose 38% on the enriched side. About two thirds of the gain came from winning more impressions, not from higher prices.
That second point matters. Enrichment mostly makes inventory easier to buy. That is exactly the problem iOS traffic now has.
Here's where I think it plays a crucial role:
- **Publishers who relied on Permutive, LiveRamp, UID2 or ID5.** Their audience segments just went dark on iOS 27. Content derived segments are the most direct replacement they can switch on quickly.
- **Publishers in iPhone heavy markets.** In Japan, the Nordics, the UK, the US and Australia, iOS is close to half of mobile traffic. That's a lot of inventory clearing with less information than it did a month ago.
- **Publishers using Google Ad Manager.** Our segments also flow into Ad Manager as [publisher provided signals](/blog/google-pps-bid-enrichment/), so the same context reaches the buyers bidding there.
- **Performance buyers.** In our Japanese test, retargeting and performance networks moved most when they got our signals. Those are the buyers who just lost their identifiers on the iPhone.
## What I'd do now
Not every publisher has felt this yet. Some say they haven't seen any impact so far. That's partly because iOS 27 is still rolling out, and partly because few people have looked. Here's where I'd start:
1. **Split your Safari numbers by iOS version.** Compare bid rate, number of bidders and eCPM on iOS 27 against earlier versions. If a vendor drops out, you'll see it in days instead of at month end.
2. **Make every bid request describe the page.** This is exactly what Neuwo does. We add standard content and audience segments to every impression, in the bid request and in Ad Manager, with no ID involved. When an ID gets blocked, buyers still know what they're bidding on.
3. **Test it on your own iPhone traffic.** We run split tests with publishers: half the traffic with Neuwo signals, half without, read by browser and iOS version. You see the effect on your own revenue, not on someone else's average.
Apple has shown it can change the rules overnight, and it will probably do it again. The publishers who come out of this fine won't be the ones who found a cleverer ID. They'll be the ones whose inventory still makes sense to a buyer with no ID at all. That's what we built Neuwo for.
[Talk to us](/contact/)
