Fire the call after your authentication API returns success — not on form submit. Avoid passing the user ID, email, OAuth token, or session cookie. If you offer multiple login methods, encode the method in the event name.
▸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
enum LoginMethod { case email, apple, google }
func handleLoginSuccess(method: LoginMethod) {
switch method {
case .email: Respectlytics.track("login_email")
case .apple: Respectlytics.track("login_apple")
case .google: Respectlytics.track("login_google")
}
// Do NOT pass user_id, email, or session token.
}Place this call in the success closure of your auth API call — never on form submit.
✦Privacy & implementation notes
Most analytics SDKs use login as the moment to merge the anonymous pre-login session with the user's prior history. Respectlytics intentionally does not — the session ID rotates every two hours, so cross-session merging isn't a feature anyway. The trade-off: per-user funnel reconstruction lives in your billing system or user-event store, not in product analytics.
Fire after the authentication API returns success — not on submit. Submit-fire inflates login counts with failed credentials and abandoned typing. The few-hundred-millisecond delay is invisible to users and produces a clean metric.
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
| Login event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| user_id attached to all subsequent events | Yes (mandatory) | Yes | Never |
| Email / username as event property | Common | Common | Rejected by API |
| Login method as parameter | Recommended | Recommended | Use distinct event_name |
| Returning user vs new user signal | Per-user | Per-user | Use distinct event_name (login vs signup) |
| Session-grouped login rate by country / platform | Yes | Yes | Yes |
❓Frequently asked questions
How do we distinguish returning users from new sign-ups?
Use distinct event names — login and account_created (the signup event). A session that emits login is a returning-user session; one that emits account_created is a new-user session. The two never overlap in the same session by definition.
Can we still tell which login method was used?
Distinct event names per method: login_email, login_google, login_apple. Keep the taxonomy small — under 6 methods is comfortable; past that, bucket the long tail as login_other.
What about failed login attempts?
Fire a separate event: login_failed. Most teams don't need fine-grained failure reasons in product analytics — operational logs catch those. If you do, distinguish the high-level reasons by name (login_failed_credentials, login_failed_locked_account).
Where does the user ID still get used in our system, then?
In your authentication and authorization stack, your user database, your billing system, and your customer-support tools — the systems that legitimately need it. Just not in your product analytics. The hard line between "identifies the user" and "counts what happened" is what makes Respectlytics's posture defensible.