SDK iOS pour la collecte de télémétrie hors ligne avec cryptage, livraison en arrière-plan et intégration dans une application existante

Situation initiale - il existe une application iOS fonctionnelle pour les employés de terrain (iOS 15-17, Swift, UIKit + quelques écrans sur SwiftUI). L'utilisateur peut travailler sans connexion, et les données sur l'utilisation et le processus technique (événements, horaires, erreurs, paramètres de session) doivent être garanties d'être transmises à notre API lorsque la connexion apparaît. Actuellement, la télémétrie est envoyée directement via URLSession et est régulièrement perdue en raison de la mise hors ligne, de la suppression d'applications et de la concurrence entre les tâches en arrière-plan. Il existe également des exigences relatives au stockage des données sensibles sur l'appareil et au contrôle du volume.

La tâche consiste à développer et à mettre en œuvre un SDK iOS modulaire (comme Swift Package) pour une collecte et une livraison fiables de télémétrie.

Environnement technique et limitations - Swift 5.9+, Xcode 15+, iOS 15+. Il est interdit de connecter des SDK analytiques lourds (Firebase/Amplitude, etc.). Vous ne pouvez pas collecter d'identifiants publicitaires et suivre l'utilisateur. Les données doivent être stockées localement pendant une durée et un volume limités. La partie serveur est déjà là - le point de terminaison REST /v1/telemetry/batch accepte gzip JSON, l'autorisation via un jeton d'accès existant de l'application (nous fournirons un protocole pour recevoir le jeton). Le format de l'événement est fixe : id (UUID), ts (ISO8601), type (chaîne), charge utile (dictionnaire), sessionId.

Ce qu'il faut faire -
1) Concevoir une architecture SDK - une API publique pour enregistrer les événements de l'application, la file d'attente interne, le stockage, la livraison, les retraits.
2) Stockage de file d'attente locale - sélectionnez et implémentez (Core Data ou SQLite/GRDB sans services externes). Exigences : atomicité, résistance aux crashs, possibilité d'échantillonner par lots, déduplication par identifiant.
3) Chiffrement sur l'appareil - stockez la charge utile sous forme cryptée (AES-GCM), stockez la clé dans le trousseau, prenez en charge la rotation des clés sans perdre la file d'attente.
4) Livraison - envoi de lots avec gzip, limitant la taille du lot (par exemple, 256 Ko) et la taille totale de la file d'attente (par exemple, 20 Mo) avec une politique de suppression des plus anciennes. Retrays avec délai exponentiel, jitter et prise en compte des codes de réponse du serveur (429/5xx). Respectez le mode faible consommation.
5) Scripts d'arrière-plan - fonctionnent correctement lorsque vous passez en arrière-plan et que vous supprimez l'application. Utilisez BGTaskScheduler pour la livraison périodique, ainsi que pour l'envoi lorsque le réseau devient disponible. Ne violez pas les restrictions iOS sur l'activité en arrière-plan.
6) Surveillance du réseau - Network.framework (NWPathMonitor) pour le déclenchement de la livraison lorsque la connexion est rétablie.
7) Intégration dans l'application - remplacez l'envoi direct actuel par le SDK à 2-3 points de journalisation (par exemple les erreurs, les événements de navigation, les horaires du système). Fournissez des appels thread-safe à partir de différents threads.
8) Tests - couvrez les éléments clés avec des tests unitaires (file d'attente, cryptage, formation de lots, politiques de récupération). Ajoutez des tests d'intégration minimaux au serveur fictif (URLProtocol) et des tests de script hors ligne-en ligne.

Le résultat spécifique est un référentiel avec Swift Package (sources, tests), un exemple d'utilisation et des instructions d'intégration dans une application existante, plus MR/PR avec connexion du package et remplacement des anciens appels d'envoi.

Critères d'acceptation mesurables -
- Lorsque le mode avion est activé, les événements sont écrits dans la file d'attente et ne sont pas perdus après le redémarrage de l'application ; une fois le mode avion désactivé, tous les événements accumulés sont transmis au point final dans un délai maximum de 15 minutes lorsque l'application est activement utilisée.
- La taille de la file d'attente est limitée à 20 Mo - si elle est dépassée, les événements les plus anciens sont supprimés, l'application ne plante ni ne se bloque.
- La charge utile sur le disque n'est pas stockée en texte clair - vérification par inspection des fichiers conteneurs (les chaînes de JSON ne sont pas lues en texte brut).
- Le SDK n'utilise pas de services analytiques tiers interdits et ne demande pas d'autorisations inutiles.
- La livraison s'effectue par lots avec gzip, traite correctement les 429 et 5xx (retrays), les 4xx sauf 429 ne sont pas retracés.
- Les tests unitaires sont exécutés localement dans CI (test xcodebuild) et couvrent au moins 60% du code du module de livraison/file d'attente.

De plus, vous pouvez proposer une optimisation du format (par exemple, JSON/CBOR compact), mais le format filaire final doit rester JSON, tel qu'il est actuellement sur le serveur.