Expertise · Mobile Apps
Wir bauen native iOS-Apps in Swift, mit Sensoren und HealthKit, sowie Single-Code-Apps für iOS, Android und Web, wenn das Projekt keine Sensoren erfordert. Der Kern der Logik wird getrennt vom Bildschirm getestet.
Bereits gebautEs sind drei eigene Implementierungen, nicht eine. Ein Repository mit fünf App-Zielen (vier iOS und ein macOS), definiert in `project.yml`, dessen Logiktests wir heute ausgeführt haben: 160 von 160 bestehen. Eine zweite iOS-App, in einem anderen Projekt, mit 40 Swift-Dateien und HealthKit. Und eine dritte Richtung, mit einem einzigen Code für iOS, Android und Web, deren Web-Variante heute antwortet. Der Vorbehalt, der die Antwort auf die Frage verändert, die jeder Käufer vor allem anderen stellt: Keine unserer Apps ist im App Store oder bei Google Play veröffentlicht. Der Grund ist nur einer und hat einen Namen — `DEVELOPMENT_TEAM` ist in der Projektkonfiguration leer, das heißt, die Team-ID aus dem Apple Developer Program fehlt. Die Maschine hat eine gültige Signaturidentität, ausreichend für die Installation auf dem eigenen Gerät, unzureichend für die Verteilung im Store. Es ist ein Kontoproblem, kein Codeproblem, aber es bleibt ein Problem, und wir schreiben es hier hin, nicht in die Fußnote.
Eine Mobile App hat zwei Teile, die sich unterschiedlich kaputtgehen. Der Teil, der Sensoren liest und etwas berechnet — einen Winkel, einen Score, einen Zustand — und der Teil, der Bildschirme zeichnet. Wir halten sie getrennt, und das nicht aus ästhetischen Gründen: In unserem Haupt-iOS-Repository importieren die Kerndateien die Oberfläche nicht, sodass sie direkt mit `swiftc` auf dem Mac kompiliert und wie ein gewöhnliches Programm ausgeführt werden können, ohne Simulator und ohne Telefon. Die Suite hat 160 Prüfungen, gruppiert in 16 Stufen; wir haben sie heute ausgeführt und sie besteht vollständig. Deshalb können wir sagen, was ein Algorithmus genau macht, statt zu sagen, dass er „gut funktioniert“.
Auf iOS arbeiten wir mit Swift 6, mit minimalem Ziel iOS 17. Dasselbe Repository definiert fünf Apps als separate Ziele: vier für iPhone und eine für macOS, und die macOS-Version verwendet fünfzehn Dateien aus dem Kern der iOS-Version wieder, ohne Kopieren. Die Sensoren werden an der Quelle gelesen: Die Apple-Schnittstelle für Sensoren in Kopfhörern gibt die Kopforientierung aus, und die App vergleicht den aktuellen Winkel mit einer Position, die der Nutzer zu Beginn der Sitzung kalibriert. Die Schwellenwerte sind keine „internen Einstellungen“: unter 7° ist gerade, zwischen 7° und 13° ist Schieflage, über 13°, drei Sekunden gehalten, löst den Alarm aus, und die Glättung verwendet einen exponentiellen Mittelwert mit dem Koeffizienten 0,15. Alle vier Werte stehen in vier aufeinanderfolgenden Codezeilen und können gezeigt werden.
Wenn das Projekt keine Sensoren braucht, empfehlen wir nicht nativ. Die dritte Richtung im Portfolio ist ein einziger Code, der für iPhone, Android und Browser kompiliert wird — React Native mit Expo — und die Web-Version ist veröffentlicht und antwortet heute. Der praktische Unterschied für den Kunden: Ein Fragebogen, ein Rechner oder ein Dashboard rechtfertigen keine zwei Teams und zwei Repositories; eine App, die einen Sensor zwanzigmal pro Sekunde abfragt, schon.
Was wir noch nicht können. Keine unserer Apps ist im App Store oder bei Google Play. Nicht, weil sie nicht kompiliert — sie kompiliert, lässt sich im Simulator installieren und besteht die Tests — sondern weil in der Projektkonfiguration die Apple-Team-ID leer ist, das heißt, es gibt keine Registrierung im Apple Developer Program, die mit diesen Builds verknüpft ist. Auf dem Mac gibt es eine gültige Signieridentität vom Typ Development, die für die Installation auf dem eigenen Gerät reicht und für den Store nicht ausreicht. Bei einem Kundenprojekt wird das Entwicklerkonto auf der Firma des Kunden eröffnet und bleibt sein Eigentum — das ist das Gespräch, das am Anfang geführt werden muss, nicht am Ende.
Was dazugehört
Auf iOS verwenden wir direkt die Apple-Schnittstellen: `CMHeadphoneMotionManager` für die Kopforientierung aus den Kopfhörern, mit Delegate für Verbinden und Trennen sowie expliziter Prüfung des Autorisierungsstatus, bevor der Datenstrom gestartet wird. Wenn der Sensor nicht verfügbar ist, wechselt der Zustand zu `waiting`, nicht zu einem stillen Fehler.
Die Analyse-, Kalibrierungs-, Verlaufs- und Politikdateien sind reines Swift. Sie werden zusammen mit der Testdatei mit `swiftc` kompiliert und als Kommandozeilen-Binärdatei ausgeführt. Das Ergebnis von heute: 160 Prüfungen, 16 Stufen zu je 10, alle bestanden. Ein Test, der auf dem Mac in zwei Sekunden läuft, läuft bei jeder Änderung; einer, der einen Simulator braucht, nicht.
SwiftUI für beide. Das macOS-Ziel desselben Repositories enthält fünfzehn Dateien aus dem iOS-Kern als gemeinsam genutzte Quellen, nicht als kopierte Dateien, also gelangt eine Korrektur im Algorithmus gleichzeitig in beide Apps.
Expo über React Native, mit `react-native-web` für die Browser-Version, aus dem Paket geladene Schriftarten und separate App-Symbole für Android, einschließlich der vom System verlangten monochromen Variante. Dieselbe App läuft auf dem Telefon und in der Seite, aus einem einzigen Repository.
Nicht „wir lesen HealthKit“, sondern eine Tabelle im Code: elf Datentypen (Haltungswinkel, rohe Bewegung aus den Kopfhörern, Puls und Variabilität, Schlaf, Gehen, Audioexposition, geführte Sitzungen und weitere) und fünf mögliche Modi (nur lokal, Lesen aus HealthKit, Schreiben eines Trainings, Schreiben einer Entspannungssitzung, Schreiben einer Route). Jeder Typ erhält ausdrücklich einen der Modi. Die zweite iOS-App im Portfolio, aus einem privaten Projekt, verwendet denselben Ansatz in 40 Swift-Dateien.
Vier Ziele haben `PrivacyInfo.xcprivacy` als Build-Ressource eingebunden, nicht hastig nach der ersten Ablehnung hinzugefügt. Die Verwendungsbeschreibungen für Bewegung, Kamera, Mikrofon, HealthKit und Benachrichtigungen sind auf Rumänisch, in der Projektkonfiguration, nicht automatisch generiert.
Die Suche nach `URLSession` in den Quellen des iOS-Ziels liefert null Treffer. Der Verlauf wird auf dem Gerät geschrieben, über `FileManager` und `UserDefaults`, mit Option zum Löschen der Datei. Der einzige Netzcode im Repository ist in einer Funktion der macOS-App, in einer separaten Datei. Wenn eine App keinen Server braucht, fügen wir ihr keinen hinzu.
Das Onboarding hat 24 Schritte mit eindeutigen und geordneten Kennungen, und einige Schritte verlangen eine explizite Bestätigung (Sensorgrenzen, Verhalten im Vordergrund, Vertraulichkeit, Vorbereitung), ohne die die Weiter-Schaltfläche gesperrt bleibt. Der Zustand wird codiert und wieder aufgenommen. Zehn der 160 Tests prüfen genau das.
Wir prüfen, welches Entwicklerkonto vorhanden ist, auf welche Firma, wer es verwaltet und was fehlt, damit der Build für den Store signiert werden kann. Es ist eine kurze und langweilige Liste, aber sie macht den Unterschied zwischen einer App, die auf unserem Telefon läuft, und einer, die zu den Nutzern gelangt.
Wie es aussieht
Die Frage ist keine Geschmacksfrage, sondern eine Hardwarefrage: braucht die App Bewegung, Gesundheit, Bluetooth, Kamera in Echtzeit, Hintergrund? Wenn ja, nativ. Wenn es um Formulare, Berechnungen, Listen und ein Dashboard geht, erledigt ein einziger Code für iOS, Android und Web dieselbe Aufgabe mit halb so viel Wartung. Wir liefern die schriftliche Entscheidung mit dem Grund.
Der Algorithmus, die Schwellen, die Zustände und die Persistenz. Die Tests werden direkt auf dem Mac kompiliert und in wenigen Sekunden ausgeführt. Wir liefern die Suite und ihr Ergebnis, nicht ein Qualitätsversprechen.
SwiftUI auf iOS und macOS, oder React Native, wenn wir den gemeinsamen Code gewählt haben. Wir prüfen den Einstiegspfad, die Berechtigungen und das Verhalten, wenn der Sensor fehlt oder sich mitten in der Sitzung trennt — der Fall, der in der Praxis oft kaputtgeht.
Paketkennung, Version, Symbole, Datenschutzdatei, Berechtigungsbeschreibungen, Team-ID aus dem Apple Developer Program. Hier bleiben Projekte hängen, die das Konto nicht von Anfang an besprochen haben — auch unsere, was genau der Grund ist, warum wir diesen Schritt auf Papier setzen.
Die Daten
Die Fragen, die jede Person mit einem Datenschutzbeauftragten stellt — hier gestellt, bevor er sie stellt.
Ein Fall
Die Ausgangslage
Ein eigenes Projekt, nicht das eines Kunden: ein Konzentrations-Timer, der beobachtet, wie stark der Kopf im Verhältnis zu einer vom Nutzer zu Beginn der Sitzung kalibrierten Position geneigt ist. Ich brauchte einen Fall, in dem Aussagen über den Algorithmus gezeigt, nicht beschrieben werden konnten.
Was wir gebaut haben
Ich habe den Kern von der Oberfläche getrennt und die Schwellenwerte in Code geschrieben, nicht in die Dokumentation: unter 7° gerade, zwischen 7° und 13° Abgleiten, über 13° für drei Sekunden löst die haptische Warnung aus, mit exponentieller Glättung beim Koeffizienten 0,15. Die Daten kommen über die Apple-Oberfläche für die Sensoren in den Kopfhörern, mit expliziter Behandlung der Trennung. Das Onboarding hat 24 Schritte, von denen vier die Bestätigung der Grenzen verlangen, bevor der Nutzer weitermachen darf. Aus demselben Kern habe ich auch eine macOS-Variante gebaut.
Was dabei herauskam
Die Logik-Suite wird mit `swiftc` kompiliert und läuft auf dem Mac in wenigen Sekunden: 160 Prüfungen in 16 Etappen, alle beim letzten Lauf bestanden. Die App wird installiert und startet im Simulator. Jede Aussage im obigen Absatz kann überprüft werden, indem Sie vier Codezeilen öffnen.
Was der Fall nicht sagt
Sie ist nicht im App Store. Die Projektkonfiguration hat eine leere Apple-Team-ID, daher kann der Build nicht für die Verteilung signiert werden — ein fehlender Eintrag im Apple-Programm, kein fehlender Funktionsumfang. Und noch eine Grenze, des Produkts und nicht des Codes: Sie misst die Kopfneigung, nicht die Gesundheit der Wirbelsäule, und funktioniert mit den Kopfhörern, die Bewegungssensoren über die Apple-Oberfläche bereitstellen.
Fragen
Nein. Keine unserer Apps ist im App Store oder bei Google Play, und es ist richtig, das zuerst zu fragen. Was wir zeigen können: fünf im selben Projekt definierte App-Ziele, davon vier für iPhone und eines für macOS, die kompilieren und im Simulator installiert werden, plus die Logik-Suite mit 160 Prüfungen, die auf Anfrage vor Ihnen ausgeführt wird. Die Blockade bei der Veröffentlichung ist `DEVELOPMENT_TEAM` leer in der Projektkonfiguration, also das Fehlen einer Team-ID aus dem Apple Developer Program. Auf dem Mac gibt es eine gültige Signaturidentität vom Typ Entwicklung — ausreichend für die Installation auf dem eigenen Gerät, nicht für den Store.
Aus nichts, wenn Sie einen Nachweis der Veröffentlichung verlangen — wir haben keinen und erfinden auch keinen. Was Sie prüfen können, ist der Rest der Kette: Code, der kompiliert, Tests, die bestehen, vorhandene Datenschutzdateien, deklarierte Berechtigungen, konfigurierte Symbole und Versionen. Der fehlende Schritt ist eine bezahlte Einschreibung in ein Apple-Programm, abgeschlossen auf die Firma, der die App gehört. In einem Kundenprojekt gehört dieses Konto dem Kunden und wird am Anfang eröffnet, genau damit es nicht der Schritt ist, der am Ende jemanden überrascht.
Das hängt von den Sensoren ab. Wenn die App Bewegung, Gesundheit, Bluetooth oder die Kamera in Echtzeit liest, nativ — diese Oberflächen gehören zur Plattform, und jede Zwischenschicht fügt Verzögerung und neue Fehlerquellen hinzu. Wenn die App im Wesentlichen Formulare, Berechnungen und Ergebnisbildschirme umfasst, deckt ein einziger Code iOS, Android und den Browser aus einem Repository ab. Wir haben beide Varianten im Portfolio und wählen sie mit schriftlicher Begründung, nicht implizit.
Über gemeinsamen Code, ja: Dasselbe Expo-Projekt erzeugt einen Build für Android, mit adaptivem Symbol und der vom System geforderten monochromen Variante, bereits konfiguriert. Native Android-Entwicklung in Kotlin haben wir nicht im Portfolio — wenn ein Projekt sie erfordert, sagen wir das vorher, nicht nach der Unterzeichnung.
Dadurch, dass der Kern nicht vom Bildschirm abhängt. Die Analyse-Dateien werden separat kompiliert, mit dem Swift-Compiler, und als Programm auf dem Mac ausgeführt. Die aktuelle Suite hat 160 Prüfungen in 16 Stufen und läuft in wenigen Sekunden. Was sich so nicht prüfen lässt — wie sich eine Vibration anfühlt, wie ein Bildschirm auf einem bestimmten Telefon aussieht, wie sich Kopfhörer verhalten, wenn sie aus einem Ohr herauskommen — wird auf dem Gerät getestet, und es wird gesagt, was was ist.
Nur wenn Sie sie genehmigen, Typ für Typ, im Apple-Bildschirm, und nur die deklarierten. Im Code ist die Richtlinie für jede Datenart explizit: Einige bleiben nur auf dem Telefon, andere werden aus HealthKit gelesen, andere können zurückgeschrieben werden, als Training oder als Entspannungssitzung. Es wird keine Diagnose gestellt, und die Daten gelangen nicht zu uns.
Sie bleiben auf dem Telefon. In der iOS-Referenzapp aus unserem Portfolio gibt es keinen einzigen Netzwerkanruf — die Suche nach `URLSession` in den Quellen dieses Ziels liefert null Ergebnisse. Der Verlauf wird in einer lokalen Datei gespeichert und kann aus der App gelöscht werden. Wenn ein Projekt einen Server benötigt, bauen wir ihn, setzen ihn aber nicht als Reflex ein.
Es beginnt mit einer Kompatibilitätsprüfung, nicht mit einem Angebot: welche Plattformversion angezielt wird, welche Abhängigkeiten es gibt und welche davon noch gepflegt werden, ob sich der Build auf einem sauberen Rechner reproduzieren lässt, wer das Entwicklerkonto und die Schlüssel besitzt. Es gibt Projekte, bei denen die ehrliche Antwort ist, dass das Umschreiben des Kerns weniger kostet als seine Wartung.
Auf macOS, ja, und aus demselben Kern: In unserem Haupt-Repository verwendet das macOS-Ziel fünfzehn Logikdateien aus der iPhone-App wieder, als gemeinsam genutzte Quellen. Windows ist nicht im Portfolio.
10 davon sind Code und Dateien aus unseren Repositories. Wir veröffentlichen weder ihren Namen noch die Zeile: zusammen, auf einer einzigen Seite, würden sie zu genau beschreiben, wie Systeme gebaut sind, die nicht nur uns gehören. Wir gehen sie mit Ihnen durch, im Repository, auf Anfrage — die Überprüfung bleibt möglich, sie findet nur in einem Gespräch statt.
Erzählen Sie uns von Ihrem Prozess. Gemeinsam legen wir fest, was sich zu bauen lohnt, was wir anbinden können und wie wir das Ergebnis prüfen.