Вихідна ситуація: у нас є iOS-програма для контролю доступу на заходи. Наразі перевірка квитків йде через сервер, через що на майданчиках із поганим інтернетом виникає черга. Потрібно зробити внутрішній iOS SDK-модуль, який дозволить валідувати квитки повністю офлайн та синхронізувати результати пізніше. Технічне середовище та предметна область: iOS 15+, Swift 5.9+, Xcode 15+, SPM. Сканування – AVFoundation. Зберігання - CoreData або SQLite (обговоримо, але потрібна робота офлайн та стійкість до падінь). Криптографія - CryptoKit. Формат квитка - QR, всередині base64url payload у вигляді JSON. Валідація – перевірка підпису Ed25519 та перевірка правил (захід, дата, зона, повторне використання). Що має вийти в результаті: 1) Swift Package (SPM) з публічним API, який можна підключити до нашої програми. 2) Приклад інтеграції (маленький demo target або sample app всередині репозиторію) тільки щоб показати виклики API та потік даних. 3) Набір unit-тестів та базові performance-тести для критичних частин (парсинг, валідація, запис подій). Функціональні вимоги: 1) Сканування QR через AVFoundation з підтримкою безперервного потоку - повернення результату у вигляді структурованого об'єкта (ticketId, eventId, zoneId, issuedAt, validFrom, validTo, signature). 2) Офлайн-валідація – перевірка Ed25519 підпису за публічним ключем заходу, перевірка тимчасового вікна та зони, захист від повторного використання квитка на одному пристрої (локальний анти-реюз). 3) Черга подій - усі спроби сканування та рішення (accepted/denied + причина) пишуться у локальне сховище і можуть бути вивантажені пізніше пачками. 4) Синхронізація – метод SDK, який приймає callback/протокол для відправки пачки на наш API (мережевий шар у нас свій, тому SDK не повинен нав'язувати конкретну HTTP-бібліотеку). Повинні бути ретраї, дедуплікація та позначка успішно відправлених подій. 5) Управління ключами – можливість оновити набір публособистих ключів (наприклад, ключі для декількох eventId) через конфіг і зберегти локально. Має бути версія конфігурації та безпечна заміна без втрати можливості перевіряти раніше видані квитки. Обмеження: 1) Робота суворо офлайн при скануванні - жодних мережевих запитів під час перевірки. 2) Не можна використовувати сторонні важкі SDK для сканування або бази даних - тільки стандартні Apple фреймворки або дуже легкі залежності через SPM за погодженням. 3) Публічне API пакета має бути мінімальним та документованим у коментарях (SwiftDoc). 4) Код повинен бути сумісний з iOS 15 та новішим, без private API. Критерії приймання (вимірні): 1) Валідація коректного квитка з перевіркою підпису виконується не довше 30 мс на iPhone 12 у релізному збиранні в середньому по 100 прогонів. 2) SDK коректно відхиляє щонайменше 6 типів помилок зі зрозумілими кодами/причинами - невірний підпис, прострочений, ще активний, неправильна зона, повторне використання, невідомий eventId/ключ. 3) Після 500 сканувань офлайн всі події доступні в черзі і не губляться при примусовому завершенні програми (kill) та наступному запуску. 4) Unit-тестами покрито не менше 70% логіки парсингу/валідації/черги (можна за Xcode coverage). 5) Sample інтеграція демонструє: старт сканера, отримання результату, виклик validate, запис події та запуск sync. Етапи виконання: 1) Уточнення формату payload та протоколу синхронізації, фіксація публічного API SDK. 2) Реалізація ядра – парсер, криптоперевірка, правила валідації. 3) Реалізація сховища та черги подій + дедуплікація. 4) Інтеграція сканера, sample, тести та оптимізація. Ми надамо: приклади QR payload, тестові Ed25519 ключі, мок-специфікацію API для вивантаження подій та список бізнес-правил за зонами/часом.