iOS SDK für die Offline-Telemetrieerfassung mit Verschlüsselung, Hintergrundbereitstellung und Integration in eine bestehende Anwendung

Ausgangssituation – es gibt eine funktionierende iOS-Anwendung für Außendienstmitarbeiter (iOS 15-17, Swift, UIKit + einige Bildschirme auf SwiftUI). Der Benutzer kann ohne Verbindung arbeiten und Daten über Nutzung und technische Prozesse (Ereignisse, Zeitpläne, Fehler, Sitzungsparameter) müssen garantiert an unsere API übermittelt werden, wenn die Verbindung hergestellt wird. Derzeit werden Telemetriedaten direkt über URLSession gesendet und gehen regelmäßig aufgrund von Offline, Anwendungsbeendigung und Hintergrundaufgabenkonkurrenz verloren. Es gibt auch Anforderungen an die Speicherung sensibler Daten auf dem Gerät und die Lautstärkeregelung.

Die Aufgabe besteht darin, ein modulares iOS SDK (wie Swift Package) für die zuverlässige Erfassung und Bereitstellung von Telemetriedaten zu entwickeln und zu implementieren.

Technische Umgebung und Einschränkungen – Swift 5.9+, Xcode 15+, iOS 15+. Es ist verboten, umfangreiche analytische SDKs (Firebase/Amplitude usw.) zu verbinden. Sie können keine Werbekennungen sammeln und den Benutzer nicht verfolgen. Daten müssen für eine begrenzte Zeit und ein begrenztes Volumen lokal gespeichert werden. Der Serverteil ist bereits vorhanden – der REST-Endpunkt /v1/telemetry/batch akzeptiert gzip JSON, Autorisierung über ein vorhandenes Zugriffstoken von der Anwendung (wir stellen ein Protokoll für den Empfang des Tokens bereit). Das Ereignisformat ist fest – ID (UUID), ts (ISO8601), Typ (Zeichenfolge), Nutzlast (Wörterbuch), Sitzungs-ID.

Was zu tun -
1) Entwerfen Sie eine SDK-Architektur – eine öffentliche API zum Protokollieren von Ereignissen aus der Anwendung, der internen Warteschlange, dem Speicher, der Zustellung und den Weiterleitungen.
2) Lokaler Warteschlangenspeicher – auswählen und implementieren (Core Data oder SQLite/GRDB ohne externe Dienste). Anforderungen: Atomizität, Crash-Resistenz, Fähigkeit zur stapelweisen Probenentnahme, Deduplizierung nach ID.
3) Verschlüsselung auf dem Gerät – Nutzdaten in verschlüsselter Form speichern (AES-GCM), Schlüssel im Schlüsselbund speichern, Schlüsselrotation unterstützen, ohne die Warteschlange zu verlieren.
4) Zustellung – Senden von Stapeln mit gzip, Begrenzung der Stapelgröße (z. B. 256 KB) und der gesamten Warteschlangengröße (z. B. 20 MB) mit einer Richtlinie zum Löschen der ältesten Daten. Retrays mit exponentieller Verzögerung, Jitter und unter Berücksichtigung von Server-Antwortcodes (429/5xx). Respektieren Sie den Energiesparmodus.
5) Hintergrundskripte – funktionieren korrekt, wenn sie in den Hintergrund gehen und die Anwendung beenden. Verwenden Sie BGTaskScheduler für die regelmäßige Zustellung sowie für den Versand, wenn das Netzwerk verfügbar ist. Verstoßen Sie nicht gegen die iOS-Beschränkungen für Hintergrundaktivitäten.
6) Netzwerküberwachung – Network.framework (NWPathMonitor) für den Auslöser der Zustellung, wenn die Verbindung wiederhergestellt wird.
7) Integration in die Anwendung – ersetzen Sie das aktuelle direkte Senden durch das SDK an 2-3 Protokollierungspunkten (z. B. Fehler, Navigationsereignisse, Systemzeiten). Stellen Sie threadsichere Aufrufe von verschiedenen Threads bereit.
8) Testen – Schlüsselbereiche mit Komponententests abdecken (Warteschlangen, Verschlüsselung, Stapelbildung, Weiterleitungsrichtlinien). Fügen Sie minimale Integrationstests zum Mock-Server (URLProtocol) und Offline-Online-Skripttests hinzu.

Das konkrete Ergebnis ist ein Repository mit Swift Package (Quellen, Tests), einem Anwendungsbeispiel und Anleitungen zur Integration in eine bestehende Anwendung, plus MR/PR mit Anbindung des Pakets und Ersetzung alter Sendeaufrufe.

Messbare Akzeptanzkriterien -
- Wenn der Flugzeugmodus aktiviert ist, werden Ereignisse in die Warteschlange geschrieben und gehen nach dem Neustart der Anwendung nicht verloren; Nachdem der Flugmodus deaktiviert wurde, werden alle akkumulierten Ereignisse innerhalb von maximal 15 Minuten an den Endpunkt übermittelt, wenn die Anwendung aktiv verwendet wird.
- Die Größe der Warteschlange ist auf 20 MB begrenzt. Bei Überschreitung werden die ältesten Ereignisse gelöscht, die Anwendung stürzt nicht ab und friert nicht ein.
– Nutzdaten auf der Festplatte werden nicht im Klartext gespeichert – Überprüfung durch Inspektion von Containerdateien (Strings aus JSON werden nicht als Klartext gelesen).
- Das SDK nutzt keine verbotenen Analysedienste Dritter und fordert keine unnötigen Berechtigungen an.
- Die Lieferung erfolgt stapelweise mit gzip, verarbeitet 429 und 5xx (Retrays) korrekt, 4xx außer 429 werden nicht nachgereicht.
- Unit-Tests werden lokal in CI ausgeführt (xcodebuild-Test) und decken mindestens 60 % des Codes des Bereitstellungs-/Warteschlangenmoduls ab.

Darüber hinaus können Sie eine Formatoptimierung anbieten (z. B. kompaktes JSON/CBOR), aber das endgültige Wire-Format sollte JSON bleiben, so wie es jetzt auf dem Server ist.