Cette mise à jour est accompagnée d'une histoire, puisque nous avons trouvé un bug inattendu dans iOS 17 qui limite essentiellement le nombre de règles de blocage de contenu, donc vous savez déjà qu'il est impossible que nous ne vous en parlions pas. Outre la résolution du bug, cette version contient également quelques améliorations et corrections utiles pour les performances et la stabilité de l'application.

Apple, vous aviez dit que nous pouvions utiliser jusqu'à 150 000 règles de blocage de contenu dans Safari, que s'est-il passé ??

Le problème

Tout a commencé par une tentative de résolution d'un problème sur iOS 17 où les filtres se mettaient à jour sans arrêt sans être réellement mis à jour. Oui, vous avez bien entendu, le fait d'appuyer sur l'icône 🔄 dans le coin supérieur droit de l'écran principal d'AdGuard déclenchait une animation de rotation sans fin, mais rien ne se passait. Dans certains cas, cependant, ce spectacle prenait fin sous la forme d'erreurs de mise à jour du filtre.

La cause

Au départ, nous avons essayé de trouver des problèmes dans le code de notre propre application (comme le ferait tout développeur responsable). Mais plus nous essayions, plus nous faisions attention au fait que le problème ne se produisait que sur l'iOS le plus récent, qui est censé être le plus perfectionné et le plus optimisé. Ce détail et les commentaires de plus en plus nombreux des utilisateurs nous ont amenés à réaliser que la racine du problème se trouvait dans la mise à jour d'iOS.

Nous avons ensuite constaté que les filtres se mettaient toujours à jour avec succès en fonction des filtres activés (ou plutôt non activés) par l'utilisateur, ce qui nous a permis de découvrir que le chargement des règles dans Safari atteignait parfois une limite de mémoire - ce qui ne nous avait jamais posé de problème auparavant.

Apple offre aux développeurs la possibilité d'implémenter la fonctionnalité Safari Content Blocker dans leurs applications, ce qui leur permet d'offrir des fonctions de blocage de contenu aux utilisateurs. Comme vous pouvez le deviner, il s'agit d'un outil indispensable pour les applications de blocage des publicités sur iOS, car il permet d'appliquer des règles de filtrage aux pages consultées dans Safari. Actuellement, selon la documentation de l'API de blocage de contenu de Safari, un bloqueur de contenu peut contenir jusqu'à 150 000 règles (et une application peut avoir plusieurs bloqueurs de contenu).

La contradiction

En fin de compte, nous avons été confrontés à une nouvelle réalité surprenante : l'utilisation de nos bloqueurs de contenu Safari standard avec 150k règles de filtrage provoquait soudainement un plantage sur iOS 17. Il s'est avéré que Safari n'acceptait plus les fichiers dépassant une certaine taille - même les bloqueurs de contenu avec 40-60k règles (ce qui est 3 fois inférieur à la limite de 150k) plantaient parfois, en fonction des règles qu'ils contenaient.

**Cela nous amène à poser une question simple à Apple : comment se fait-il qu'un bloqueur de contenu de 40k règles se plante alors que Safari autorise officiellement 150k règles ?

Comme il s'agit d'un bogue évident dans iOS 17, nous l'avons déjà signalé sur le forum d'Apple. Nous vous serions reconnaissants de bien vouloir l'augmenter en cliquant sur "Me too". Voici également l'identifiant du ticket dans l'assistant de commentaires d'Apple : FB13282146.

La solution de contournement

Il nous a fallu plus d'une semaine pour trouver une mesure temporaire : nous avons limité la taille de nos fichiers JSON et optimisé les principaux filtres de manière à ce qu'ils puissent s'adapter à cette nouvelle "exigence de taille". Si un bloqueur de contenu est encore un peu trop gros au goût d'iOS (la taille finale dépend du nombre et de la nature des filtres activés par l'utilisateur), nous réduisons automatiquement sa taille afin qu'au moins une partie des règles qui répondent à l'exigence de taille soit appliquée dans Safari.

Ainsi, même si tout devrait fonctionner correctement pour la plupart des utilisateurs pour le moment, nous attendons avec impatience qu'Apple corrige ce bogue le plus rapidement possible.

Mise à jour de SafariConverterLib, Scriptlets et TSUrlFilter

Merci de nous avoir permis de nous exprimer un peu plus haut, maintenant nous pouvons vous parler de choses plus agréables dans la v4.5.1. Par exemple, nous avons mis à jour les dépendances SafariConverterLib, Scriptlets et TSUrlFilter. La mise à jour de ces trois composants et de leur interconnexion permet de maintenir une qualité de filtrage élevée, c'est-à-dire une performance efficace et à jour des règles de blocage.

SafariConverterLib convertit les règles de filtrage AdGuard en règles de blocage de contenu Safari, ce qui permet d'utiliser toute la puissance de nos filtres dans AdGuard pour iOS. Les Scriptlets et TSUrlFilter sont également très importants, car ils permettent d'implémenter la fonction de blocage avancé dans AdGuard pour iOS.

DnsLibs retravaillé

Dans la mise à jour DnsLibs (notre moteur de filtrage DNS) v2.3 nous avons fait de sérieux travaux et ajustements qui ont amélioré de manière significative les performances et la stabilité du DNS-over-HTTP/3 d'AdGuard.

D'autres choses ont également été corrigées, l'une d'entre elles étant le problème où AdGuard ne s'ouvrait pas sur iOS 13.x.

Nous espérons que vous apprécierez l'amélioration d'AdGuard pour iOS, et si vous avez des commentaires sur cette mise à jour, n'hésitez pas à laisser un commentaire ci-dessous ou à nous contacter sur les médias sociaux.
Le journal des modifications complet de la v4.5.1 est disponible sur Github.
Tout commentaire est également le bienvenu dans Github issues.