▸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
Probabilistic install-attribution SDKs (AppsFlyer, Branch, Adjust) build fingerprints from model + OS + screen + locale + IP and match them across the install boundary to attribute the install to a specific ad click. Apple's SKAdNetwork and Google's Privacy Sandbox are the non-fingerprinting alternatives. Respectlytics is event analytics, not install attribution — but if you remove the install-attribution SDK from your app, the fingerprint surface goes with it.
Audit indicator: search your build for Locale.current, UIDevice.current, Build.MODEL, screen.width, Intl.DateTimeFormat().resolvedOptions().timeZone — these are the canonical fingerprint signals that SDKs reach for. If they appear in your shipped code only as part of your own UI logic (not as analytics-emission), you're clean.
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
| Fingerprint signals | Firebase Analytics | AppsFlyer | Branch | Respectlytics |
|---|---|---|---|---|
| Model + OS version | Yes | Yes | Yes | No |
| Screen size + density | Yes | Yes | Yes | No |
| Locale + timezone | Yes | Yes | Yes | No |
| Installed font list | No | Sometimes | Sometimes | No |
| IP + User-Agent combination | Yes | Yes | Yes | IP transient, UA standard |
| Probabilistic install attribution | No | Yes | Yes | No |
❓Frequently asked questions
Does the SDK report ANY device characteristics?
Two: the platform field (iOS / Android / RN / Flutter — already in the 5-field schema) and the inferred country code from IP lookup. That's it. Model, OS version, screen size, locale, timezone are not collected.
What about User-Agent — that has model + OS in it on Android.
The HTTP request to our API includes a standard User-Agent that identifies the SDK and platform but does NOT include device model, OS build number, or other fingerprinting signals. We use a fixed UA string per SDK version + platform combination.
How do we still see crash data by device model, then?
From your crash reporter (Sentry, Crashlytics, Bugsnag) — those tools legitimately need device model for crash dedup. Respectlytics is event analytics, not crash analytics; the two have different data needs and should be wired separately.
What about A/B-test variant assignment using fingerprint stability?
Don't. Variant assignment via fingerprinting is a re-identification anti-pattern. Use a randomised assignment within your client, encode the variant in the event_name (paywall_purchase_a, paywall_purchase_b), and compute conversion rates from session-grouped event counts. No fingerprint needed.