hsb.horse
L’une des premières surprises quand on commence le développement iOS, c’est qu’il existe des fonctionnalités inutilisables sur un vrai appareil même quand le build passe. On essaie de lancer une app basée sur la Screen Time API sur un appareil réel, puis on se retrouve immédiatement bloqué par la signature. Dans beaucoup de cas, la cause est la limite de Personal Team.
Personal Team est l’équipe de développement créée automatiquement quand on se connecte à Xcode avec un Apple ID gratuit. Le mécanisme permet de compiler une app et de la lancer sur son propre appareil sans payer, mais les capacités disponibles sont limitées.
Family Controls Development est réservé aux membres payants
Une app qui utilise FamilyControls a besoin de l’entitlement Family Controls (Development), autrement dit l’autorisation qui lui permet d’utiliser cette capacité. Personal Team ne peut pas l’obtenir.
Apple le mentionne dans Supported capabilities (iOS). C’est explicitement listé comme indisponible pour Personal Team, sans exception.
Autrement dit, tester ce type d’app sur un vrai appareil suppose une adhésion payante à l’Apple Developer Program, actuellement 99 dollars par an. Sans expérience iOS, on a facilement tendance à penser que tout peut être fait gratuitement, mais cette barrière existe.
Jusqu’où aller avec le simulateur
Dans le simulateur, l’app compile même sans entitlement Family Controls. La vérification des types à la compilation et la logique des couches qui n’utilisent pas directement FamilyControls peuvent encore être testées de cette manière.
En revanche, le flux d’autorisation de AuthorizationCenter, l’application des règles ManagedSettings et l’affichage réel de l’écran de shield ne peuvent pas être vérifiés dans le simulateur. Quand on débute sur iOS, on peut facilement penser que “si ça marche dans le simulateur, c’est bon”, mais la Screen Time API se comporte très différemment entre simulateur et appareil réel.
Le plus réaliste est donc d’utiliser le simulateur pour détecter les erreurs de compilation et vérifier la mise en page de l’UI.
App Group peut aussi être concerné
Family Controls n’est pas la seule capacité limitée par Personal Team. App Group, le mécanisme qui permet à une app et à ses extensions de partager des données, fonctionne en principe avec Personal Team, mais certaines configurations peuvent quand même poser problème.
En plus de cela, In-App Purchase ne peut pas non plus être provisionné avec Personal Team. Si la monétisation fait partie du projet, mieux vaut préparer l’environnement comme membre payant dès le départ.
À quel moment devenir membre payant
Si on continue le développement sans test sur appareil réel, on finit par arriver à une situation où l’app compile, mais où rien ne peut vraiment être validé. Une grande partie du comportement des Shield Extensions et de l’application des règles ManagedSettings ne peut être vérifiée que sur un vrai appareil.
Si ce projet est sérieux, il vaut mieux prendre la décision au moment où le premier test sur appareil réel devient nécessaire. Attendre “que l’implémentation soit terminée” revient à repousser le problème jusqu’au moment où l’environnement commence à faire perdre du temps. Sans expérience iOS, ce type de blocage est difficile à anticiper, donc il vaut mieux le savoir tôt.
Faire tout ce qui est possible avec Personal Team avant de payer réduit le risque financier initial, mais il faut partir du principe que le flux de développement s’interrompra à un moment donné.