Safari Now Blocks Ad Identity Tools on iPhone and Mac. What Apple's iOS 27 Change Means for Your Ad Revenue

If your site earns from display ads, a change Apple shipped in September is starting to show up in what those ads pay. Safari in iOS 27 and macOS 27 now cuts off a group of ad technology companies that turn a reader's email address into a tracking ID, and early data from one ad revenue platform shows advertisers bidding less for readers on updated Apple devices.

This guide explains what Apple changed and why, what the first numbers show, and what a publisher can do this quarter. Every figure comes from Apple's own WebKit blog, the public WebKit bug tracker or data published by the companies that measured it, and we mark where their findings stop and our reading begins. If you want the wider case for spreading income before the detail, our guide to publisher revenue diversification covers it first.

What Apple changed in Safari

On October 19, WebKit engineers John Wilander, Charlie Wolfe and Matthew Finkel published a post titled "Blocking Identity Resolution Infrastructure." It describes a tracking method that grew up after Safari fully blocked cross-site cookies six years ago, which Apple calls identity resolution.

In Apple's description, third parties that are not the website owner "invisibly collect your email address when you log in or sign up for a newsletter." They then create "an opaque tracking ID permanently linked to your email address" and send that ID back to the page, where it can be used for purposes such as "targeting ads at you across websites."

The response is blunt. "In our iOS, iPadOS, macOS, and visionOS 27 releases, Safari and WebKit block network access to identity resolution infrastructure to prevent cross-site tracking," the post says. Apple adds that the blocking "is done on the domain level, meaning they can't just change the structure of the network request to work around the protection."

The post names no companies and publishes no list. The names come from a bug report that Ian Meyers of The Trade Desk filed on the public WebKit tracker on September 21, which reproduced nine entries bundled into Safari 27. They include uidapi.com, the domain behind the Unified ID 2.0 system, along with domains belonging to ID5, LiveRamp and Permutive, and The Trade Desk's own ad serving domain, adsrvr.org.

The Trade Desk's ad server was caught, then restored

The bug report matters for publishers because of one entry on that list. Meyers wrote that adsrvr.org "is The Trade Desk's core ad request and delivery domain, not identity," so blocking it did more than stop tracking, because it stopped that buyer's ads from loading in Safari on updated devices.

Apple engaged on the ticket. On October 5, Wilander wrote that "a new iOS 27.2 beta went out today" and asked The Trade Desk to test it, and on October 9 he marked the issue "Confirmed resolved." Digiday reported on October 27 that Apple partly restored The Trade Desk's ad server in early October while Unified ID 2.0 and the other identity vendors stayed blocked.

That sequence explains why the early revenue numbers are worse on some devices than others. Part of the drop came from a large buyer being unable to serve at all for a stretch, and part comes from the identity block itself, where Digiday wrote that Apple has shown every sign of pressing on.

What the first numbers show

The clearest early data comes from Aditude, an ad revenue platform for publishers, published by Digiday on October 27. Across Aditude's customers, browsers built on WebKit, which covers Safari everywhere and every browser on iPhones and iPads in Digiday's description, account for 30% of ad impressions and 28.5% of ad revenue.

Only a small slice of that traffic is on the new software so far. Digiday reported that 3.8% of impressions and 3.3% of Prebid revenue had moved to the updated WebKit, while noting that adoption grew by half in a week and that new iPhones over the holidays will push it higher.

Where the update has landed, buyers are paying less. iOS bid rates fell 14% between September 15 and October 8 and have since recovered to about 8% down, while Mac bid rates are off about 25%. eCPMs are down 4% on iOS and 11% on Macs, and revenue per ad opportunity has fallen 6% on iOS and 20% on Macs.

The Mac figure is larger partly because, as Digiday reported, The Trade Desk's bidding "has yet to come fully back" there. Our reading is that the iOS figure is the better guide to the lasting cost of the identity block, while the Mac figure shows what happens when one large buyer drops out of your auction.

Why readers without an ID sell for less

Permutive, one of the blocked companies, published a wider comparison that Digiday also charted. Across more than 10 publishers and 569 million winning bids in August, inventory without an identifier traded at an average 42% discount to Chrome, with the gap wider on mobile.

The same analysis found that identifiers only cover about 30% of the bid stream, which means most readers on most sites were already selling without one. Permutive's argument is that a publisher's own data can reach those readers, and it reported that applying publisher data lifted CPMs by 76% on direct-sold deals and 32% on private marketplace deals across more than 80 publishers over 12 months.

Treat those Permutive figures as a vendor's case for its own approach, because Permutive sells publisher data tools. The direction still matches a separate trend from OpenX, which told Digiday that the share of US targeted ad spend on its platform going to third-party audience data fell from 78% in 2022 to around 40% by 2025, while targeting by the content around an ad rose to as much as 35%.

The reader who trusts you with an email address is still yours. What changed is who else gets to read it.

What Apple says is not affected

Apple's post draws a line that publishers should read closely. "First party personalization is not tracking, and is not what our technologies seek to prevent," it says, and it closes by promising to keep "the ability for websites to provide first-party personalization to their users."

The target is the third party sitting invisibly on your signup form, which Apple describes as companies that "are not themselves login providers or newsletter services, they're just there to track you." Your own newsletter signup, your own login and your own record of what a subscriber reads sit on the first-party side of that line, by Apple's own description.

Two limits are worth stating plainly. Apple published no list of blocked domains and no appeal route, so a vendor in your ad stack could be added later without notice. And Apple's post does not mention consent banners, so in our reading a reader clicking "I agree" on your site should not be treated as an exception to the block.

What a publisher can do this quarter

None of this needs a rebuild, but a few checks are worth doing before the holiday ad season, when Digiday expects more readers to be on updated iPhones. These steps are our recommendations, drawn from the data above.

1. Split your ad report by browser and device. Ask your ad manager or ad network for revenue per session or RPM on Safari against Chrome since mid September. A flat site total can hide a falling Apple line behind a rising Chrome one. 2. Ask your ad partner which identity vendors your stack calls. If it relies on Unified ID 2.0, ID5, LiveRamp or Permutive, those calls fail on updated Safari, so ask what the plan is for that traffic and whether contextual signals are being passed to buyers. 3. Make your pages easy to buy on context. Clear topics, accurate categories and focused pages give buyers something to bid on when they cannot see the person, which is the shift OpenX's numbers describe. 4. Grow the audience you can reach directly. An email list is first-party by Apple's definition and does not depend on an auction. Our guide to building an email list from your Facebook Page shows the route, and newsletter ad networks show how a list earns without chasing sponsors. 5. Check how much of your income runs through one auction. If display ads on your own site are most of your revenue, a browser change you never saw coming now sets part of your pay. Our look at platform dependency risk lays out how to measure that concentration.

The bigger pattern for publishers

WebKit's post frames identity resolution as the method the industry built in what it calls the "post cookie era," and it ends with a promise to "continue to prevent covert and cross-site tracking by default." Our reading is that revenue which depends on a third party identifying your reader can be repriced by a browser update, while revenue built on your own audience and several channels keeps working when one of them changes. Our map of content syndication routes is a good next read if you have not added those channels yet.

Where to go from here

If you want part of your income to come from channels outside your own site's ad auction, PIB's Content Syndication Turnkey Management builds and operates your syndication footprint across MSN, Yahoo, Apple News, NewsBreak, SmartNews and Flipboard on a revenue share. You add distribution that does not depend on Safari, Google or any single feed, and you keep owning the asset.

Frequently asked questions

What did Apple change in Safari in iOS 27?

In its iOS, iPadOS, macOS and visionOS 27 releases, Safari and WebKit block network access to what Apple calls identity resolution infrastructure. These are third parties that collect a reader's email address on a login or newsletter form and turn it into a tracking ID used across websites. Apple explained the change in a WebKit blog post on October 19, 2026.

Which companies are blocked?

Apple has not published a list. A WebKit bug report filed by The Trade Desk on September 21 reproduced nine entries, including domains for Unified ID 2.0, ID5, LiveRamp and Permutive. The Trade Desk's ad serving domain was also caught and was restored in an iOS 27.2 beta in early October, while the identity domains stayed blocked.

How much is this costing publishers?

Early Aditude data reported by Digiday on October 27 showed revenue per ad opportunity down 6% on updated iPhones and 20% on updated Macs, with eCPMs down 4% and 11%. Only a few percent of impressions were on the new software at that point, so the effect on a whole site is still small and is expected to grow as more readers update.

Does this block my own newsletter signup or email list?

Apple says first-party personalization "is not tracking, and is not what our technologies seek to prevent." The block targets third parties that sit invisibly on your forms and are "not themselves login providers or newsletter services." Your own list and your own login are on the first-party side of that line by Apple's description.

Does a reader's consent on my cookie banner change anything?

Apple's post does not mention consent banners or any opt-in route through a website. The block is applied at the domain level by the browser, so publishers should not plan around a consent click restoring those identity calls.

What should I do first?

Ask your ad manager or ad network for revenue on Safari against Chrome since mid September, and ask which identity vendors your ad stack calls. Then look at how much of your total income depends on that one auction, and whether email, syndication or direct deals can carry more of it.

Sources

• WebKit, Blocking Identity Resolution Infrastructure, October 19, 2026, webkit.org
• WebKit Bugzilla, Bug 324771, Inclusion of adsrvr.org in IS_REQUEST_UNCONDITIONALLY_BLOCKABLE domain list, filed September 21, 2026, bugs.webkit.org
• Digiday, In Graphic Detail: What Apple's identity block means for the ad money, October 27, 2026, with data from Aditude, Permutive and OpenX, digiday.com