hsb.horse
Lorsque vous venez de commencer le développement iOS et que vous souhaitez créer une application qui bloque des sites, votre première pensée peut être le DNS. Il semble plus fiable et plus simple d’arrêter le processus au stade de la résolution du nom que de surveiller le processus.
Lorsque vous effectuez une recherche, vous trouverez une classe appelée NEDNSProxyProvider. Le nom reste le même et le but semble être le même.
Mais n’utilisez pas ça. Il est facile de perdre du temps ici, surtout si vous n’avez aucune expérience avec iOS.
À quoi sert le cours ?
NEDNSProxyProvider fait partie du framework Network Extension et est une classe permettant de configurer un proxy DNS sur un appareil. Techniquement, c’est comme ça que ça marche.
Le problème réside dans l’environnement cible. Si vous lisez le TN3134 (Network Extension Provider Deployment) d’Apple, vous verrez que ce cours est destiné aux appareils supervisés contrôlés par MDM, c’est-à-dire aux terminaux gérés par les entreprises et les écoles.
Non destiné aux applications distribuées à des utilisateurs individuels sur l’App Store. Si vous avez de l’expérience avec le développement iOS, vous comprendrez le contexte de « pour les appareils gérés par MDM », mais cette partie est difficile à lire au début.
Messages cohérents dans les forums de développeurs
Lorsque vous posez des questions sur la mise en œuvre d’applications de contrôle personnel sur les forums de développeurs Apple, les réponses sont assez cohérentes. Vous serez dirigé vers Family Controls + ManagedSettings.
Même lorsque j’explique moi-même mon besoin de filtrer le DNS, j’obtiens une réponse disant : « Ce n’est pas le cas d’utilisation prévu ». Essayer de mettre en œuvre un blocage de sites nuisibles pour des utilisateurs individuels utilisant des extensions réseau est en soi contraire à la philosophie de conception d’Apple.
De nombreuses personnes découvrent pour la première fois après avoir lu des forums que « iOS possède sa propre API ».
Que va-t-il réellement se passer ?
Puisqu’il s’agit d’une fonction destinée aux appareils supervisés, il n’est pas clair si elle passera l’examen en tant qu’application App Store classique. Le développement se poursuivra avec le risque de rejet de l’App Review.
De plus, si vous choisissez cette voie, vous ne pourrez pas utiliser FamilyActivityPicker ou ManagedSettings. Vous finissez par écrire vous-même toute la logique de bloc et ne bénéficiez d’aucun des mécanismes maintenus par Apple au niveau de la plate-forme.
Changement de conclusion
Pour les applications iOS d’autocontrôle destinées aux utilisateurs individuels, la combinaison de Family Controls + ManagedSettings est la réponse. Si vous n’avez aucune expérience en développement iOS, vous continuerez sans savoir qu’il existe une API formelle.
Je comprends que vous souhaitiez bricoler le système DNS. Mais le respect des politiques de plate-forme d’Apple réduit les frictions liées à l’évaluation des applications et les coûts de maintenance à long terme. Vous devez d’abord lire la documentation de l’API Screen Time avant de passer du temps sur NEDNSProxyProvider.