For most iPhone and iPad users, ad blocking falls into 5 main approaches. iOS and iPadOS use the Safari WebKit engine (more on this below) for browsers, and you are limited to what kind of ad blocking you can perform.
- Content blocker extension (browser only): In Safari, you can perform ad blocking by providing a content blocker extension. This is a 3rd party application that requires the full App Store lifecycle (developer program membership, submission, review, distribution, etc.) The extension supplies rules describing resources to block or elements to hide. Other browsers using the Safari engine on iOS and iPadOS cannot use the 3rd party content blocker extension because that extension is only for the Safari brower, not other browsers based on WebKit engine. Note that alternate browser engines are only available in the EU (iPhone and iPad) and Japan (iPhone only). Safari applies content-blocker rules without giving the blocker access to browsing activity
- 3rd party browsers with built in ad blocking (browser only): WebKit has a WKContentRuleList API that allows the developer to provide blocking rules for WebKit to enforce. The browser processes browsing data locally, so users must trust their browser’s implementation and privacy practices
- VPN (system wide): 3rd party VPN applications from the App Store can block destinations based on DNS answers, IP addresses, or other visible host information. It does not need a remote VPN service; this filtering can take place on-device. Users must be careful not to install VPN services that perform additional HTTPS inspection or interception. Users must inherently trust the implementation
- DNS filtering (system wide): Manual DNS configuration can block domain names for ad hosting domains. Slightly more work is needed by the end user to configure DNS settings for cellular connections but it’s not difficult. The DNS resolver sees all DNS queries, not just the ones that contain ads, so users must trust the implementation
- URL Filtering (NEURLFilter): Apple technology introduced in WWDC 2025 to perform URL filtering by a 3rd party app developer using PIR (private information retrieval), OHTTP (Obvlious HTTP) and on-device Bloom filters. This technology allows a 3rd party application to provide block lists to the system in a way that allows the OS to perform network filtering without ever reporting back (more on this below) to Apple or 3rd party application on what URLs were filtered. This works automatically for nearly all apps (using WebKit and URLSession) across the system except for apps that use their own networking implmentations like those built with sockets. Apps with custom networking can voluntarily participate in URL filtering. Apple allows blocked-URL reporting on supervised (MDM/corporate devices) and that data can go back to the PIR endpoint. Supervision restricts where reporting is available; it doesn’t establish who owns that endpoint, the data could go back to the filtering provider which could be different than the MDM/supervision provider. Note that URL filtering blocks network requests, it cannot remove leftover ad spaces or other page elements.
In full disclosure, I wrote this little post as the developer of SuperBlocker: Ad Blocker (App Store link) to shamelessly plug my own application as using the network filter technology discussed in bullet point #5 above. I’ve been working on this for some time now, since the technology behind it (PIR, OHTTP relays, gateway and the app) is not easy to setup. It also requires in depth scrutiny from Apple before they validate and onboard the backend. That is separate from the development and approval of the iOS and iPadOS app. Network filtering is also available on macOS and I have a build ready for the Mac. But as of this writing (October 24, 2026), there is a bug in macOS 27 that prevents the activation of URL filters because of a macOS group/userid mismatch.
It’s a one time universal purchase. macOS/iOS/iPadOS, so when Apple fixes the bug in macOS 27, I’ll release the macOS build and you can just download it if you have already purchased it on iOS/iPadOS. No subscriptions, no in app purchases. No notifications or account sign ups. Just how it should be. Let me know what you think: satish@satishmaha.com
Thanks for reading