iOS SDK для офлайн-збору телеметрії із шифруванням, фоновою доставкою та інтеграцією в існуючу програму

Вихідна ситуація - є діюча iOS-додаток для польових співробітників (iOS 15-17, Swift, UIKit + частина екранів на SwiftUI). Користувач може працювати без зв'язку, а дані про використання та техпроцес (події, таймінги, помилки, параметри сесії) повинні гарантовано доставлятися на наш API, коли зв'язок з'явиться. Зараз телеметрія відправляється безпосередньо через URLSession і регулярно втрачається через офлайн, вбивство програми та конкуренцію фонових завдань. Також з'явилися вимоги щодо зберігання чутливих даних на пристрої та контролю обсягу.

Завдання - розробити та впровадити модульний iOS SDK (як Swift Package) для надійного збору та доставки телеметрії.

Технічне середовище та обмеження – Swift 5.9+, Xcode 15+, iOS 15+. Заборонено підключати важкі аналітичні SDK (Firebase/Amplitude тощо). Не можна збирати рекламні ідентифікатори та робити трекінг користувача. Дані повинні зберігатися локально обмежений час та обсяг. Серверна частина вже є - REST endpoint /v1/telemetry/batch приймає gzip JSON, авторизація через існуючий access token із програми (надамо протокол для отримання токена). Формат події фіксований - id (UUID), ts (ISO8601), type (рядок), payload (словник), sessionId.

Що потрібно зробити -
1) Спроектувати архітектуру SDK - публічне API для логування подій із додатку, внутрішня черга, сховище, доставка, ретра.
2) Локальне сховище черги – вибрати та реалізувати (Core Data або SQLite/GRDB без зовнішніх сервісів). Вимоги - атомарність, стійкість до кріш, можливість вибірки батч, дедуплікація по id.
3) Шифрування на пристрої - зберігати payload в зашифрованому вигляді (AES-GCM), ключ зберігати в Keychain, підтримати ротацію ключа без втрати черги.
4) Доставка - відправка батчів з gzip, обмеження розміру батча (наприклад 256 КБ) та загального розміру черги (наприклад 20 МБ) з політикою витіснення (drop oldest). Ретраї з експонентною затримкою, джиттером та обліком кодів відповіді сервера (429/5xx). Поважати режим Low Power Mode.
5) Фонові сценарії - коректна робота під час догляду в background і вбивства докладання. Використовувати BGTaskScheduler для періодичної доставки, а також надсилання при появі мережі. Не порушувати обмеження iOS щодо фонової активності.
6) Спостереження мережі - Network.framework (NWPathMonitor) для тригера доставки при відновленні з'єднання.
7) Інтеграція в додаток – замінити поточну пряму відправку на SDK у 2-3 точках логування (наприклад, помилки, події навігації, системні таймінги). Передбачити thread-safe дзвінки з різних потоків.
8) Тестування – покрити ключові частини unit-тестами (черга, шифрування, формування батча, політики ретраю). Додати мінімальні integration-тести на сервер МОК (URLProtocol) і перевірку сценарію офлайн-онлайн.

Конкретний результат - репозиторій із Swift Package (джерела, тести), прикладом використання та інструкцією інтеграції в існуючу програму, плюс MR/PR із підключенням пакета та заміною старих викликів відправки.

Вимірювані критерії приймання -
- При включеному Airplane Mode події пишуться в чергу і не губляться після перезапуску програми; після відключення Airplane Mode усі накопичені події доставляються на endpoint максимум за 15 хвилин при активному використанні програми.
- Черга обмежена за обсягом 20 МБ - при перевищенні видаляються найстаріші події, програма не падає і не зависає.
- Payload на диску не зберігається у відкритому вигляді - перевірка через інспекцію файлів контейнера (рядки з JSON не читаються як plain text).
- SDK не використовує заборонені сторонні аналітичні сервіси і не вимагає зайвих дозволів.
- Доставка виконується батчами з gzip, коректно обробляє 429 та 5xx (ретраї), 4xx крім 429 не ретраються.
- Unit-тести запускаються в CI локально (xcodebuild test) і покривають щонайменше 60% коду модуля доставки/черги.

Додатково можна запропонувати оптимізацію формату (наприклад, компактний JSON/CBOR), але підсумковий wire-формат повинен залишитися JSON, як зараз на сервері.