Mit Personal Team kann Family Controls nicht auf echten Geräten getestet werden

Eine der ersten Überraschungen in der iOS-Entwicklung ist, dass es Funktionen gibt, die selbst dann auf echten Geräten nicht nutzbar sind, wenn der Build erfolgreich ist. Man versucht eine App mit der Screen Time API auf echter Hardware zu starten und steckt sofort bei Signierung und Provisioning fest. In vielen Fällen ist die Ursache die Beschränkung von Personal Team.

Personal Team ist das Entwicklungsteam, das Xcode automatisch erzeugt, wenn man sich mit einer kostenlosen Apple ID anmeldet. Damit lässt sich eine App ohne Zahlung bauen und auf dem eigenen Gerät starten, aber die verfügbaren Capabilities sind begrenzt.

Family Controls Development ist nur für zahlende Mitglieder verfügbar

Eine App, die FamilyControls verwendet, benötigt die Entitlement Family Controls (Development), also im Grunde die Erlaubnis, diese Capability überhaupt zu nutzen. Mit Personal Team lässt sie sich nicht erhalten.

Apple führt das in Supported capabilities (iOS) auf. Dort ist klar vermerkt, dass die Capability für Personal Team nicht verfügbar ist. Ausnahmen gibt es nicht.

Das bedeutet: Wer solche Apps auf echten Geräten testen will, braucht eine kostenpflichtige Mitgliedschaft im Apple Developer Program, derzeit 99 US-Dollar pro Jahr. Ohne iOS-Erfahrung geht man leicht davon aus, dass alles kostenlos möglich ist, aber genau an dieser Stelle steht eine harte Grenze.

Was im Simulator geprüft werden kann

Im Simulator lässt sich die App auch ohne Family Controls Entitlement bauen. Typprüfung beim Kompilieren und Logik in Schichten, die FamilyControls nicht direkt aufrufen, können dort weiterhin geprüft werden.

Was im Simulator nicht geprüft werden kann, sind der Autorisierungsfluss von AuthorizationCenter, die Anwendung von ManagedSettings Regeln und das tatsächliche Verhalten des Shield-Screens. Gerade am Anfang denkt man schnell: „Im Simulator lief es doch.“ Bei der Screen Time API unterscheiden sich Simulator und echtes Gerät aber deutlich.

Praktisch betrachtet sollte der Simulator deshalb vor allem für Compile-Fehler und UI-Layout verwendet werden.

App Group kann ebenfalls betroffen sein

Family Controls ist nicht die einzige Capability mit Einschränkungen in Personal Team. App Group, also der Mechanismus für Datenaustausch zwischen App und Extension, funktioniert grundsätzlich auch dort, kann aber in bestimmten Setups trotzdem Einschränkungen zeigen.

Zusätzlich kann auch In-App Purchase mit Personal Team nicht provisioniert werden. Wenn Monetarisierung Teil des Plans ist, sollte die Umgebung von Anfang an als zahlendes Konto aufgebaut werden.

Wann man zahlendes Mitglied werden sollte

Wer ohne Tests auf echten Geräten weiterentwickelt, landet irgendwann in einer Situation, in der die App zwar baut, aber nicht mehr sinnvoll verifiziert werden kann. Ein großer Teil des Verhaltens von Shield Extensions und ManagedSettings Regeln lässt sich nur auf realer Hardware prüfen.

Wenn die App ernsthaft entwickelt werden soll, ist der beste Zeitpunkt für den Beitritt der Moment, in dem der erste Test auf einem echten Gerät nötig wird. Wenn man bis „nach der Implementierung“ wartet, trifft einen das Umgebungsproblem genau dann, wenn es am meisten Zeit kostet. Ohne iOS-Erfahrung ist diese Art von Blockade schwer vorhersehbar, deshalb lohnt es sich, das früh zu verstehen.

Erst alles mit Personal Team auszureizen und dann über den Beitritt zu entscheiden, reduziert zwar das finanzielle Risiko am Anfang, aber man muss einplanen, dass der Entwicklungsfluss an einem Punkt stoppt.