That’s because there’s a limit on the number of filters per extension. uBO may eventually need to do the same.
https://adguard.com/kb/adguard-for-safari/solving-problems/r...
Sounds like I should direct a portion of my ire toward Apple on this.
It's really AdGuard's fault for failing to fit their functionality within the arbitrary constraints Apple decided was suitable for a runtime.
For one Safari compiles block lists to perform better, but it can be noticed at startup for big lists.
Then there is just resource constraints since the focus is mobile. Chrome on mobile notably supports no extensions.
But I do wish desktop Safari was more lenient.
> uBOL is entirely declarative, meaning there is no need for a permanent uBOL process for the filtering to occur, and CSS/JS injection-based content filtering is performed reliably by the browser itself rather than by the extension. This means that uBOL itself does not consume CPU memory resources while content blocking is ongoing -- uBOL's service worker process is required _only_ when you interact with the popup panel or the option pages.
EDIT: On a fresh install, AdGuard prompts to run in the background for extension updates. I also tend to separately toggle "launch AdGuard for Safari at Login" option.
Most of their software (including AdGuard for Safari and AdGuard Home) is open source, so there's little chance of anything nefarious happening.
(I still use AdGuard fwiw)
The generally awful and sad state of web browing on IOS was a big reason why I switched to Android.
Maybe not today, but there's no guarantee the company won't get sold tomorrow.
Not to mention that your AdGuard seems to be one of the 10 billion apps that competes for my subscriptions budget.