Hacker News Reader

Comment by danaris | Hacker News Reader

Apple will let whatever browsers want to run on iOS. Chrome is, in fact, on there.

They just won't let them using any rendering engine but WebKit—and this restriction long predates Google's current level of draconian dominance in that sphere.

I don't believe the tracking settings are tied to the rendering engine, so I would be surprised if Chrome on iOS has settings that different to Chrome on macOS in that regard.

View on HN

So they allow WebKit reskins, that's not the same thing as allowing competing browsers.

And it's not as dire as just a reskin of Safari. You have to use Webkit but everything before and after it are up to you.

The rendering engine also includes the entire network infrastructure. I can't think of how I would plug my own network infrastructure into WKWebView on iOS, which means I can't block any built-in tracking prevention.

I think you’re confusing WKWebView with SFSafariViewController. Content blockers are not used for WKWebView. You can use your own content blocking logic via the appropriate delegate calls, but the “system-wide” content blockers are not inherited from Safari.

Intelligent Tracking Prevention and content blockers aren't the same thing though. I don't know if ITP runs for WKWebView but I really hope so.

Chrome on iOS uses its own networking stack.

What's your source for this claim?

Right, there'd be no way Chrome on iOS could do the same things Chrome on macOS does when it comes to cookies, etc.

Reply on news.ycombinator.com