What changed in iOS 27?

The issue concerns WebKit, the browser engine used by Safari and other browsers on iOS. WebKit has long implemented tracking prevention measures intended to limit cross-site tracking and certain forms of persistent identification.

In September 2026, The Trade Desk’s engineering team reported that adsrvr.org had been included in WebKit’s IS_REQUEST_UNCONDITIONALLY_BLOCKABLE domain list. The public issue described requests being blocked on iOS 27 while viewing a webpage in ordinary, non-private browsing.

The significance was that the domain was not used exclusively for identity matching. The Trade Desk identified it as a core domain for ad requests and delivery. A restriction associated with cross-site identity infrastructure could therefore interfere with an actual advertising request.

The public record confirms the specific domain issue and its resolution. It does not establish that every advertising request, every browser, or every programmatic platform was affected in the same way. Read the WebKit bug report.

What is confirmed, and what remains uncertain?

Which advertising technology companies were affected?

Reporting by AdExchanger identified several advertising data and identity vendors associated with the initial restrictions, including LiveRamp, ID5, Permutive, Audigent, and The Trade Desk’s Unified ID 2.0 ecosystem. The public WebKit report also lists domains such as id5-sync.com, rlcdn.com, and permutive.com.

These names should be treated as reported examples, not as a complete, permanently accurate blocklist. WebKit has not published a comprehensive public list in the cited issue, and individual vendor domains, endpoints, and implementation methods may behave differently.

AdExchanger subsequently reported that Apple could be considering a broader list of advertising and data companies. That broader claim was based on industry sources and should be attributed to that reporting rather than presented as an official Apple announcement. Read AdExchanger’s industry analysis.

Why domain-level restrictions can have wider effects

An advertising technology domain may support several different operations. Depending on the vendor’s architecture, requests to that domain might be used for identity synchronization, audience matching, bid requests, ad delivery, or related measurement tasks.

When multiple operations share a domain, a restriction intended to prevent a tracking-related request can have consequences for other requests using the same domain. This is an architectural risk, not proof that every vendor using a shared domain will experience the same failure.

How can browser restrictions affect programmatic advertising?

Programmatic advertising depends on a sequence of technical interactions between the publisher’s page, its ad server, supply-side technology, demand-side platforms, and measurement systems. A failure at one point can affect subsequent steps, but the consequences depend on the implementation.

1. Ad requests and delivery

If a required ad-delivery request is blocked, an ad may fail to load even if other parts of the page work normally. Depending on the setup, the result could be a blank ad slot, a delayed response, a fallback creative, or another delivery path.

2. Identity synchronization and audience matching

Identity vendors help participating platforms associate data across environments, subject to their technology and applicable consent requirements. If an identity-sync request fails, the systems involved may have fewer usable matching signals.

This does not automatically prevent an ad from serving. A campaign may still qualify through contextual targeting, publisher first-party data, other permitted signals, or a different demand source.

3. Bid eligibility and auction competition

Some demand-side platforms use audience or identity signals when deciding whether to bid. If those signals are missing, a buyer might not participate in an auction or might value the impression differently. Other buyers may still compete for the same inventory.

The result can vary by browser version, publisher implementation, campaign targeting, demand partner, and fallback behavior. It is not safe to assume that every blocked identity request results in a lost bid.

4. Measurement and attribution

Restrictions on identity or measurement endpoints may complicate user matching, conversion attribution, and cross-channel reporting. This can create differences between what an ad platform records and what an advertiser or publisher observes in another system.

Ad operations teams should distinguish between a genuinely undelivered ad, an impression that was delivered but measured differently, and a conversion that could not be attributed. These are different problems and need different investigations.

What does this mean for publishers and AdOps teams?

The immediate lesson is to validate actual delivery rather than relying on a single reporting metric. Browser-specific restrictions can affect one vendor or endpoint without producing an obvious, site-wide outage.

Can iOS 27 reduce publisher CPM?

It can be a contributing factor under some conditions, but a CPM decline is not an automatic outcome of a browser restriction. The effect depends on whether valuable demand is lost, whether alternative bidders remain available, and whether the publisher’s inventory can still be targeted and measured effectively.

CPM is the cost per thousand ad impressions from an advertiser’s perspective. Publisher monetization teams often use eCPM to understand revenue per thousand impressions. Both metrics need context: changes in geography, device mix, seasonality, consent, ad format, and auction competition can also change the observed result.

For a refresher, see CPMinsider’s guide to eCPM in advertising.

How to audit iOS 27 ad delivery: a practical checklist

Publishers do not need to redesign their entire advertising stack simply because a browser restriction has been reported. Start with a controlled investigation and change the implementation only when the evidence identifies a specific failure.

Step 1: Establish a baseline

• Record ad requests, rendered impressions, revenue, and relevant delivery metrics before comparing periods.
• Segment results by browser, operating-system version, device, geography, and major ad placement where reliable data is available.
• Check whether traffic mix, consent rates, or campaign demand changed during the same period.

Step 2: Reproduce the behavior

• Test a representative page on the relevant Safari and iOS versions.
• Use browser developer tools, remote debugging where supported, and network logs to inspect failed requests.
• Compare the same page and placement in a control environment, keeping other variables as consistent as possible.
• Record the exact endpoint, response or failure, timestamp, browser version, and test conditions.

Step 3: Identify the failing layer

• Determine whether the failure concerns identity synchronization, an ad request, a bidder response, creative loading, or measurement.
• Check whether the request is blocked by the browser, rejected by the endpoint, delayed, or failing for an unrelated reason.
• Review ad-server and bidder logs alongside browser observations wherever possible.

Step 4: Verify the latest status

• Check the official WebKit issue for updates to the specific restriction being investigated.
• Test the relevant stable and beta software versions separately.
• Confirm the affected vendor’s guidance before changing domains, tags, identity integrations, or auction configuration.

Step 5: Quantify business impact

• Compare request volume, rendered impressions, fill rate, revenue, and eCPM across comparable segments.
• Look for discrepancies between auction wins, ad-server records, and rendered impressions.
• Document the likely cause, confidence level, affected inventory, mitigation, and follow-up testing.

What are the longer-term implications for AdTech?

First-party data and direct integrations

Publishers may place greater emphasis on their own authenticated audiences, consented first-party data, and direct integrations with advertising partners. These approaches can improve control over data relationships, but they do not automatically guarantee addressability or permission to use data across contexts.

Server-side advertising infrastructure

The industry is also exploring server-side approaches that move certain advertising operations away from the browser. AdExchanger has discussed the IAB Tech Lab’s Trusted Server work in this context. Server-side infrastructure can change where requests are processed, but it does not remove the need for lawful data use, appropriate consent, security, and transparent measurement.

Less dependence on a single identity signal

Publishers and buyers should avoid treating any one identifier as a universal foundation for monetization. Contextual advertising, direct audience relationships, consented first-party data, and multiple demand integrations can provide different ways to support advertising. Each has trade-offs involving scale, measurement, implementation cost, and audience relevance.

More rigorous operational monitoring

Browser and operating-system changes are a reminder that a programmatic setup needs ongoing technical validation. Monitoring should connect the browser’s behavior with bidder responses, ad-server outcomes, and commercial reporting rather than treating those systems as interchangeable.

Frequently asked questions

Conclusion: Treat browser compatibility as part of ad operations

The iOS 27 incident demonstrates why publishers and programmatic advertising teams need visibility into the full delivery path, from identity and auction requests to rendered impressions and revenue reporting.

The specific adsrvr.org issue has been marked fixed in the public WebKit tracker, but that is not evidence that every related restriction has disappeared. The responsible next step is to monitor official updates, test relevant browser versions, and investigate measurable delivery discrepancies before changing the advertising stack.

For AdOps teams, the most useful response is a repeatable process: establish a baseline, reproduce the issue, isolate the failing layer, verify the current software status, and quantify the impact. This turns a fast-moving privacy story into an actionable operational workflow.

Sources and further reading

1. WebKit Bugzilla: Inclusion of adsrvr.org in the IS_REQUEST_UNCONDITIONALLY_BLOCKABLE domain list . Primary technical record, reported September 21, 2026; resolution confirmed October 9, 2026.
2. AdExchanger: How Data And Ad Tech Vendors Are Preparing For The iOS 27 Fallout . Industry reporting published October 8, 2026.
3. AdExchanger: Apple Has Far-Reaching Plans To Block Hundreds Of Programmatic Data Companies From iOS . Industry reporting published October 2, 2026; broader blocklist claims are attributed reporting, not an official Apple announcement.
4. WebKit: Tracking Prevention in WebKit . Official background on WebKit’s tracking-prevention mechanisms.