Safari 27’s WebKit updates have sparked a lot of noise across ad tech. There are warnings of platform monopolies, predictions of an escalated “Apple Tax,” and mounting alarm over the outright domain-level blocking of identity resolution infrastructure.
I understand the frustration. But beneath the rhetoric, Apple is speaking out of both sides of its mouth.
We have seen this playbook before. Under the banner of user privacy, Apple introduced App Tracking Transparency (ATT) in iOS 14.5, hampering third-party app measurement and data networks while its own Apple Ads business simultaneously accelerated. Now, with Safari 27 rolling out remote blocklists targeting hundreds of identity providers, DSPs, and measurement vendors, Apple is applying that exact App Store playbook to the web. By degrading independent monetisation and crippling the programmatic supply chain within Safari, Apple subtly clears the runway for its own expanding ad platform while keeping up the appearance of absolute privacy alignment.
Let’s be clear: tracking itself is not inherently sinister. HTTP cookies were an elegant, simple solution that funded decades of independent journalism, free utility, and open-web commerce. When Google attempted to engineer client-side replacements through the Privacy Sandbox, they spent years running into technical dead-ends and market resistance.
Furthermore, if cross-site tracking were the existential consumer crisis Apple claims, users would have voted with their feet long ago. Chrome remains the dominant global browser; users did not abandon it in droves to seek refuge in Safari or Firefox simply because third-party cookies were blocked. What signal is Apple actually responding to? At best, it’s misguided paternalism; at worst, it's a convenient cover to insulate and grow their own walled garden at the expense of the open web.
Yet as an engineer, this architectural shift was always inevitable. Apple is not going to change its mind, and relying on client-side workarounds was never a long-term strategy.
Since Apple first launched Intelligent Tracking Prevention (ITP 1.0) in 2017, it has engaged in a predictable cat-and-mouse escalation: capping cookie lifespans, shutting down CNAME cloaking, curtailing bounce tracking, and ultimately terminating third-party cookies in 2020. The industry responded by stacking alternative ID modules, browser fingerprinting scripts, and client-side listeners onto publisher pages. Safari 27 demonstrates the fatal flaw in that pattern: if your monetisation relies on client-side scripts executing inside someone else's walled browser, the gatekeeper can sever your connection with a single update.
Whoever controls the browser runtime sets the rules. But the open web is here to stay, and how we monetise it must mature.
Over 90% of our publisher network’s revenue comes from web browsers. So the browser remains central to what we do, backed by a practical, hybrid architecture. Our engineering and data teams started preparing for this long before Safari 27 landed. I’ve only recently joined Publift as CTO, and I can already see that groundwork paying off.
Here is how we are approaching it:
- Keep the client side clean. The browser should do what it does best: render content and display ads with minimal latency, without being bogged down by dozens of brittle third-party identity scripts that trigger browser-level blocks.
- Move signalling to the server. Identity resolution, contextual enrichment, and bid orchestration run in robust, server-to-server environments. When data flows through server-side pipes rather than arbitrary client-side calls, a client-side WebKit blocklist cannot break your pipeline.
Publishers that invest in resilient server-to-server infrastructure now will be in the strongest position, whatever WebKit decides to block next. That means less time firefighting platform updates, zero reliance on Apple's goodwill, and sustainable, long-term revenue growth on the open web.