▸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 5-field rejection at the API boundary is the single most useful feature for keeping privacy posture consistent over time. Most teams accidentally drift toward more PII as engineers reflexively add fields to events for debugging. Respectlytics's API gives you a 400 in CI on the first commit that adds an extra field — the bad pattern fails fast.
The 5 stored fields map cleanly to the analytical dimensions most product teams actually use: WHAT happened (event_name), WHEN (timestamp), WHERE (platform + country), and the session-grouping key (session_id). What's missing is per-user identity — and that's the design point.
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
| Event payload | Firebase Analytics | Mixpanel | Amplitude | Respectlytics |
|---|---|---|---|---|
| Custom event properties allowed | Up to 25 params/event | Up to 250 properties | Up to ~100 | Zero (rejected) |
| User properties | Up to 25 | Unlimited (people profiles) | Unlimited | N/A |
| Stored per event | Variable | Variable | Variable | Exactly 5 fields |
| API enforcement of schema | Lenient | Lenient | Lenient | Strict (rejects extras) |
| Per-user state computable | Yes | Yes | Yes | No (use account system) |
❓Frequently asked questions
How do we segment events without custom properties?
By using distinct event_names. Instead of track('purchase', { product: 'gold_pack' }), fire track('purchase_gold_pack'). The aggregation buckets event_names automatically; no manual configuration. Keep your taxonomy under ~50 distinct names per matrix axis to stay navigable.
What about timestamps with sub-second precision?
The timestamp field is millisecond-precision UTC. That's enough for session-grouping and aggregate analysis. For higher-precision use cases (e.g., performance monitoring), use a different tool — APM is not Respectlytics's job.
Can we attach internal user IDs even if they're never returned to the user?
No. The API rejects extra fields outright with a 400. The rejection is the feature: there's no version of "send the user_id to analytics for internal use" that doesn't eventually leak through dashboards, exports, support tools, etc. The 5-field boundary keeps that surface zero.
What if we need a sixth field for legitimate reasons?
The 5-field constraint is architectural and won't change. But the constraint pushes you to a different solution: (a) encode the variant in the event_name, (b) keep per-user state in your own systems and don't mirror it to analytics, or (c) use a different tool for the use case. Most product teams find (a) or (b) sufficient.