Respectlytics Respect lytics
Menu
Swift (iOS) Zero device storage for analytics

How to add Swift (iOS) analytics with zero device storage

Most analytics SDKs persist event data to disk — typically UserDefaults on iOS, SharedPreferences on Android, AsyncStorage on React Native, or files in the app sandbox. The reasoning is delivery resilience: events should survive a crash. Respectlytics's Swift (iOS) SDK takes the opposite trade-off: zero bytes written to disk for analytics. The event queue is RAM-only. Below: what this means operationally, the deliberate trade-off, and the FAQ.

Install the Swift (iOS) SDK

swift Respectlytics
// 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)

swift Respectlytics
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 analyticsFirebase AnalyticsMixpanelAmplitudeRespectlytics
Persistent event queue on diskYes (sqlite)Yes (sqlite)Yes (sqlite)No (RAM only)
User-defaults / preferences usageYes (instance ID)Yes (distinct_id)Yes (device ID)No
Survives force-quit before flushYesYesYesNo (events lost — by design)
Disk space used0.5–5 MB typical1–10 MB1–5 MB0 bytes
Forensic data on devicePersistent identifiers, queuesSameSameNone

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).

Related guides

Track what matters. Collect nothing you don't.

Five-field event schema, RAM-only event queue, no IDFA, no AAID, no persistent user IDs. Helps developers avoid collecting personal data in the first place.