Skip to content

Wize AdBlock VPN Product History

macOS Private DNS and iOS Targets: Expanding Wize AdBlock Beyond Android

An Android private DNS ad blocker grows up: how Wize AdBlock VPN added macOS private DNS detection and iOS run targets, with Android still the primary platform.

macOS Private DNS and iOS Targets: Expanding Wize AdBlock Beyond Android preview

Written by the Fulldive product engineering team, based on direct inspection of the repositories listed below.

Wize AdBlock VPN started life as an Android private DNS ad blocker. Its home is still Android, where the VpnService-based local DNS sinkhole is the cleanest way to filter traffic across apps without root. But the repository (fulldiveVR/FulldiveExtension.AdShield) also shows a deliberate, narrow expansion to Apple platforms, and the shape of that expansion tells you a lot about what a DNS-filtering app can and cannot do on iOS and macOS.

This post walks through three commits from late 2025 that map the cross-platform work, and explains why the macOS and iOS footprints look smaller than the Android one.

On Android, the model is clear

On Android, the technique is well-trodden: request VpnService consent, stand up a local tun interface, serve as the DNS resolver for the device, and apply blocklists. This is documented on the Android Developers VpnService page and is the same mechanism used by the Android private DNS ad blocker category generally. Wize AdBlock VPN’s primary platform is Android because the API surface fits the product exactly.

On macOS, private DNS is an OS-level concept

Apple does not hand third-party apps the same kind of in-process DNS interception that VpnService gives Android. Instead, macOS users configure Private DNS (DNS-over-HTTPS or DNS-over-TLS per RFC 8484) at the system level. A filtering app has two realistic options: run as a system network extension (significant entitlement burden), or detect when the OS already has a private DNS configured and adjust its own behavior accordingly.

commit d9a99dec `` adds macOS private DNS detection to the AdShield codebase. The point is not to provide DNS filtering on macOS the way we do on Android. The point is for the shared application layer to know when macOS is already routing DNS through an encrypted resolver, so the app’s UI and status reflect reality instead of claiming to filter traffic it cannot see.

This is a small, honest feature. It avoids the failure mode of an app that shows a “protected” state on a platform where it is not the one doing the protecting.

iOS gets development run targets

commit 98671f41 `` introduces iOS development run targets in the project configuration. These are Xcode build targets intended for internal work: they let the team run, test, and iterate parts of the codebase on iOS without shipping an App Store build. The commit’s significance is not a full iOS release; it is that the shared code is now exercised on iOS in active development, with all the compiler warnings and API differences that surfaces.

We call this out explicitly because it is the honest framing. A development run target is a toe in the water, not a shipped product. If and when a full iOS Wize AdBlock VPN release happens, it will be written up separately.

HTTP timeouts, synchronized across platforms

The third commit worth noting is commit 76175b69 ``, which synchronizes HTTP timeouts across the platforms the codebase builds for. Timeout values sound like a trivial config line, but when a codebase targets Android, macOS, and iOS-development surfaces, timeout inconsistencies produce bug reports that are hard to triage. A request that fails quickly on Android and slowly on macOS will make users and engineers disagree about whether a network problem is a network problem or a product problem.

Aligning timeouts is the kind of maintenance that keeps cross-platform code honest. It rarely appears in a release note, and it matters.

Why the Android footprint is still the biggest

Comparing what these three commits do:

Platform2025 commitFunctional role
AndroidEvery release linePrimary product: VpnService DNS sinkhole
macOSd9a99decDetect system-level private DNS, do not duplicate it
iOS98671f41Development run targets, internal iteration only
Cross-platform76175b69Consistent HTTP timeouts

The honest picture is: Wize AdBlock VPN is an Android app whose codebase is partially multi-platform. On macOS, the most useful thing the app can do is stay out of the way of Apple’s own Private DNS configuration. On iOS, the app is in development, and we are not going to pretend otherwise.

Where DoH and Private DNS fit

For context on the macOS detection work: Private DNS on macOS and iOS is largely built on DNS-over-HTTPS, which is defined in RFC 8484. When a user configures a Private DNS profile, system-wide DNS queries are routed through the encrypted resolver the profile specifies, independent of any app. A third-party filter that tries to compete with this ends up either fighting the OS or lying to the user. Detecting it, and telling the user honestly, is the correct behavior.

Apple’s own relay tooling (iCloud Private Relay, documented in their Private Relay overview) reinforces this. On Apple platforms, network-level privacy features are increasingly the OS’s job. A DNS-filtering app fits alongside those features, not on top of them.

Limits: what cross-platform expansion does not deliver

  • It does not make Wize AdBlock VPN a full-featured macOS product. Detecting private DNS is not the same as filtering it.
  • It does not make Wize AdBlock VPN an iOS product. Development run targets are not App Store releases.
  • It does not extend blocking coverage to apps that bypass system DNS. On any platform, an app using its own DoH endpoint can skip local DNS resolution.
  • It does not claim anonymity or tracker elimination. Those are different products.

For the full list of what this app does not promise, see What Wize AdBlock VPN can and cannot block.

Where to go next

Sources

Last updated: 2026-04-16. Commit hashes and version numbers are drawn from Fulldive repositories inspected on 2026-04-13.