Treat each onboarding step as its own event name (onboarding_step_1_complete, onboarding_step_2_complete, …, onboarding_complete). Funnel rates are then session-grouped event-name counts — no per-user attribution required. The pattern below is what we recommend for most Swift (iOS) apps.
▸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.
▸Track the event in Swift (iOS)
import Respectlytics
// One step:
Respectlytics.track("onboarding_step_1_complete")
// At the very end of the flow:
Respectlytics.track("onboarding_complete")
// SwiftUI example — fire on view dismissal:
struct OnboardingFinalStep: View {
var body: some View {
Button("Get started") {
Respectlytics.track("onboarding_complete")
navigateToHome()
}
}
}Each step is its own event name. onboarding_complete is a sentinel for the final step. Avoid one event with a step parameter — the API rejects parameters.
✦Privacy & implementation notes
Common mistake: emitting one onboarding_step_completed event with {step: 1} as a parameter. Respectlytics's API rejects that with a 400. Instead, emit onboarding_step_1_complete, onboarding_step_2_complete, etc. as distinct event names — Respectlytics's funnel auto-discovery picks them up without any manual configuration.
The most frequent unintentional PII leak is sending the user's email or phone number as event metadata ("so we can re-engage them later"). The API returns a 400 with the offending field name — so this fails on the first integration test, not after months of unnoticed silent collection.
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
| Onboarding completion event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Per-user identity | app_instance_id | distinct_id (if signed in) | Never |
| Step metadata as parameters | Up to 25 params per event | Up to 250 properties | Use distinct event_name per step |
| Email / signup_method as event property | Recommended | Recommended | Rejected by API |
| Session-level funnel computation | Yes (session-scoped tables) | Yes (insights builder) | Yes (default) |
| What you store about who finished | a lot | a lot | event_name + session_id (rotated) + timestamp + platform + country |
❓Frequently asked questions
Why use distinct event_names per step instead of one event with a step parameter?
Two reasons. First, Respectlytics's API rejects custom parameters — you have five fields, period. Second, distinct event names compose better with the automatic funnel-discovery feature: any monotonic sequence of event names in a session is a candidate funnel, no manual configuration required.
How do we segment onboarding completion by acquisition source?
If your acquisition source is one of N values (organic, paid_search, referral, …), emit it as part of the event name: onboarding_complete_organic, onboarding_complete_paid_search, etc. The aggregation engine groups them. Avoid composing freeform combinations — keep your taxonomy short.
What about completion time / duration?
Two timestamped events in the same session implicitly carry duration — compute it server-side in your dashboard, not as an event property. The raw timestamps stay on Respectlytics; the duration metric is your derivation.
Should we track each step view or just step completions?
Just completions, in nearly every case. "Saw step 3" with no completion is rarely actionable — a session that has onboarding_step_2_complete but no onboarding_step_3_complete already tells you they got stuck.