I object to removing AdGuard. The reason is that it doesn’t work with PWA apps.
I have tested uBlock on iOS 17.6, and this point is still true.
5 Likes
How does uBlock Origin Lite work on Safari if not via the native content blocking framework?
iOS is annoying because the Safari settings used to explicitly list which extensions were content blockers, which would make this easier to check, but now that is gone.
Gorhill is aware of the issue
https://github.com/uBlockOrigin/uBOL-home/issues/358#issuecomment-3159712627
Hopefully there’ll be a solution soon
uBOL reads and alters webpages’s content directly, not through Safari.
Meanwhile, Adguard uses a hybrid approach. It provides basic rules for Safari’s content blocker in addition to reads and alters content directly. This is because the rules that Safari’s content blocker supports are very basic.
Content blockers are app extensions that you build using Xcode. They indicate to Safari a set of rules to use to block content in the browser window. Blocking behaviors include hiding elements, blocking loads, and stripping cookies from Safari requests.
With extensions like Adguard, this distinction is gone.
They can wait for web apps on iOS/iPadOS to support extensions. 
Web apps on macOS only support extension from last year, so it may take several years.
1 Like
Another objection regarding permissions:
- AdGuard: “AdGuard does not have permission to read or transmit content from any webpages”.
- uBOL: “Webpage Content and Browsing History: Can read and alter sensitive information on webpages, including passwords, phone numbers, and credit cards, and see your browsing history on the current tab’s webpage when you use the extension.”
They then closed that issue.
I know AdGuard uses a hybrid approach, but I thought it was the other way around with uBOL, where they only use Safari’s system and don’t modify websites. Don’t all MV3 extensions have to use declarative statements?
This should be optional, like it is on desktop. Can someone test setting this permission to Deny and seeing if it still works?
It is not optional, I just tested on iOS 18.6.
I think this stems from it again not being a true Apple “content blocker”.
1 Like
It still works, and this is the default iirc. You need to grant it permission for Optimal or Complete filtering though
2 Likes
Additionally, from my testing, if you don’t grant it that permission and try to change to Optimal or Complete, as soon as you close and reopen the settings tab for uBlock, it should be back at Basic. It apparently lacks the ability to ask for permission, at least on iOS. You have to grant it in the Safari settings manually to use any of these modes.
1 Like
I don’t think Adguard should be removed, it also provides content blocking on other apps and ublock doesn’t, that’s useful if you use any banking apps and therefore can’t use a VPN, iOS doesn’t support split tunneling on vpns.
3 Likes
Why do you believe these are incompatible?
1 Like
Installed uBOL on all my Apple devices yesterday. Very happy so far. I’ve noticed adjusting the settings between basic, optimal, and complete sometimes doesn’t stick even with full permissions to access every website. Not really sure of the difference between optimal and complete though.
No one should be surprised that an extension that modifies the webpage you are viewing can see and alter sensitive information on the webpage. Safari is simply warning you of what is going on. Other Safari extensions that do this include Wiper and StopTheMadness.
AdGuard only provides content blocking in other apps if you let it be your DNS too. That’s a function that NextDNS, ControlD or other serivces already may do for you. And uBOL appears to be much lighter than Ad Guard (at least on macOS) which has to have the full app running all the time.
1 Like
Can confirm, uBOL is so much lighter than running the Adguard extension in Safari on my iPhone and Mac. That alone makes it an easy choice for me.
1 Like
I think we should wait a bit longer before recommending uBOL for Safari.
For other services, we usually wait months or even years before making a recommendation. Now, we’re considering adding uBOL after just a few days, even though we’re still unsure about potential downsides or development issues that could arise.
Yes, the developer is reputable and trusted, but it’s still new on Safari. A little patience won’t hurt.
6 Likes
I figured any half-decent Safari content blocker would be using this hybrid — content blocker API + web extensions API — approach.
I currently use Wipr 2 which does that. If I go to Settings > Apps > Safari > Extensions I see a multiple entries/toggles related to Wipr and only one of them, the Wipr Extra entry, has that warning about being able to view and modify webpage contents. I assume that Wipr Extra entry is leveraging the web extensions API to provide more advanced blocking.
I’m no developer, but always assumed the content blocker API simply provided “hosts file” capabilities, while the web extensions API handled javascript related stuff (cosmetic filtering).
Does uBO Lite only rely on the web extensions API for all its blocking?
Yes, and it will remain like that in the near future.
uBOL will stay a webextensions-based browser extension, I do not plan to go further than this, I do not have the time and motivation to take on more work than I already do.
That’s problematic imo. It means it won’t work in web apps or in-app Safari websites unless apple makes them support extensions
Are you currently using a DNS solution like NextDNS or AdGuard Pro with it’s DNS? I’m not aware of any other way to impact what happens in apps. (I personally use NextDNS) Am I missing something?
