This update comes with a story, since we found an unexpected iOS 17 bug that essentially limits the number of content-blocking rules, so you already know there’s no way we aren’t telling you all about it. Apart from the bug workaround, this release also contains some nice improvements and fixes beneficial to the app's performance and stability.

Apple, you said we could use up to 150k content-blocking rules in Safari, what happened?

The issue

So, it all started with us trying to find a solution to an issue on iOS 17 where filters would just update endlessly without actually updating. Yeah, you heard that right — tapping 🔄 icon in the upper right corner of the AdGuard's main screen was triggering an endless spinning animation but nothing happened. In some cases, however, this sight would come to an end in the form of filter update errors.

The cause

Initially, we were trying to find issues in our own app's code (as any responsible developer would). But the more we tried, the more we started to pay attention to the fact that the issue occurred only on the newest iOS, which is supposed to be the most polished and optimized. This detail and increasing user feedback lead us to realize that the root of the problem lies in the updated iOS.

The next realization was that filters would still update successfully depending on the filters enabled (or, rather, not enabled) by the user, which in turn helped us find out that loading rules into Safari sometimes hits a memory limit — something we never had a problem with before.

Apple provides developers with the ability to implement Safari Content Blocker functionality in their apps, which allows them to offer content-blocking features to users. As you can probably guess, this is an indispensable tool for ad-blocking apps on iOS, because it gives a way to apply filtering rules to pages accessed in Safari. Currently, according to the Safari Content Blocking API documentation, it allows for up to 150k rules in one content blocker (and one app can have several content blockers).

The contradiction

All in all, we were faced with a surprising new reality where using our standard Safari content blockers with 150k filtering rules was all of sudden causing a crash on iOS 17. It turned out that Safari wouldn't accept files over a certain size anymore — even content blockers with 40-60k rules (which is 3 times below the 150k limit) would sometimes crash, depending on the rules they contain.

This leads to a simple question to Apple: how come a 40k rule content blocker crashes when Safari officially allows 150k rules?

Since it’s an obvious bug in iOS 17, we already reported it on Apple’s forum. We’d appreciate it if you could upvote it there by pressing 'Me too'. Also, here’s the ticket ID in Apple’s Feedback Assistant: FB13282146.

The workaround

It took us over a week to figure out a temporary measure: we restricted the size of our JSON files and optimized main filters so that they can squeeze into this new ‘size requirement’. If a content blocker is still a little too big for iOS’s liking (the final size depends on how many and what filters are enabled by the user), we automatically cut its size so that at least part of the rules that meet the size requirement gets applied in Safari.

So while everything should work fine for most users at the moment, we are very much looking forward to Apple fixing this bug ASAP.

SafariConverterLib, Scriptlets and TSUrlFilter updated

Thanks for letting us blow off some steam above, now we can tell you about nicer things in v4.5.1. For instance, we updated SafariConverterLib, Scriptlets, and TSUrlFilter dependencies. The update of these three components and their interconnection helps maintain high filtering quality, i.e. efficient and up-to-date performance of blocking rules.

SafariConverterLib converts AdGuard filtering rules into Safari content blocking rules, so it basically makes possible to use the full power of our filters in AdGuard for iOS. Scriptlets and TSUrlFilter are also nothing short of important, since they help implement the Advanced blocking feature in AdGuard for iOS.

DnsLibs reworked

In DnsLibs (our DNS filtering engine) v2.3 update we have done some serious rework and adjustments which significantly improved AdGuard's DNS-over-HTTP/3 performance and stability.

Also, some other things were fixed, one of them being the issue where AdGuard wouldn’t open on iOS 13.x.

We hope you'll enjoy improved AdGuard for iOS, and if you have any thoughts about this update, please don't hesitate to leave a comment below or reach out to us on social media.
The full v4.5.1 changelog can be found on Github.
Any feedback is also very welcome in Github issues.