Apple HealthKit: Gesundheitsdaten on-device

Foto: Direct Media · StockSnap (CC0 1.0), via Openverse

Gesundheitsdaten sind die heikelste Kategorie von Daten, die eine App überhaupt verarbeiten kann. Sie sagen etwas über den Körper eines Menschen aus, über seinen Schlaf, seinen Puls, seine Bewegung — und niemand gibt so etwas leichtfertig aus der Hand. Als wir angefangen haben, über die Anbindung von Apple HealthKit nachzudenken, war die erste Frage deshalb nicht "Wie kommen wir an die Daten?", sondern "Wie kommen wir an möglichst wenig davon heran und behalten trotzdem den Nutzen?".

Diese Woche geht es um die Apple-HealthKit-Integration in Xircuit: was sie liest, warum sie das Gerät nicht verlässt, wo sie in einer Blazor-Hybrid-App überhaupt sitzt — und was es bedeutet, dass wir sie mit voller iOS-Parität in Produktion ausgeliefert haben.

Warum on-device die Grundentscheidung war

Die naheliegende Architektur für eine Gesundheitsdaten-Integration wäre ein Server-seitiger Poller: Ein Dienst holt regelmäßig die Werte einer Nutzerin ab, legt sie in einer Datenbank ab, und die App liest sie von dort. Genau das machen wir für einige cloud-basierte Anbieter auch. Bei Apple ist der Weg ein anderer, und das ist Absicht.

HealthKit ist von Apple bewusst so gebaut, dass die eigentlichen Gesundheitsdaten das Gerät nicht ohne Weiteres verlassen. Der Zugriff läuft über eine lokale API, die nur auf dem iPhone selbst existiert. Wir haben uns entschieden, diesem Modell zu folgen statt es zu umgehen: Schritte, Kalorienverbrauch, Herzfrequenz und Aktivitätseinheiten werden direkt auf dem Gerät gelesen und dort verarbeitet. Was der Nutzer in der App sieht, entsteht lokal — nicht in unserer Cloud.

Das ist bequemer für uns beim Datenschutz, aber es ist auch die ehrlichere Architektur. Wenn jemand fragt, wo seine Herzfrequenz gespeichert ist, ist die Antwort "auf Ihrem Telefon" deutlich beruhigender als eine Erklärung über verschlüsselte Blobs in einer Datenbank.

Was HealthKit tatsächlich liefert

Konkret liest die Integration vier Datentypen aus HealthKit: die Schrittzahl, den aktiven Kalorienverbrauch, die Herzfrequenz und die Aktivitätseinheiten — also die Minuten, die Apple in seinen Aktivitätsringen als "bewegt" zählt. Das sind bewusst die Werte, die für ein Gesundheits- und Fitness-Bild den größten Nutzen bei der geringsten Eingriffstiefe bieten.

Für uns sind das keine Rohdaten, die wir bloß anzeigen. Sie fließen in dieselben internen Metriken ein wie Werte aus anderen Quellen, sodass ein Schritt aus HealthKit und ein Schritt aus einer anderen Anbindung am Ende im selben Diagramm landen. Diese Vereinheitlichung ist der eigentliche Grund, warum sich der Aufwand einer nativen Anbindung lohnt: Eine Zahl allein ist wenig wert, eine Zahl im Kontext einer Woche ist ein Signal.

Einwilligung ist kein Häkchen, sondern die Architektur

Der Teil, der am meisten Sorgfalt gekostet hat, ist die Einwilligung. HealthKit-Zugriff ist strikt einwilligungsbasiert, und Apple meint das ernst: Man bekommt nicht pauschal "Gesundheitsdaten", sondern muss jeden einzelnen Datentyp separat anfragen. Die App fordert granulare Berechtigungen an — für Schritte, für Herzfrequenz, für Kalorien, für Aktivität jeweils einzeln.

Das hat eine unangenehme, aber wichtige Konsequenz: Apple sagt der App aus Datenschutzgründen nicht einmal zuverlässig, ob eine Leseberechtigung verweigert wurde. Aus Sicht der App ist "keine Daten vorhanden" und "Zugriff abgelehnt" nur schwer zu unterscheiden. Man muss den Code also so schreiben, dass ein leeres Ergebnis niemals wie ein Fehler behandelt wird und dass die Oberfläche auch dann sinnvoll aussieht, wenn die Nutzerin nur einen Teil der Datentypen freigegeben hat. Wir zeigen entsprechend nur das an, wofür wir tatsächlich eine Freigabe und Daten haben — der Rest bleibt schlicht unsichtbar, ohne Fehlermeldung.

Foto: Joshua Sortino · StockSnap (CC0 1.0), via Openverse

Wo der native Zugriff in einer Blazor-Hybrid-App sitzt

Xircuit ist eine Blazor-Hybrid-App. Das heißt, der größte Teil der Oberfläche und der Logik lebt in gemeinsamem .NET-Code, der auf allen Plattformen identisch läuft. HealthKit dagegen ist eine zutiefst plattformspezifische Apple-Technologie — es gibt sie nur auf iOS, und der Zugriff geht über native Frameworks, die im gemeinsamen Code schlicht nicht existieren.

Die Lösung ist eine saubere Schichtentrennung. Der eigentliche HealthKit-Zugriff sitzt in einer plattformspezifischen MAUI-Schicht, die nur im iOS-Build kompiliert wird. Darüber liegt eine Abstraktion — im Kern eine Schnittstelle, die sagt "gib mir die Schritte der letzten sieben Tage" —, und dahinter kann jede Plattform ihre eigene Implementierung stellen. Der gemeinsame .NET-Code kennt nur diese Schnittstelle und weiß nichts von HealthKit. Auf iOS wird die native Implementierung registriert, auf Plattformen ohne HealthKit eine, die einfach nichts liefert.

Dieser Aufbau hat einen angenehmen Nebeneffekt: Die Blazor-Komponenten, die die Daten anzeigen, mussten für HealthKit gar nicht angefasst werden. Sie fragen die Abstraktion, bekommen Werte, und ob die aus HealthKit oder aus einer anderen Quelle stammen, ist ihnen gleichgültig. Genau so soll eine plattformspezifische Integration aussehen: ein kleiner, gut abgegrenzter nativer Kern und ein großer, unveränderter gemeinsamer Rest.

Warum Samsung nicht denselben Weg geht

Eine Frage, die naheliegt: Wenn wir schon eine native Anbindung bauen, warum dann nicht gleich eine für Samsung-Geräte? Die Antwort ist eine bewusste Zurückhaltung. Wir bedienen Samsung nicht über einen eigenen, dedizierten Build mit einer proprietären Samsung-Health-Anbindung. Stattdessen werden Samsung-Geräte später über Health Connect abgedeckt — die geräteübergreifende Gesundheitsdaten-Brücke unter Android, die Fitbit, Pixel und eben auch Samsung unter einem Dach zusammenführt.

Der Grund ist pragmatisch: Jede zusätzliche native Anbindung ist eine eigene Berechtigungslogik, ein eigener Freigabeprozess und eine eigene Pflegelast. Health Connect erlaubt uns, mit einer Integration eine ganze Familie von Android-Geräten zu erreichen, statt für jeden Hersteller eine eigene Brücke zu bauen. Das ist genau die Art von Entscheidung, die man am Anfang trifft, damit man in einem Jahr nicht fünf halb gepflegte Integrationen hat.

Ausgeliefert und on-device verifiziert

Zum Stand der Dinge: Die iOS-Parität ist nicht Theorie. Sie wurde on-device verifiziert — also auf echter Apple-Hardware getestet, nicht nur im Simulator — und in Produktion ausgeliefert. Mit "Parität" meine ich, dass die vier Datentypen auf iOS vollständig ankommen und in dieselben Ansichten einfließen wie alles andere, ohne Sonderfälle in der Oberfläche.

Dieser Schritt von "kompiliert im Simulator" zu "läuft auf einem echten iPhone" ist bei HealthKit alles andere als Formsache. Der Simulator kann viele Berechtigungs- und Datenszenarien gar nicht realistisch abbilden, und die granularen Freigaben verhalten sich auf echter Hardware anders. Deshalb war die Verifikation auf dem Gerät für uns die eigentliche Ziellinie — und dass sie genommen und die Integration in Produktion ist, ist der Grund, warum ich diese Woche darüber schreibe und nicht erst in ein paar Wochen.

Was kommt als Nächstes?

Nächste Woche: Google Health und Health Connect — Fitbit, Pixel und Samsung über eine gemeinsame Brücke.