Fire one event per step: password_reset_requested (after the user submits their email and the backend accepts it), password_reset_completed (after the new password is set successfully). Don't pass email, token, or user ID — your auth backend has all of them with the right access controls.
▸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
func requestPasswordReset(email: String) {
api.requestPasswordReset(email: email) { result in
switch result {
case .success:
Respectlytics.track("password_reset_requested")
case .failure:
Respectlytics.track("password_reset_request_failed")
}
}
}
func completePasswordReset() {
Respectlytics.track("password_reset_completed")
}The email argument is a credential identifier; it stays in api, never in track. Failure event is useful for rate-limit / deliverability diagnosis.
✦Privacy & implementation notes
The reset token in the email link is a one-time credential that grants account access. Treat it like any other secret: it never leaves your auth backend, never appears in analytics events, never gets logged. Respectlytics's API rejects extra fields, so even an accidental include fails fast.
Password reset spans two sessions by design — the request session and the completion session. Single-session funnel queries will miss most completions. Use the rate of password_reset_completed events relative to password_reset_requested over a 24-hour window; the math is country- and platform-bucketed.
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
| Password reset event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Email or username as event property | Common | Common | Rejected by API |
| Reset token stored | Possible | Possible | Forbidden (credential) |
| Per-user reset frequency | Yes | Yes | Out of scope |
| Request → completion funnel | Per-user | Per-user | Session-scoped |
| Rate-limit + abuse detection | Per-user heuristic | Per-user heuristic | Country + session aggregate |
❓Frequently asked questions
How do we measure password-reset completion rate without per-user join?
Per-session. A session that emits both password_reset_requested and password_reset_completed is a completing session. The bigger source of drop-off — request → email-clicked — happens between two distinct sessions (the user closes the app, opens the email, taps the link). For that, fire a separate password_reset_link_opened when the deep link lands; the rate from request to link-open is your email-deliverability signal.
What about abuse detection (someone spamming reset requests)?
That's a security concern, not a product analytics concern — handle it in your auth backend with proper rate-limiting and IP-based heuristics. Respectlytics's product-analytics events are not the right surface for abuse-detection signals; abuse logs may legitimately include IPs while product analytics never persists them.
Should we differentiate reset reasons (forgot password vs forced rotation)?
If you have multiple reset flows, distinct event names: password_reset_requested_user_initiated, password_reset_requested_forced_rotation. Most apps have one flow.
What about the actual password change while logged in?
Different event entirely — password_changed. It's a settings-screen action, not a recovery flow. Don't conflate them; their funnels and rates are unrelated.