▸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
The most common transition pain when adopting Respectlytics is the loss of per-user retention curves. The product question "are users coming back?" can still be answered (via session-cohort rates) but the "who" can't be. Teams that need per-user retention for revenue or compliance reasons typically resolve this by querying their billing / account system instead — where the data legitimately lives.
Session-ID rotation forces a discipline most analytics setups would benefit from anyway: putting per-user metrics in the system that owns the user (your account / billing system) and product engagement in the system that observes events (your analytics). The boundary is a feature.
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
| Session / user identification | Firebase Analytics | Mixpanel | Amplitude | Respectlytics |
|---|---|---|---|---|
| Persistent device-level ID | app_instance_id (UUID, persistent) | distinct_id | device_id | None |
| User-level ID after login | user_id | distinct_id (merged) | user_id | None |
| Survives app restart | Yes | Yes | Yes | No (new session_id) |
| Survives app reinstall | Yes (often, via FCM token) | No | No | No |
| Cross-app linkage on same device | Yes (via IDFA/AAID) | Optional | Yes | No |
| Joinable within one session window | Yes | Yes | Yes | Yes (within 2h) |
❓Frequently asked questions
How is the 2-hour rotation triggered?
Two ways: (1) on every app launch, the SDK generates a fresh session_id; (2) within a foreground session, if no events have been emitted for 120 minutes, the next event emits with a new session_id. Both are automatic — no application code changes the rotation.
What can you compute from a single session_id within its lifetime?
Within one session, you have an ordered list of (event_name, timestamp) pairs that all share the session_id. That's enough for funnel analysis, step-by-step conversion, time-on-task, and feature-sequence derivations. What you can't compute: per-user retention curves, per-user lifetime value, or anything that needs to span sessions for the same user.
How do we measure D1 / D7 retention without a persistent ID?
Session-cohort retention. "Of the sessions that emitted onboarding_complete on day N, what percent of sessions on day N+1 appear at all?" — bucketed by country and platform. The metric is approximately what "D1 retention" measures with cleaner identity, and it's actionable for the same product decisions.
Why 2 hours specifically?
The choice balances analytical utility (a single user's continuous app usage typically fits in a 2-hour foreground session) with privacy minimisation (longer windows allow more cross-event correlation per user). It's a trade-off; 30 minutes was deemed too aggressive (would split natural sessions), 4 hours was considered too lenient. The 2-hour mark is the current value and may be tuned in future major versions with notice.