Notes d'intégration HealthKit, depuis une app qui l'a construite puis retirée

miniHabits avait un mode HealthKit qui lisait cinq choses : les pas, les minutes d’exercice, les séances, le sommeil et les minutes de pleine conscience. Cinq, ce n’est pas beaucoup, et l’intégration a quand même pris plus de temps que tout l’écran de statistiques. Elle n’est pas dans l’app. App Review a refusé la première soumission au titre de la règle 2.5.1 — le binaire référençait HealthKit alors qu’aucune fonctionnalité principale n’exigeait de données de santé — et plutôt que de discuter, j’ai retiré le mode, parce qu’ils avaient raison.

C’est la partie qui mérite d’être écrite, alors elle vient en premier. Un tracker d’habitudes qui peut éventuellement remplir une habitude depuis Santé n’a pas de fonctionnalité principale exigeant des données de santé. Il a une commodité. La position d’Apple est que HealthKit est fait pour les apps dont l’objet même est la santé et la forme, et un tracker dont l’objet même est une chaîne de jours n’y entre pas parce qu’on lui a ajouté un compteur de pas. Le refus a mis huit jours à arriver et environ une journée à corriger, et l’app y a gagné : ce qui est sorti à la place est une habitude quantité qu’on saisit, et qui ne ment jamais sur la provenance du nombre.

Les notes techniques tiennent toujours, parce que l’intégration fonctionnait avant d’être supprimée.

Les permissions de lecture sont délibérément opaques : pour des raisons de confidentialité, vous ne pouvez pas demander si l’utilisateur a accordé l’accès en lecture à un type, seulement s’il a été sollicité. Un résultat vide veut donc dire soit pas de permission, soit pas de données, et votre interface doit gérer les deux sans accuser l’utilisateur de quoi que ce soit. Les requêtes d’observation se déclenchent plus souvent qu’on ne s’y attend, y compris pour des échantillons qui changent rétroactivement quand une autre app écrit de l’historique, ce qui fait qu’une implémentation naïve recalcule une habitude vingt fois par heure.

Les doublons sont la troisième. Une seule marche peut produire des échantillons de pas depuis le téléphone, la Watch et une app tierce, et les additionner donne un nombre confiant et faux. La requête de statistiques gère ça si vous l’utilisez, la requête d’échantillons non, ce qui n’est pas évident au vu des noms.

Plan

Statut : plan. L’introduction ci-dessus est de la copie finie. Tout ce qui suit est le plan des sections de la version complète, visant environ 1 700 mots.

1. La règle 2.5.1, en entier. Ce que disait le refus, ce qui l’a déclenché, et pourquoi une clé d’Info.plist suffit à le déclencher même quand le framework n’est jamais lié.
2. Les cinq mesures. Pourquoi celles-là, et à quoi chacune correspondait dans l’app.
3. Des permissions de lecture opaques. L’API, la raison derrière, et l’interface qui doit s’en accommoder.
4. Les requêtes d’observation. Trop de déclenchements, modifications rétroactives, et l’amortissement qui a réglé ça.
5. Les échantillons en double. Requête de statistiques contre requête d’échantillons, chiffres à l’appui.
6. La livraison en arrière-plan. Ce que vous obtenez, à quelle fréquence, et ce que le système brise.
7. Retirer le mode sans perdre de données. La migration de décodage qui transforme une habitude Santé enregistrée en habitude quantité au lieu d’un fichier illisible.
8. Quoi construire à la place. Quand un tracker doit se tourner vers HealthKit, et quand il doit simplement laisser saisir un nombre.