Apple's iOS 27 Quietly Cut The Trade Desk Off Safari (and Buyers Weren't Told)
Apple's iOS 27, released September 14, 2026, added adsrvr.org to WebKit's tracking blocklist, and according to AdExchanger that domain is The Trade Desk's core ad request and delivery endpoint, not an identity service. The result: TTD campaigns have been unable to serve ads in Safari on updated iPhones for roughly two weeks, and buyers got no platform notice.
I want to be careful about the framing here, because the headline version ("Apple blocks The Trade Desk") makes it sound like a deliberate strike. It might not be. The more likely story, and the one AdExchanger floats as the best case, is that Apple swept adsrvr.org in with a batch of identity and data vendors and caught the ad-serving pipe along with the cookie-matching pipe. Intent matters for how long this lasts. It matters a lot less for what your campaigns did over the last 15 days.
Apple wasn't aiming at the pipe, but it hit it anyway
September was a busy month for the WebKit blocklist. Per the same AdExchanger report, Apple also added UID2's domain (UIDAPI.com), ID5, Audigent, LiveRamp and Permutive. That list reads like a who's-who of post-cookie identity, which fits Apple's stated position. The WebKit Tracking Prevention Policy says it does not grant exceptions to specific parties, and it treats cross-site data collection as tracking whether or not anyone thinks the data is personally identifiable.
The problem is that adsrvr.org does two jobs. It's the domain TTD has historically used for its third-party cookie, and it's also the domain that requests and delivers the ad. Block it for the first reason and you kill the second as a side effect.
The public record on this is, honestly, a GitHub thread. TTD senior director of engineering Ian Meyer asked the WebKit team to reconsider, writing that "Adsrvr.org is The Trade Desk's core ad request and delivery domain, not identity." WebKit privacy manager John Wilander replied that he would "let you know if and when any changes are available for you to test." That's more or less the whole exchange as of this week. No ETA, no official statement from either company.
Wry side note: the most consequential ad-supply change of the quarter is being negotiated in a bug tracker with the polite energy of a support ticket.
Why a Safari hole is bigger than it looks in your dashboard
Safari held 52.84% of US mobile browser share in August 2026, with Chrome at 41.17%, per StatCounter. Not every Safari user is on iOS 27 yet, and adoption of a two-week-old OS is still ramping. But the cohort that updates first tends to skew toward newer, more expensive iPhones, which is to say the audience a lot of advertisers pay a premium to reach.
This is the part I think gets missed. A blocked request doesn't show up as a failure in most DSP reporting. It shows up as nothing. The bid never happens, the impression never serves, and the pacing algorithm quietly moves the money somewhere it can clear. If your campaign was set to spend its budget, it probably spent its budget. It just spent it on Chrome and Android and in-app supply instead.
On paper that's fine. Budget delivered, CPMs in range. In practice you may have shifted a meaningful slice of spend away from the audience you planned for, and your reach and frequency reports will undercount iPhone Safari users without flagging why.
A blocked domain doesn't throw an error. It just makes a slice of your audience disappear from the auction.
Think of it like a store that loses its front door and doesn't notice because the side entrance keeps foot traffic steady. Totals look normal. Who walked in did not.
Safari 27 was already stricter before this
This didn't come out of nowhere. Safari 27 moved tracking enforcement down the network stack. PPC Land's review of the Safari 27 source found the browser now checks destination IP ranges and can terminate connections to known ad infrastructure before the request completes, which is how Bing's UET endpoint and LinkedIn's Insight Tag got caught. First-party proxying doesn't get around that, since Safari evaluates where the request is actually going.
Stape's breakdown adds that Safari 27 extends link tracking protection to Threads, YouTube and X click IDs, and reclassifies tools like Tealium and Segment as fingerprinting scripts. Worth flagging: the two writeups don't fully agree on which protections are on by default versus limited to Private Browsing, and both were written against beta builds. I'd treat the specifics as "test it yourself" rather than settled. We covered the earlier version of this problem when Safari 26 started stripping GCLID, and the direction of travel has only gotten steeper.
And to be fair, none of this is new in spirit. Apple has done targeted blocking that hit Meta and Criteo before. It just used to hit measurement. This time it hit delivery.
Pull these three reports before your next buy
You don't need to wait for Apple or TTD to sort this out to find out whether it cost you anything. Roughly what I'd do, and it's maybe a 20-minute job for a single advertiser:
1. Browser and OS split, September 1 to today. In TTD reporting, break out impressions and spend by browser and OS version, and compare September 1 to 13 against September 14 onward. If Safari's share of your mobile web impressions dropped by more than about a third while total spend held flat, the block is almost certainly the cause. A drop of a few points is probably just normal iOS adoption noise.
2. Where the money went. Check whether mobile web CPMs rose after September 14. If Safari supply vanished and the algorithm refilled with Chrome and Android inventory, I'd expect effective CPMs to creep up a bit on campaigns with tight audience targeting, since there's less supply chasing the same segments. Honestly I'm not sure how big that effect is, and it'll vary a lot by vertical, but it's worth a look.
3. Reach and frequency against your plan. If your media plan assumed a certain iPhone share of reach, your delivered reach report is now undercounting it. Flag that in any wrap report going to a client or CMO before someone reads it as a performance problem.
If the numbers show real leakage, the pragmatic move for the next few weeks is to cover iOS Safari through a second path, whether that's another DSP, a direct deal, or in-app inventory where the WebKit blocklist doesn't apply in the same way. I wouldn't restructure a whole annual plan around a block that could get reversed next week. I would stop assuming it'll be reversed.
What this does to the TTD negotiation
The timing is rough for The Trade Desk. On its Q2 2026 earnings call the company reported $715 million in revenue, up just 3% year over year, and guided Q3 to at least $650 million, a step backward from the quarter it just posted. When we wrote that TTD's fee had become negotiable, this is the kind of leverage we meant. A DSP that can't reach the largest US mobile browser for weeks, with no customer notice, is a DSP whose account team should be expecting some pointed questions.
My prediction, for what it's worth: Apple carves out or narrows the adsrvr.org rule within 60 days, because blocking ad delivery outright goes further than its own policy language about tracking. But I'd put maybe 30% odds on the fix arriving with conditions attached, like TTD having to split identity and serving onto separate domains, which would be a real engineering project and not a quick patch.
The slightly uncomfortable thought I keep coming back to is that most buyers seem to have found out about this from a trade publication. Not from their DSP, not from their dashboards. If a two-week Safari blackout on a major DSP can slip past normal reporting, it's probably worth asking what else your reports would never show you, and building a browser split into your weekly checks so the next one takes days to spot instead of weeks.
Notice Me Senpai Editorial
