Safari on iOS 27 blocks The Trade Desk's ad domain adsrvr.org

The Trade Desk cannot serve ads in Safari on iPhones and iPads that have installed iOS 27, AdExchanger reported on 29 September 2026, because Apple added the DSP's core ad-delivery domain, adsrvr.org, to a list of domains Safari blocks unconditionally. The same list now covers several identity providers, including the TTD-backed Unified ID 2.0, ID5, Audigent, LiveRamp and Permutive. Apple was still looking into The Trade Desk's complaint at the time of reporting, and neither company commented.

What Apple changed in Safari on iOS 27

According to AdExchanger's 29 September report, iOS 27 extends a policy Apple already had: Safari unconditionally blocks domains belonging to data brokers that do addressable ID matching and help track people across sites. In September 2026 Apple added more names to that list. AdExchanger lists Unified ID 2.0 (which runs on the domain uidapi.com), ID5, Audigent, LiveRamp and Permutive as additions this month.

The identity vendors were the expected part. The surprise was adsrvr.org. Some programmatic buyers know it as the domain The Trade Desk uses for third-party cookies, but the company says it does far more than that. Ian Meyers, The Trade Desk's senior director of engineering, wrote on WebKit's public bug tracker that "Adsrvr.org is The Trade Desk's core ad request and delivery domain, not identity." If Safari refuses every request to that domain, TTD bids and creatives cannot load at all in Safari on updated devices. That makes this a much bigger problem than losing an identifier.

PPC Land, which reviewed the WebKit code and the bug ticket on 30 September, reported that Apple began rolling out iOS 27 on 14 September 2026 and that Meyers filed his bug a week later, on 21 September, with priority P1 and severity Major.

How the block works inside WebKit

The mechanism is public code, but the list is not. PPC Land traced the behaviour to WebKit bug 307853, titled "Unconditionally block requests going to certain domains", opened and committed on 13 February 2026 as commit 307525@main. The change added 11 lines to a single file, WebPrivacyHelpers.mm.

Two details from that analysis matter for advertisers:

• In the open-source build, the check blocks nothing. The actual domain list is pulled in only when WebKit is compiled with Apple's internal SDK, so only Apple knows the full contents and only Apple can remove an entry.
• The check runs before Safari's existing tracker-exemption logic. A domain on the private list is treated as blockable even if Apple's tracker data would otherwise mark it as allowed.

The code also compares the registrable domain (the part a browser treats as the site, such as adsrvr.org) rather than the full hostname. According to PPC Land, that means one entry for adsrvr.org covers every host under it: the cookie-sync subdomain Meyers called legacy, and also the hosts that carry bid requests and creatives. The way the hook is written, Apple cannot block one subdomain and let the others through.

Apple has not published the list. The version circulating comes from Meyers' bug report, which reproduced nine entries: tainted.example, uidapi.com, adsrvr.org, id5-sync.com, eu-1-id5-sync.com, rlcdn.com, pippio.com, permutive.com and ad.gt. PPC Land notes that Apple has not confirmed these contents in the thread.

The timeline so far

The table below sets out the dated events reported by AdExchanger and PPC Land.

What The Trade Desk and Apple have said

The only on-record exchange so far is on the bug tracker. John Wilander, who manages WebKit privacy and ad tech at Apple, replied that he had seen the report and would investigate. When Meyers asked for an estimated date, Wilander's update on Monday 28 September was: "I will let you know if and when any changes are available for you to test." Neither Apple nor The Trade Desk answered AdExchanger's requests for comment before publication.

The bug report also contains a detail that will interest anyone who buys on more than one platform. It shows an ad call on a yahoo.com article in a normal, non-private Safari session. The Trade Desk's bids were blocked. Google's bids, served through the ad.doubleclick.net domain, went through cleanly. PPC Land notes that ad.doubleclick.net is not among the nine entries Meyers listed, and nothing in the thread explains why one buying platform's delivery domain is on the list and another's is not.

AdExchanger described two possible outcomes. In the best case for TTD, the block was an accident and Apple removes adsrvr.org, leaving a few painful weeks behind. In the worse case, WebKit confirms that it intends to keep blocking the domain. As of the 29 September report, Apple had been looking at the ticket for more than a week without a public decision.

Who is affected, and who probably is not

Based on the reporting, the people most exposed are:

• Advertisers and agencies buying open-web display and video through The Trade Desk, for any impression that would have been served to Safari on an iPhone or iPad running iOS 27.
• Buyers and sellers relying on UID2, ID5, LiveRamp, Audigent or Permutive identifiers in Safari on those devices, because those domains are on the same list.
• Publishers whose Safari traffic on iOS 27 was monetised partly through TTD demand.

Some things the sources did not establish. PPC Land says the ticket names only iPhone and iPad under iOS 27, and nothing in it documents Safari 27 on macOS. In-app inventory is a separate path from the Safari browser, and the reporting is about Safari. None of the sources put a figure on lost impressions, spend or revenue. For scale, PPC Land cites Cloudflare data for the third quarter of 2025 that put Safari at 15.1% of global browser traffic, against 66.3% for Chrome. That share covers all Safari versions and devices, not just updated iPhones.

Apple has done this kind of thing before. AdExchanger points out that earlier targeted changes to Apple's tracking policies hurt advertising systems run by Meta and Criteo, among others.

What to check in your own reporting

This section is analysis rather than sourced fact. If you buy through The Trade Desk, the effect should show up as a change in delivery mix rather than an error message, because the browser quietly drops the requests. Things worth checking:

1. Break TTD delivery down by browser and operating system version from 14 September onwards. A drop in Safari on iOS impressions, with spend shifting to Chrome or Android, fits the reported block.
2. Look at pacing and win rates on line items that target iPhone users or audiences that skew heavily towards iPhone. Campaigns that cannot find enough eligible Safari supply may underspend or bid up elsewhere.
3. Compare reach and frequency with the same period last month. Losing a slice of iPhone users can push frequency up among the users you can still reach.
4. If you use UID2, ID5 or LiveRamp segments, check match rates on Safari traffic separately from the rest.
5. When you compare DSP performance, keep in mind that Google's ad.doubleclick.net bids went through in the example in TTD's own bug report. A comparison between platforms over this period may reflect the block rather than buying quality.

On the measurement side, a clean GA4 setup with browser and OS dimensions makes it easier to see whether site traffic from paid display fell on iOS Safari specifically, and to keep that drop from being read as a creative or targeting problem.

What this means for Thai marketers

The sources contain no Thailand-specific data, so this is analysis. iPhone use is high among affluent urban audiences in Thailand, and those users are often the target of premium programmatic campaigns. Thai brands and agencies buying open-web inventory through The Trade Desk, or activating UID2, ID5 or LiveRamp audiences, should check Safari delivery since mid-September before drawing conclusions about campaign performance. Teams that run both TTD and Google buying, including Google Ads display and video, should avoid moving budget purely on a few weeks of numbers where one platform could not reach part of the iPhone audience.

The wider lesson is that one browser vendor can switch a buying platform off for its users with a private list and no notice beyond a bug ticket. Planning that depends on a single DSP or a single identifier carries that risk.

Frequently asked questions

Is The Trade Desk completely blocked on iPhones?

No, the reported block covers the Safari browser on iPhones and iPads that have installed iOS 27. AdExchanger reported on 29 September 2026 that TTD cannot serve ads there because adsrvr.org is on Safari's unconditional block list. Devices on older iOS versions and other environments were not described as affected.

Is the adsrvr.org block intentional?

Nobody has said. Apple did not comment, and WebKit's John Wilander said only that he would report back "if and when any changes are available" to test. AdExchanger presented an accidental block as the best case for TTD.

Which identity providers are on the same list?

AdExchanger names Unified ID 2.0 (uidapi.com), ID5, Audigent, LiveRamp and Permutive as additions in September 2026. The nine-domain list reproduced in Meyers' bug report has not been confirmed by Apple.

Are Google's ads affected in the same way?

Not in the example on record: in TTD's bug report, Google's bids through ad.doubleclick.net went through in the same Safari session where TTD's bids were blocked. The sources did not say whether that holds everywhere.

Do I need to change anything in my campaigns right now?

Nothing is mandatory, but checking TTD delivery by browser and iOS version since 14 September is a sensible first step. The sources did not give a fix date, so plan as if the block could last.

Relevant Audience helps brands in Thailand read cross-platform data when a change like this skews it. If your programmatic, Google Ads or GA4 numbers moved in late September and you want a second look, talk to our team.