hsb.horse
Wenn man ohne iOS-Erfahrung eine Self-Control-App zum Blockieren von Websites bauen will, stößt man schnell auf eine Reihe von Momenten, in denen man merkt: Das funktioniert ganz anders als erwartet. Ich habe mit NEDNSProxyProvider angefangen, weil ich auf DNS-Ebene blockieren wollte, dann Extensions kennengelernt, an Signierungsgrenzen festgehangen und schließlich den tatsächlichen Einsatzpfad der Screen-Time-API verstanden.
Dieser Artikel ist ein Index über fünf einzelne Beiträge, die aus diesem Weg entstanden sind. Ich hoffe, er hilft Menschen mit wenig iOS-Erfahrung, die an derselben Stelle feststecken.
1. Gleich am Anfang nicht falsch abbiegen
Wenn man Website-Blocking unter iOS umsetzen will, fällt einem schnell NEDNSProxyProvider auf. Name und Einsatzzweck wirken passend, aber die Klasse ist nicht für Apps gedacht, die im App Store verteilt werden. Sie ist für überwachte Geräte im MDM-Kontext gedacht.
Beim Bau von Website-Blocking unter iOS sollte man NEDNSProxyProvider nicht wählen
Lesen Sie das zuerst, bevor Sie entscheiden, die DNS-Blocking-Idee aufzugeben und stattdessen zur Screen-Time-API zu wechseln.
2. Das Grunddesign der Screen-Time-API
Die richtige Kombination ist FamilyControls + ManagedSettings. Die Autorisierung holt man über AuthorizationCenter, die Auswahl der zu blockierenden Ziele läuft über FamilyActivityPicker, und die Regeln werden in ManagedSettingsStore geschrieben.
Self-Control-Blocking unter iOS mit FamilyControls + ManagedSettings entwerfen
Wenn man versucht, blockierte Ziele als frei eingegebene URLs zu verwalten, läuft man schnell in eine Sackgasse. Der Artikel erklärt auch, warum das tokenbasierte Design rund um FamilyActivitySelection die eigentliche Grundlage ist.
3. Es werden zwei Shield Extensions benötigt
Um den Shield-Bildschirm anzupassen, der nach dem Setzen von Regeln durch ManagedSettings erscheint, braucht man zwei Extensions. Wenn man denkt, ein zusätzliches Target in Xcode genüge, bleibt man genau hier hängen.
Eine iOS-Shield-Oberfläche braucht zwei Extensions, nicht eine
Dort sind die Extension Point Identifier, Principal Classes und Info.plist-Einstellungen sowohl für die Shield Action Extension (ShieldActionDelegate) als auch für die Shield Configuration Extension (ShieldConfigurationDataSource) zusammengefasst.
4. Unlock-Handoff vom Shield zur App
Apple stellt keinen Weg bereit, mit dem der Shield-Bildschirm direkt die Haupt-App öffnen und einen Unlock-Flow starten kann. ShieldActionDelegate kann nur .close oder .defer zurückgeben.
Unlock-Handoff von einer Shield Extension zur Haupt-App per App Group implementieren
Dieser Artikel beschreibt das Handoff-Muster, bei dem die Extension eine “Unlock-Anfrage” in gemeinsame UserDefaults innerhalb einer App Group schreibt und die App sie liest, sobald die Nutzerin oder der Nutzer die App öffnet. Außerdem geht es darum, warum diese Beschränkung existiert und wie man die UX innerhalb dieser Grenzen sinnvoll gestaltet.
5. Für Gerätetests braucht man ein bezahltes Entwicklerkonto
Das Entitlement Family Controls (Development) ist mit einem kostenlosen Apple-ID-basierten Personal Team nicht verfügbar. Tests auf echten Geräten setzen die Mitgliedschaft im Apple Developer Program voraus.
Family Controls lässt sich mit einem Personal Team nicht auf echten Geräten testen
Der Artikel erklärt, was im Simulator möglich ist und was nicht, wie sich das zu anderen Entitlements wie In-App Purchase verhält und wann sich eine kostenpflichtige Mitgliedschaft lohnt.
Zusammenfassung als Entwicklungsreihenfolge
Wenn man diese App ohne iOS-Vorerfahrung baut, wird die Implementierungsreihenfolge nach der Lektüre dieser fünf Beiträge deutlich klarer.
Zuerst verabschiedet man sich von der Idee mit NEDNSProxyProvider. Danach legt man das Grunddesign mit FamilyControls + ManagedSettings fest und baut den UI-Flow mit AuthorizationCenter und FamilyActivityPicker. Anschließend fügt man die zwei Shield Extensions hinzu und konfiguriert Info.plist korrekt. Danach implementiert man das Unlock-Handoff per App Group. Zum Schluss tritt man dem Apple Developer Program bei und testet alles auf einem echten Gerät.
In dieser Reihenfolge ist die Wahrscheinlichkeit am geringsten, dass das Design später neu gebaut werden muss. Gerade ohne iOS-Erfahrung vergiftet eine falsche API-Entscheidung am Anfang oft alles, was danach kommt. Deshalb spart es am meisten Zeit, die Richtung früh zu klären.