hsb.horse
Quand on veut créer une application d’autocontrôle pour bloquer des sites alors qu’on débute sur iOS, on découvre vite une série de moments où l’on se dit : “ce n’est pas du tout ce que j’imaginais”. J’ai commencé par NEDNSProxyProvider parce que je visais un blocage au niveau DNS, puis j’ai découvert les extensions, buté sur les contraintes de signature, et fini par comprendre la bonne manière d’utiliser l’API Screen Time.
Cet article est un index qui relie cinq articles issus de ce parcours. J’espère qu’il pourra aider les personnes peu expérimentées en iOS qui se retrouvent face au même problème.
1. Éviter la mauvaise porte d’entrée
Quand on cherche à bloquer des sites sur iOS, NEDNSProxyProvider semble être exactement ce qu’il faut. Le nom paraît juste, le cas d’usage aussi, mais ce n’est pas destiné aux applications distribuées sur l’App Store. Cette API vise les appareils supervisés gérés via MDM.
Ne choisissez pas NEDNSProxyProvider pour bloquer des sites sur iOS
Lisez d’abord cet article avant de décider d’abandonner l’idée du blocage DNS au profit de l’API Screen Time.
2. L’architecture de base avec l’API Screen Time
La bonne combinaison est FamilyControls + ManagedSettings. On demande l’autorisation avec AuthorizationCenter, on laisse l’utilisateur choisir quoi bloquer avec FamilyActivityPicker, puis on écrit les règles dans ManagedSettingsStore.
Concevoir un blocage d’autocontrôle sur iOS avec FamilyControls + ManagedSettings
Essayer de gérer les cibles bloquées sous forme d’URL saisies en texte libre mène vite dans une impasse. Cet article explique aussi pourquoi la conception basée sur des tokens autour de FamilyActivitySelection est le vrai point de départ.
3. Deux Shield Extensions sont nécessaires
Pour personnaliser l’écran Shield affiché après application des règles par ManagedSettings, il faut deux extensions. Si vous pensez qu’ajouter une seule cible dans Xcode suffit, c’est précisément là que vous allez vous bloquer.
L’interface Shield iOS nécessite deux extensions, pas une
L’article récapitule les Extension Point Identifier, les classes principales et les réglages Info.plist pour la Shield Action Extension (ShieldActionDelegate) et la Shield Configuration Extension (ShieldConfigurationDataSource).
4. Le handoff de déverrouillage entre le Shield et l’app
Apple ne fournit pas de chemin permettant à l’écran Shield de lancer directement l’application principale pour exécuter un flux de déverrouillage. ShieldActionDelegate ne peut renvoyer que .close ou .defer.
Implémenter un handoff de déverrouillage d’une Shield Extension vers l’app principale via App Group
Cet article décrit le modèle où l’extension écrit une “demande de déverrouillage” dans les UserDefaults partagés d’un App Group, puis où l’application la lit lorsque l’utilisateur ouvre l’app. Il explique aussi pourquoi cette contrainte existe et comment rendre l’UX acceptable malgré elle.
5. Les tests sur appareil exigent un compte développeur payant
L’entitlement Family Controls (Development) n’est pas disponible avec un Personal Team reposant sur un Apple ID gratuit. Pour tester sur un vrai appareil, il faut adhérer à l’Apple Developer Program.
Family Controls ne peut pas être testé sur un appareil réel avec un Personal Team
L’article clarifie ce qu’on peut ou non faire sur le simulateur, l’impact sur d’autres entitlements comme In-App Purchase, et le bon moment pour passer à une adhésion payante.
Résumé en séquence de développement
Si vous construisez ce type d’application sans expérience préalable sur iOS, l’ordre d’implémentation devient beaucoup plus clair après la lecture de ces cinq articles.
Commencez par abandonner l’idée NEDNSProxyProvider. Ensuite, fixez l’architecture de base FamilyControls + ManagedSettings et construisez le flux d’interface avec AuthorizationCenter et FamilyActivityPicker. Puis ajoutez les deux Shield Extensions et configurez correctement Info.plist. Après cela, implémentez le handoff de déverrouillage via App Group. Enfin, rejoignez l’Apple Developer Program et vérifiez le comportement sur un appareil réel.
Suivre cet ordre réduit au maximum le risque de devoir refaire l’architecture plus tard. Quand on débute sur iOS, choisir la mauvaise API au départ finit souvent par contaminer tout le reste, donc valider la direction dès le début fait gagner le plus de temps.