Ian Meyers of The Trade Desk wrote on October 5 that he could see changes in Apple's 24B5099f build, about 15 minutes after Apple's John Wilander asked him to try a new iOS 27.2 beta, according to the WebKit Bugzilla record for bug 324771.

In Short

Apple's iPhone browser, Safari, stopped loading ads from adsrvr.org, a web address The Trade Desk uses to deliver ads, because the address sits on a private Apple list of domains that the browser always blocks. On October 5 an Apple engineer asked The Trade Desk to try a new test version of iOS, and a Trade Desk engineer replied that he could see changes, which matters to advertisers buying through The Trade Desk and to publishers whose iPhone visitors may not receive those ads. The bug report is still open and has nobody assigned, so the public record does not show whether the block was lifted, narrowed or left in place.

What the Bugzilla record shows

The October 5 exchange consists of two comments. At 12:29:29 Pacific time, Wilander wrote that a new iOS 27.2 beta had gone out that day, asked Meyers to test with it and thanked him for "the technical documentation you provided." At 12:44:51, 15 minutes and 22 seconds later, Meyers answered that he could see "the changes in the 24B5099f build" and that The Trade Desk would "test and report back if there are any issues."

Neither comment names a domain, a setting or a behaviour. The header fields of the bug, as captured, still read status NEW with the resolution blank, priority P1, severity Major, version Safari 27, hardware iPhone / iPad and operating system iOS 27. The assignee field says Nobody. The record was last modified at 12:44 PDT on October 5, the minute of Meyers' reply. The copy list has grown: PPC Land's September 30 review counted six users on the bug after its September 28 modification, whereas the capture now shows seven.

Only one attachment is listed, number 481466, a 51.16 KB PNG showing blocked requests on a yahoo.com article in non-private browsing. The documentation Wilander thanked Meyers for is not visible in the thread. His first reply, on September 22, mentioned an email: "I also got your email."

The pace of the thread

The timestamps give a measure of how the matter has moved. Meyers filed the bug at 19:13:36 on September 21. Wilander replied a little over 19 hours later, at 14:36:23 on September 22, with "We're investigating." Meyers asked for an estimated time on September 25 at 13:34:49, and Wilander answered on September 28 at 13:48:34 that he would report if and when changes became available to test. That evening, at 19:14:12, the Radar importer linked an internal Apple tracking reference, rdar://problem/188653580. The next comment came just under seven days later. From filing to the October 5 comment, 13 days and about 17 hours passed.

The code behind the list

The mechanism sits in WebKit pull request 58670, titled "Unconditionally block requests going to certain domains". GitHub shows that the webkit-commit-queue merged one commit into WebKit:main from the branch charliewolfe:eng/Unconditionally-block-requests-going-to-certain-domains, dated February 14 in the page's display. The Bugzilla record for the linked bug 307853 puts the commit on February 13 in Pacific time, and PPC Land's September 30 review reconciled the two dates as a time-zone difference. The page lists one commit, one changed file and 11 additions with no deletions. The file is Source/WebKit/Platform/cocoa/WebPrivacyHelpers.mm. The pull request shows two conversation items and no checks.

The diff has two parts. Near line 54, a conditional import pulls in WebKitAdditions/WebPrivacyHelpersAdditions.mm, but only when WebKit is built with Apple's internal software development kit and that file exists. Directly below, a fallback defines IS_REQUEST_UNCONDITIONALLY_BLOCKABLE(domain) as false. In a public build the macro therefore answers no for every domain.

The second part, at lines 773 to 775 inside a function named isRequestBlockable, calls the macro on a value built as a WebCore::RegistrableDomain from the request's host. A registrable domain, which browser engineers also call the eTLD+1, is the public suffix plus one label, so every host under adsrvr.org collapses to adsrvr.org before the check runs. If the macro returns true, the function returns true at once. Below it, existing code looks the domain up in TrackerDomainLookupInfo and returns false where the entry's canBlock() value equals CanBlock::No. The new check runs first, so a listed domain is reported as blockable before that branch is reached.

Two consequences follow from the structure. A change to the list would travel inside Apple's build, in a file the public repository names but does not contain, rather than as a public commit. And because the macro receives a registrable domain and no hostname, a list entry covers the whole domain. The capture also cuts off the function signature after "needsAdvan", so the diff alone does not show whether a user-facing privacy setting gates the check.

Nine entries from one list

Apple has not published the list. The version in circulation comes from Meyers, who wrote that the pull request "introduced unconditional blocking to Webkit/Safari, which bundled the following in Safari 27" and then gave 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. The bug does not say how he assembled it, and nothing from Apple in the thread confirms the contents.

PPC Land's September 30 review matched the entries to companies: uidapi.com to the Unified ID 2.0 programme, ID5 for the two id5-sync.com hosts, LiveRamp for rlcdn.com and pippio.com, Permutive for its own domain and Audigent, now part of Experian, for ad.gt. The first entry uses a reserved .example name, which the same review read as a test fixture. According to AdExchanger, which reported the block on September 29, neither Apple nor The Trade Desk responded to requests for comment before publication.

Meyers, whom AdExchanger identifies as The Trade Desk's senior director of engineering, rests his argument in the bug on a distinction between identity and delivery. He wrote that the intent "seems to be to hard block domains that power 'post-cookie' identity" but that "adsrvr.org is The Trade Desk's core ad request and delivery domain, not identity." He added that the match subdomain operates on "legacy third-party cookies." That subdomain is the host associated with cookie syncing, and Safari has blocked all third-party cookies by default since March 24, 2020.

Whether the other eight entries moved with adsrvr.org in the 24B5099f build is not stated anywhere in the attached record. One Reddit commenter, using the handle mcpapaya, wrote: "I think that only saved adsrvr.org but not the identity providers including UID." The same commenter asked whether anyone had yet tested the beta. No reply in the capture answers.

What the Reddit thread adds

A separate source of reaction is a thread titled "Apples Update" in r/programmatic, a community created on March 11, 2014 that lists 6.7K weekly visitors and 215 weekly contributions. The original poster, u/mass_mike47, says they no longer work at a programmatic company and asks whether the Apple update will "completely change programmatic," describing it as an attempt to "block all targeting and attribution on safari which is 50% of mobile traffic." No source for the 50% figure appears in the thread. PPC Land's September 30 review cited Cloudflare data for the third quarter of 2025 that put Safari at 15.1% of global browser traffic, against 66.3% for Chrome. The two figures use different bases, mobile traffic in one case and all browser traffic in the other, and the thread does not reconcile them.

The captured replies, sorted by controversial, split in several directions. A commenter named cheerycherry2501 wrote "They have fixed it. It was a mistake" and linked to bug 324771, though that comment carries no votes and the bug's status is still NEW. Another, Crazy_Cat_Dude2, had not yet seen people panicking among clients in Canada. Emotional_Waltz_6542 wrote that "3P data doesn't cut it anymore," and hdiggyh wrote that first-party data and identity "has been the answer," which drew a reply asking how that is going. The original poster answered that the issue is the serving of ads: first-party data does not help if the domain where The Trade Desk serves ads is blocked, adding "I could be misinterpreting it."

Two further commenters moved away from the technical question. The user goodgoaj argued that reliance on user IDs has been irrelevant for a long time, while AlanWegrzyn described how hard it is to move senior staff away from cost-per-acquisition metrics. SaltPathOptimization wrote that "No one but media people are talking about it." The capture shows only relative timestamps, such as two hours ago, so the thread's date is not stated, and the comments that mention a beta do not say which one.

Why the record matters beyond one domain

The distinction Meyers drew carries weight for anyone tracking how Safari treats advertising infrastructure. A block on identity endpoints lowers what a buyer can know about a visitor and, in turn, what a bid is worth. A block on the delivery domain removes the request altogether. PPC Land's September 30 review framed the issue in those terms, and the Reddit original poster voiced the same concern in a reply.

The company at the centre arrives with its own pressures. The Trade Desk cut about 575 jobs on September 4, around 15 percent of its workforce, and lost its S&P 500 seat the same day. Nothing in the attached documents connects those events to the Safari list, and PPC Land's reporting treated them as separate developments.

Apple's direction on tracking is also well documented. A July review of the Safari 27 beta found network-layer blocking and a category of unconditionally blockable domains whose contents sat in an unpublished Apple file. Safari 26 made Advanced Fingerprinting Protection the default for all browsing sessions. And iOS 27.2, the release that carries the October 5 beta, is the same point release in which Apple told developers on September 16 that an alternative App Tracking Transparency prompt would become mandatory in Germany, France, Italy, Poland and Romania.

Several questions remain open in the record as it stands:

  • Scope of the change: the thread does not say whether the 24B5099f build removes adsrvr.org, alters how the check treats it, or changes something else.
  • The other eight entries: nothing in the bug or the pull request addresses whether identity domains such as uidapi.com or id5-sync.com are affected.
  • Release path: the thread does not say whether the changes will reach the production release of iOS 27.2, or when that release will ship.
  • Platforms: the bug names only iPhone and iPad under iOS 27, and nothing in it documents behaviour on Mac.
  • Resolution: the bug remains NEW with no assignee, so the formal outcome is undecided even if the build behaves differently.

Meyers has said The Trade Desk will report back if testing turns up issues. Any further comment would appear in the same Bugzilla thread.

Timeline

Summary

Who: Ian Meyers of The Trade Desk and John Wilander of Apple, who manages WebKit privacy and ad tech according to AdExchanger, in a Bugzilla thread opened by Meyers; Charlie Wolfe authored the February change; forum users on r/programmatic reacted separately.

What: Wilander told Meyers that a new iOS 27.2 beta had gone out, and Meyers replied that he could see changes in the 24B5099f build and would report back after testing. The record does not state what changed, and bug 324771 remains NEW with no assignee. The underlying mechanism is an 11-line WebKit change that consults a private Apple list before WebKit's tracker exemptions.

When: The exchange took place on October 5, 2026, between 12:29 and 12:44 Pacific time. The bug was filed on September 21, 2026, and the WebKit change dates from February 13, 2026 in Pacific time.

Where: WebKit Bugzilla for the bug, GitHub for pull request 58670, and Reddit's r/programmatic for the reaction. The bug concerns Safari 27 on iPhone and iPad running iOS 27.

Why: The Trade Desk's ad request and delivery domain, adsrvr.org, appears on a list of domains that Safari blocks unconditionally, which Meyers describes as aimed at post-cookie identity rather than ad delivery. The October 5 exchange is the first point in the record at which Apple points to a build for testing, and whether it resolves the block is not yet public.