iOS SDK für Offline-QR-Scannen und Ticketvalidierung mit Kryptosignatur und Protokollierung (Swift, iOS 15+)

Ausgangssituation: Wir haben eine iOS-Anwendung zur Kontrolle des Zugangs zu Veranstaltungen. Derzeit werden die Tickets über einen Server überprüft, weshalb es an Veranstaltungsorten mit schlechter Internetverbindung zu einer Warteschlange kommt. Wir müssen ein internes iOS SDK-Modul erstellen, das es uns ermöglicht, Tickets vollständig offline zu validieren und die Ergebnisse später zu synchronisieren.

Technische Umgebung und Themenbereich: iOS 15+, Swift 5.9+, Xcode 15+, SPM. Scannen - AVFoundation. Speicher – CoreData oder SQLite (wir werden darüber diskutieren, aber wir müssen offline arbeiten und resistent gegen Abstürze sein). Kryptographie – CryptoKit. Das Ticketformat ist QR, innerhalb der base64url-Nutzlast in Form von JSON. Validierung – Ed25519-Signaturüberprüfung und Regelüberprüfung (Ereignis, Datum, Zone, Wiederverwendung).

Was sollte das Ergebnis sein: 1) Swift Package (SPM) mit einer öffentlichen API, die mit unserer Anwendung verbunden werden kann. 2) Integrationsbeispiel (kleines Demo-Ziel oder Beispiel-App im Repository), nur um API-Aufrufe und Datenfluss zu zeigen. 3) Eine Reihe von Komponententests und grundlegenden Leistungstests für kritische Teile (Analyse, Validierung, Ereignisaufzeichnung).

Funktionale Anforderungen: 1) QR-Scanning über AVFoundation mit kontinuierlicher Stream-Unterstützung – Rückgabe des Ergebnisses in Form eines strukturierten Objekts (TicketId, EventId, ZoneId, IssuedAt, ValidFrom, ValidTo, Signatur). 2) Offline-Validierung – Überprüfung der Ed25519-Signatur mithilfe des öffentlichen Schlüssels der Veranstaltung, Überprüfung des Zeitfensters und der Zone, Schutz vor Ticket-Wiederverwendung auf einem Gerät (lokale Anti-Wiederverwendung). 3) Ereigniswarteschlange – alle Scanversuche und Entscheidungen (akzeptiert/abgelehnt + Grund) werden in den lokalen Speicher geschrieben und können später stapelweise hochgeladen werden. 4) Synchronisierung – eine SDK-Methode, die einen Rückruf/ein Protokoll akzeptiert, um ein Paket an unsere API zu senden (wir haben unsere eigene Netzwerkschicht, daher sollte das SDK keine bestimmte HTTP-Bibliothek vorschreiben). Es sollte eine Weiterleitung, Deduplizierung und Markierung erfolgreich gesendeter Ereignisse geben. 5) Schlüsselverwaltung – die Möglichkeit, eine Reihe von öffentlichen Schlüsseln zu aktualisierenPrivate Schlüssel (z. B. Schlüssel für mehrere EventIds) über die Konfiguration übertragen und lokal gespeichert. Es muss eine Version der Konfiguration und ein sicherer Ersatz vorhanden sein, ohne dass die Möglichkeit verloren geht, zuvor ausgestellte Tickets zu überprüfen.

Einschränkungen: 1) Beim Scannen ausschließlich offline arbeiten – zum Zeitpunkt des Scannens keine Netzwerkanfragen. 2) Sie können keine umfangreichen SDKs von Drittanbietern zum Scannen oder für Datenbanken verwenden – nur Standard-Apple-Frameworks oder sehr leichte Abhängigkeiten über SPM wie vereinbart. 3) Die öffentliche API des Pakets sollte minimal sein und in Kommentaren (SwiftDoc) dokumentiert sein. 4) Der Code muss mit iOS 15 und höher kompatibel sein, ohne private API.

Akzeptanzkriterien (messbar): 1) Die Validierung eines korrekten Tickets mit Signaturprüfung dauert auf dem iPhone 12 im Release-Build nicht länger als 30 ms, bei durchschnittlich 100 Durchläufen. 2) Das SDK weist mindestens 6 Fehlertypen mit eindeutigen Codes/Gründen korrekt zurück – falsche Signatur, abgelaufen, noch nicht aktiv, ungültige Zone, Wiederverwendung, unbekannte Ereignis-ID/unbekannter Schlüssel. 3) Nach 500 Offline-Scans sind alle Ereignisse in der Warteschlange verfügbar und gehen nicht verloren, wenn die Anwendung zum Beenden (Kill) gezwungen und dann neu gestartet wird. 4) Unit-Tests decken mindestens 70 % der Parsing-/Validierungs-/Warteschlangenlogik ab (unter Verwendung der Xcode-Abdeckung). 5) Die Beispielintegration demonstriert: Starten des Scanners, Abrufen des Ergebnisses, Aufruf von „Validate“, Aufzeichnen eines Ereignisses und Starten der Synchronisierung.

Phasen der Implementierung: 1) Klärung des Nutzlastformats und des Synchronisationsprotokolls, Fixierung des öffentlichen API SDK. 2) Kernimplementierung – Parser, kryptografische Überprüfung, Validierungsregeln. 3) Implementierung von Speicher und Ereigniswarteschlange + Deduplizierung. 4) Scannerintegration, Muster, Tests und Optimierung.

Wir stellen Folgendes bereit: QR-Payload-Beispiele, Ed25519-Testschlüssel, eine simulierte API-Spezifikation zum Hochladen von Ereignissen und eine Liste von Geschäftsregeln nach Zone/Zeit.