▸Install the Swift (iOS) SDK
// Package.swift
dependencies: [
.package(url: "https://github.com/respectlytics/respectlytics-swift.git", from: "3.0.0")
]
// Or via Xcode → File → Add Packages → paste the URL above.
The SDK ships only via Swift Package Manager. CocoaPods and Carthage are not published — fewer integration paths means fewer surfaces to keep audited.
▸Initialize Respectlytics in Swift (iOS)
import Respectlytics
@main
struct MyApp: App {
init() {
Respectlytics.configure(appKey: "<YOUR_APP_KEY>")
}
var body: some Scene { WindowGroup { ContentView() } }
}
Call configure once at app launch — typically in your App struct's init. No Info.plist keys are required: the SDK does not call ATTrackingManager and does not request the IDFA, so NSUserTrackingUsageDescription should NOT be added.
✦Privacy & implementation notes
iOS keychain dumps and Android file-system dumps from rooted/jailbroken devices routinely surface analytics artifacts: distinct_ids, device_ids, queued events sometimes containing PII. The typical retention is months to years because most analytics SDKs don't expose a clear-data API and users don't think to clear analytics state. Respectlytics's RAM-only approach moves the dump-recovery surface to zero.
The 30-second flush cadence + RAM-only queue makes Respectlytics well-suited to apps with strict device-data policies: telehealth, fintech, and government apps where forensic recoverability of analytics data is itself a documented risk. The trade-off — losing events on force-quit — is an acceptable cost in those contexts.
Apple rejected approximately 3% of apps in 2024 for incorrectly omitting NSUserTrackingUsageDescription when ATT was required by the SDKs they shipped. Respectlytics doesn't trigger ATT. The corollary is also true: do not add the key on Respectlytics's account — its presence implies you track across apps, even if your code never calls requestTrackingAuthorization.
Internally the Swift SDK uses Swift Concurrency: events are queued in an actor-isolated buffer (RAM-only), flushed on a 30-second timer and on UIApplication.willResignActiveNotification. Force-quit before flush drops queued events — by design. There is no UserDefaults or file backing.
⇋How this compares to other analytics SDKs
| Device storage for analytics | Firebase Analytics | Mixpanel | Amplitude | Respectlytics |
|---|---|---|---|---|
| Persistent event queue on disk | Yes (sqlite) | Yes (sqlite) | Yes (sqlite) | No (RAM only) |
| User-defaults / preferences usage | Yes (instance ID) | Yes (distinct_id) | Yes (device ID) | No |
| Survives force-quit before flush | Yes | Yes | Yes | No (events lost — by design) |
| Disk space used | 0.5–5 MB typical | 1–10 MB | 1–5 MB | 0 bytes |
| Forensic data on device | Persistent identifiers, queues | Same | Same | None |
❓Frequently asked questions
What happens if the app is force-quit before events are flushed?
Those events are lost — and we treat that as the correct behaviour, not a bug. A handful of dropped events is the price of a privacy-by-architecture posture: nothing on disk means there's nothing on the device for an attacker, a forensic tool, or an unintended share to recover. Empirically, force-quit between visible activity and the SDK's flush interval (default 30 seconds) is a small fraction of all events.
Doesn't this reduce data quality?
Marginally. The trade-off is real — most analytics SDKs would rather lose 0% of events than 1%. We accept the 1% loss in exchange for eliminating an entire category of forensic and supply-chain risk. For aggregate analytics — funnel rates, feature adoption, release deltas — 1% loss is not material. For individual user reconstruction, it would be — but that use case doesn't apply to Respectlytics anyway.
What about the SDK's own configuration / app key?
The app key is in your bundled app code (it's a build-time constant, not a secret). The SDK doesn't write it back to disk. The session_id lives in process memory only and rotates.
Does this affect debug builds or local testing?
No — the SDK behaves identically in debug. If you want to introspect the queue during development, the SDK exposes a debug API that prints queued events to the console (still no file writes).