> With iOS you’re SOL. No extensions

I’m reading this using iCab Mobile on iOS, which is a browser apparently no-one on HN has ever heard of, as I need to mention it every time this tired old and inaccurate assertion is trotted-out again.

This browser allows you to define your own blocking lists, including filters for every conceivable combination of JS, CSS, cross-site, cookie-based and URL tracking.

So which part do you want to ban exactly?

[0] https://apps.apple.com/us/app/icab-mobile-web-browser/id3081...

AdGuard on iOS works in Safari and all in-app browsers that use Safari View Controllers (unfortunately a lot of malicious apps such as social networks don't use it for this exact reason).

It's not a perfect replacement for UBO as the underlying filtering API isn't as powerful but it does a good enough job most of the time. It still uses the same filter lists as UBO (though again it's not able to make all rules work, due to API limitations).

I'm not familiar enough with iOS, does Apple still allow apps to use a different web view that the filters do not apply to? If so is there any reason they shouldn't require Safari View Controllers for App Store submission?

> does Apple still allow apps to use a different web view that the filters do not apply to

The web views the filters don't apply to have different use-cases such as customizing/hiding the browser UI elements, injecting Javascript, etc. There are legitimate reasons to use it in some cases (in case you need to display server-side-rendered content as if it was native).

Of course, Apple could decide on a case-by-case basis and reject usages of the legacy web view when the new implementation is appropriate, but they won't just like they don't do anything for apps that lie on the "privacy nutrition labels" about the data they collect or various other breaches of the App Store guidelines.