Place the call in the same code path that creates the account on your backend — after success, not before. Avoid passing the new user's email, ID, or signup channel as metadata; if you need a channel breakdown, emit a distinct event name instead.
▸ 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
// After your backend confirms the account is created:
func handleSignUpSuccess(method: SignUpMethod) {
switch method {
case .email: Respectlytics.track("account_created_email")
case .signInWithApple: Respectlytics.track("account_created_apple")
case .google: Respectlytics.track("account_created_google")
}
// Do NOT pass the new user's ID, email, or any other identifier.
}Place this call in the success branch of your sign-up API call — never before the backend confirms creation. Choose the event name based on the method; do not embed the method as a parameter.
✦ Privacy & implementation notes
Resist the urge to send `user_id` even "just in case". Once a user_id is in your analytics pipeline, every analyst will eventually use it for something — and you'll have built a per-user dataset by accident. Respectlytics's API rejects user IDs at the boundary: there's no path to accidentally re-introduce them later.
Distinct event names per signup method scale up to roughly 8–12 categories before they become unwieldy. Past that, bucket the long tail as `account_created_other`. Most apps have 3 (email + Google + Apple) — well below the threshold.
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
| Sign-up event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| New user_id stored | Yes (mandatory) | Yes (default) | Never |
| Email / phone as event property | Recommended | Common | Rejected by API |
| Signup method as event property | Recommended (login_method) | Common | Use distinct event_name |
| Acquisition source attribution | utm_* parameters | UTM tracking | Distinct event_name per source |
| Cross-device user identification | Yes (App Instance ID) | Yes (Identity Merging) | Out of scope (sessions, not users) |
| Resulting privacy posture | Per-user, identifiable | Per-user, identifiable | Session-scoped, no PII |
❓ Frequently asked questions
How do we measure activation without joining sign-up to first action?
By session. A session that emits both `account_created` and at least one of your "meaningful action" event names is an activated session. Compute the ratio across your session set — that's activation rate. You never need to join to a user table to get this number.
What about email vs Apple vs Google sign-up channels?
Use distinct event names: `account_created_email`, `account_created_apple`, `account_created_google`. The aggregation buckets them automatically. Embedding the method as a custom parameter is rejected by the API.
Can we still compute conversion from a marketing campaign?
Yes — use distinct event names per campaign source. If you have many campaigns, that taxonomy can balloon — keep it to your top 5–10 sources and bucket the rest as `account_created_other`. The trade-off: you give up long-tail per-campaign granularity in exchange for never storing UTM parameters or referrers.
What if our backend creates the account but the user abandons before the next screen — does the sign-up still get tracked?
Only if your call to `track` runs before the abandonment. Respectlytics's event queue is RAM-only — events not flushed before app force-quit are lost by design. For a signal as critical as sign-up, instrument the event right after the API call returns, not on the next screen.