SDK iOS pour l'analyse QR hors ligne et la validation des tickets avec signature cryptographique et journalisation (Swift, iOS 15+)

Situation initiale : nous disposons d'une application iOS pour contrôler l'accès aux événements. Actuellement, les billets sont vérifiés via un serveur, c'est pourquoi il y a une file d'attente dans les lieux où la connexion Internet est mauvaise. Nous devons créer un module SDK iOS interne qui nous permettra de valider les tickets complètement hors ligne et de synchroniser les résultats ultérieurement.

Environnement technique et domaine : iOS 15+, Swift 5.9+, Xcode 15+, SPM. Numérisation - AVFoundation. Stockage - CoreData ou SQLite (nous en discuterons, mais nous devons travailler hors ligne et résister aux plantages). Cryptographie - CryptoKit. Le format du ticket est QR, à l'intérieur de la charge utile base64url sous forme de JSON. Validation - Vérification de signature Ed25519 et vérification des règles (événement, date, zone, réutilisation).

Quel devrait être le résultat : 1) Swift Package (SPM) avec une API publique pouvant être connectée à notre application. 2) Exemple d'intégration (petite cible de démonstration ou exemple d'application dans le référentiel) juste pour afficher les appels API et le flux de données. 3) Un ensemble de tests unitaires et de tests de performances de base pour les parties critiques (analyse, validation, enregistrement d'événements).

Exigences fonctionnelles : 1) Analyse QR via AVFoundation avec prise en charge du flux continu - renvoyant le résultat sous la forme d'un objet structuré (ticketId, eventId, zoneId, émisAt, validFrom, validTo, signature). 2) Validation hors ligne - vérification de la signature Ed25519 à l'aide de la clé publique de l'événement, vérification de la fenêtre horaire et du fuseau, protection contre la réutilisation des tickets sur un seul appareil (anti-réutilisation locale). 3) File d'attente des événements : toutes les tentatives et décisions d'analyse (acceptées/refusées + motif) sont écrites sur le stockage local et peuvent être téléchargées ultérieurement par lots. 4) Synchronisation - une méthode SDK qui accepte un rappel/protocole pour envoyer un paquet à notre API (nous avons notre propre couche réseau, le SDK ne doit donc pas imposer de bibliothèque HTTP spécifique). Il devrait y avoir des retraits, une déduplication et un marquage des événements envoyés avec succès. 5) Gestion des clés - la possibilité de mettre à jour un ensemble de clés publiquesclés privées (par exemple, clés pour plusieurs eventIds) via la configuration et enregistrées localement. Il doit y avoir une version de la configuration et un remplacement sûr sans perdre la possibilité de vérifier les tickets précédemment émis.

Limitations : 1) Travaillez strictement hors ligne lors de la numérisation - aucune requête réseau au moment de la numérisation. 2) Vous ne pouvez pas utiliser de SDK tiers lourds pour l'analyse ou les bases de données - uniquement des frameworks Apple standard ou des dépendances très légères via SPM, comme convenu. 3) L'API publique du package doit être minimale et documentée dans les commentaires (SwiftDoc). 4) Le code doit être compatible avec iOS 15 et versions ultérieures, sans API privée.

Critères d'acceptation (mesurables) : 1) La validation d'un ticket correct avec vérification de signature ne prend pas plus de 30 ms sur l'iPhone 12 dans la version release, avec une moyenne de 100 exécutions. 2) Le SDK rejette correctement au moins 6 types d'erreurs avec des codes/raisons clairs : signature incorrecte, expirée, pas encore active, zone invalide, réutilisation, ID d'événement/clé inconnu. 3) Après 500 analyses hors ligne, tous les événements sont disponibles dans la file d'attente et ne sont pas perdus lorsque l'application est forcée de s'arrêter (kill) puis redémarrée. 4) Les tests unitaires couvrent au moins 70 % de la logique d'analyse/validation/file d'attente (en utilisant la couverture Xcode). 5) Exemple d'intégration : démarrage du scanner, obtention du résultat, appel de validate, enregistrement d'un événement et démarrage de la synchronisation.

Étapes de mise en œuvre : 1) Clarification du format de charge utile et du protocole de synchronisation, fixation du SDK API public. 2) Implémentation de base - analyseur, vérification cryptographique, règles de validation. 3) Mise en place du stockage et de la file d'attente d'événements + déduplication. 4) Intégration du scanner, échantillon, tests et optimisation.

Nous fournirons : des exemples de charges utiles QR, des clés de test Ed25519, une spécification d'API simulée pour le téléchargement d'événements et une liste de règles métier par zone/heure.