How Data And Ad Tech Vendors Are Preparing For The iOS 27 Fallout
Thursday, October 8th, 2026 – 2:50 pm
Against the backdrop of Advertising Week New York this week, the programmatic ecosystem has been buzzing madly like the inhabitants of an overturned beehive.
That’s because Apple’s latest operating system update, iOS 27, which launched in mid-September, has been, without warning, unconditionally blocking data and identity vendors. The original list included LiveRamp, Permutive, Audigent (now owned by Experian) and the Unified ID 2.0 program, as well as The Trade Desk’s adsrvr.org, its root domain for serving ads.
Earlier this week, Apple released a new WebKit beta – iOS 27.2 – that removes The Trade Desk’s adsrvr.org from the blocklist, which is good news for TTD.
But this doesn’t mean the overarching problem is solved.
As AdExchanger reported after conversations with sources who have knowledge of the WebKit group’s plans, Apple is devising a far more expansive potential blocklist list that would include hundreds of ad tech, mar tech and identity vendors that handle user data and device IDs.
AdExchanger has now spoken with most of the known principals involved in the story (as in the companies blocked by iOS 27) as well as others working closely with the Apple WebKit group, although no Apple exec or insider has responded to requests for comment.
The TTD fix
The first and most visible casualty of Apple’s iOS 27 surprise was The Trade Desk.
But after weeks of uncertainty, WebKit’s ad tech leader John Wilander informed The Trade Desk engineering’s leader Ian Meyers of the iOS 27.2 beta, which removes adsrvr.org from the blocklist.
Although this is good news for TTD, it must wait for iOS 27.2 to become the live install version of iOS, which might not happen for three or four weeks. If you download the new iOS 27 today, it will still block TTD’s ads from serving.
Luckily, the install rate for iOS 27 is still relatively low and the timeline short enough that this will only be a revenue blip for a company of TTD’s size. But the bigger relief is that there’s no need to undergo a costly migration to a new ad-serving domain.
In retrospect, the block seemed aimed at match.adsrvr.org, TTD’s cookie-sync endpoint. But Safari blocks at the domain level, so it took out the core ad-serving domain, too. When TTD was founded, keeping everything under one domain meant better match rates and faster ad serving, and no one was worried about browsers blocking by domain. Now, with the rise of privacy-by-default standards and crackdowns on cross-device tracking, TTD probably wishes it had put matching on a separate domain entirely.
What about the rest of us?
Still, for The Trade Desk at least, this probably feels like a major potential crisis averted. Adsrvr.org lives to serve another day.
But the core issue has not been resolved. As several measurement vendors pointed out unprompted during Advertising Week gatherings, the initial focus on The Trade Desk has obscured how big of a deal – and bad – this iOS update is for analytics and attribution.
Marketers rely on LiveRamp, UID2 and other still-blocked identity providers and identifiers for cross-channel matching. They need identity to stitch streaming media placements with mobile ads and web traffic, for example, or to connect TV spots with spikes in organic search.
Well, sayonara to that.
In addition, data and identity vendors commonly insert alternative IDs in the bidstream for Safari ads because third-party cookies and other identifiers have been removed. Many DSPs only bid for targetable placements, so vendors need to add an ID of some kind. Goodbye to that tactic as well.
And then there’s the relatively minor but extremely thorny issue of advertisers that paid for iOS 27 ads that didn’t render.
As two agency ad buyers told AdExchanger on background, the win logs for their customers that use TTD contain ads for iOS 27 that clearly did not serve. In other words, those brands won auctions and paid for ads no one saw. Other impressions were targeted using LiveRamp’s RampID, which derives from the blocked pippio.com domain.
Fortunately, iOS 27’s user base is still small, and ad buying systems can route spend elsewhere, so the losses are limited. But some money did go to ads that never rendered, which raises the question: Do advertisers get paid back?
Whether an advertiser can contractually recoup its spend is based on the cascade of relationships between publishers, SSPs, DSPs and advertisers, according to two execs at companies directly involved. So enjoy that reconciliation process.
Apple’s POV
Meanwhile, Apple has been characteristically unresponsive.
Sure, The Trade Desk’s Meyers and Apple’s Wilander had a back-and-forth on WebKit Bugzilla, which also alludes to a separate email exchange. But those interactions appear to be the extent of Apple’s communications on the iOS 27 blocklist matter.
Not that Apple is ever chatty about policy changes. But this time it’s even less forthcoming than usual.
According to multiple leaders at blocked companies who spoke with AdExchanger on the condition of anonymity, this iOS 27 update stands in stark contrast to Apple’s Intelligent Tracking Prevention, the first version released with iOS 11 in 2017. It’s also a different beast than when Apple’s AppTrackingTransparency policy went live with iOS 14 in 2021.
In both cases, AdExchanger’s sources said, Apple released guidance and public statements, and held sessions about the changes during its developer conference. This time, the blocked companies were left to figure it out themselves, usually after a publisher client or partner asked why ads had stopped rendering. One engineering leader compared it to a heart attack: “Very subtle, easy-to-ignore signals, then all of a sudden. Boom.”
Then again, one publisher ad tech exec argued that secrecy is the point. The WebKit team can’t trust ad tech, the exec said, so it purposely keeps the blocklist’s rules and workings hidden. Permutive, for instance, the publisher noted, simply rotated to a new domain shortly after discovering “permutive.com” had been blocked.
A Permutive exec told AdExchanger this tactic is a temporary patch as the company migrates a small number of clients to server-side or first-party services. (More on this below.) It’s meant as a makeshift bridge and not a durable solution.
Still, from Apple’s perspective, hard-and-fast rules would be a gift to ad tech, data and identity vendors, which are adept at following the letter of the law while flouting its intent.
After all, the industry has been wondering for years when Apple would start enforcing its stated fingerprinting ban. For example, back in 2022, AdExchanger’s Allison Schiff penned a column entitled “It’s Time For Apple To Stop Pointing Fingers At – And Start Enforcing Against – Fingerprinting.”
Well, here it is. Apple now has a system capable of enforcing against fingerprinting and other forms of persistent identity tracking at the domain level.
Blocking a domain like adsrvr.org or pippio.com is no small thing, which is why many of these old cookie domains still bear legacy names. Pippio, for instance, was the original name of Arbor, an identity startup acquired by LiveRamp almost exactly a decade ago. Back then, Arbor unabashedly described itself as a “marketplace for people-based data.”
The big platforms do the same. Google’s ad serving domain is still ad.doubleclick.net despite the DoubleClick name having been long retired. Microsoft Advertising uses the “adnxs.com” domain, an ember still left burning from the old AppNexus days. These domains hold identity graphs that took years to build, and they can’t simply be picked up and moved. Start over on a new domain, and you’re back at zero.
The fallout
So, what happens now that Apple has shown it can wipe out years of work with a single inclusion in a blocklist? There’s really not much any ad tech company or web publisher can do.
The next steps, according to interviews with companies targeted by Apple or that feel their business model may be in WebKit’s crosshairs, is to urgently transition web publisher and DTC ecommerce customers from third-party subscription software to a first-party native implementation.
But this is a big change and not an easy lift. For an ID operator, it means developing a first-party identity framework within that publisher’s or brand’s own stack, rather than being a standalone network that stitches IDs together across the web. It requires different types of data integrations, following much stricter rules and probably seeing less data, since in a first-party structure vendors can only access what clients have given them permission to see.
Which is why you’re going to start hearing a lot more about the shift to “trusted server” implementations. The IAB Tech Lab has been developing an open-source Trusted Server product for the past year and a half.
The idea behind Trusted Server is to move the programmatic ad spec from the browser to a server that’s operated by the publisher or publisher’s tech vendor. Today, that happens in the browser, which is why WebKit can suddenly shut off The Trade Desk or any ID vendor’s access to data from the bidstream or ad auction. With Trusted Server, those calls happen on a publisher-controlled server, so WebKit never sees the bids and has nothing to block.
This is akin to the server-side migration we’ve seen in the mobile app world, where major platforms are fed an advertiser’s first-party data directly via conversion APIs, known as CAPIs.
But Meta, TikTok, Snapchat and YouTube, which all have their own CAPIs or CAPI-like tools, are far more scaled and better positioned to make that transition. And the IAB Tech Lab must corral thousands of publishers of various sizes to adopt the new web advertising standard, whereas the major platforms represent the entire media side of their marketplace and can simply go, go, go.
The Tech Lab is actively looking for publishers to adopt and test the Trusted Server setup. By early next year, there should be “production-level tests” of campaigns shifted to first-party publisher servers, Lam said.
But that’s not much runway. Although the iOS 27 install base is still small enough that the revenue hit is immaterial, the number of installations ticks up daily as more people update their Mac and/or iPhone. And, eventually, Apple will just do what it always does and push an update to the laggards. At that point, LiveRamp, Permutive, ID5, UID2, Audigent and possibly hundreds of other companies will need a fix in place, although it appears that WebKit started by targeting vendors with the largest cookie-sync footprints.
The iOS 27 setback is one more blow for an industry that has spent years beholden to building around the plans and promises of browser operators. Remember the Chrome Privacy Sandbox? Some companies spent millions of dollars – and hundreds of engineering hours – building, testing and collaborating in good faith, only for Google to renege.
Apple’s SKAdNetwork for mobile ad attribution was much the same. Some companies again spent millions redesigning their systems at Apple’s insistence only to see Apple quietly allow SKAdNetwork to die on the vine. Apple has never explained whether SKAdNetwork has been officially sunset or what the heck is going on there.
Sound familiar? Then again, don’t expect Apple to lose sleep. “Apple isn’t thinking about The Trade Desk or any of these particular vendors,” said a leader at one data company that’s also blocked in the new iOS 27. But is it really any solace to a colony of ants, he added, that the elephant isn’t thinking about them when it squashes their civilization?