iOS SDK for offline telemetry collection with encryption, background delivery and integration into an existing application

Initial situation - there is a working iOS application for field employees (iOS 15-17, Swift, UIKit + some screens on SwiftUI). The user can work without connection, and data about usage and technical process (events, timings, errors, session parameters) must be guaranteed to be delivered to our API when the connection appears. Currently, telemetry is sent directly via URLSession and is regularly lost due to offline, application killing, and background task competition. There are also requirements for storing sensitive data on the device and controlling volume.

The task is to develop and implement a modular iOS SDK (like Swift Package) for reliable collection and delivery of telemetry.

Technical environment and limitations - Swift 5.9+, Xcode 15+, iOS 15+. It is prohibited to connect heavy analytical SDKs (Firebase/Amplitude, etc.). You cannot collect advertising identifiers and track the user. Data must be stored locally for a limited time and volume. The server part is already there - REST endpoint /v1/telemetry/batch accepts gzip JSON, authorization through an existing access token from the application (we will provide a protocol for receiving the token). The event format is fixed - id (UUID), ts (ISO8601), type (string), payload (dictionary), sessionId.

What to do -
1) Design an SDK architecture - a public API for logging events from the application, internal queue, storage, delivery, retrays.
2) Local queue storage - select and implement (Core Data or SQLite/GRDB without external services). Requirements: atomicity, crash resistance, ability to sample in batches, deduplication by id.
3) Encryption on the device - store payload in encrypted form (AES-GCM), store the key in Keychain, support key rotation without losing the queue.
4) Delivery - sending batches with gzip, limiting the batch size (for example, 256 KB) and the total queue size (for example, 20 MB) with a drop oldest policy. Retrays with exponential delay, jitter and taking into account server response codes (429/5xx). Respect Low Power Mode.
5) Background scripts - work correctly when going into the background and killing the application. Use BGTaskScheduler for periodic delivery, as well as sending when the network becomes available. Do not violate iOS restrictions on background activity.
6) Network monitoring - Network.framework (NWPathMonitor) for delivery trigger when connection is restored.
7) Integration into the application - replace the current direct sending with the SDK at 2-3 logging points (for example errors, navigation events, system timings). Provide thread-safe calls from different threads.
8) Testing - cover key parts with unit tests (queuing, encryption, batch formation, retray policies). Add minimal integration tests to the mock server (URLProtocol) and offline-online script testing.

The specific result is a repository with Swift Package (sources, tests), an example of use and instructions for integration into an existing application, plus MR/PR with connecting the package and replacing old send calls.

Measurable acceptance criteria -
- When Airplane Mode is enabled, events are written to the queue and are not lost after the application is restarted; after Airplane Mode is disabled, all accumulated events are delivered to the endpoint in a maximum of 15 minutes when the application is actively used.
- The queue is limited in size to 20 MB - if it is exceeded, the oldest events are deleted, the application does not crash or freeze.
- Payload on disk is not stored in clear text - verification through inspection of container files (strings from JSON are not read as plain text).
- The SDK does not use prohibited third-party analytical services and does not request unnecessary permissions.
- Delivery is carried out in batches with gzip, correctly processes 429 and 5xx (retrays), 4xx except 429 are not retrailed.
- Unit tests are run locally in CI (xcodebuild test) and cover at least 60% of the delivery/queue module code.

Additionally, you can offer format optimization (for example, compact JSON/CBOR), but the final wire format should remain JSON, as it is now on the server.