Fire the call in the success branch of your post-OAuth handoff — after your backend verifies the provider's token and creates / fetches the user record. Don't pass any of the provider's payload. Distinct event names per provider handle the segmentation.
▸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
import AuthenticationServices
class SocialLoginCoordinator: NSObject, ASAuthorizationControllerDelegate {
func authorizationController(controller: ASAuthorizationController,
didCompleteWithAuthorization auth: ASAuthorization) {
// Provider's user ID and tokens stay in your auth backend.
if auth.credential is ASAuthorizationAppleIDCredential {
api.exchangeForSession(auth.credential) { result in
if case .success = result {
Respectlytics.track("login_apple")
}
}
}
}
}Sign in with Apple's hide-my-email relay doesn't change the analytics event you fire — login_apple regardless of whether the email is real or relayed.
✦Privacy & implementation notes
OAuth tokens, refresh tokens, and provider account IDs are credentials. They belong in your authentication code path with proper access controls — not in your product analytics pipeline. Respectlytics's API rejects them at the boundary. If a teammate adds them by reflex, the integration test fails.
Don't write track('login', { provider: 'google' }) — Respectlytics rejects the parameter. Instead write track('login_google'). Aggregation buckets it automatically; the funnel auto-discovery picks it up; the breakdown is queryable without any custom configuration.
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
| Social login event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Provider account ID stored | Yes | Yes | Never |
| Provider email / name stored | Common | Common | Never |
| OAuth token / refresh token | Yes (server-side) | Yes (server-side) | Never |
| Provider as event parameter | Recommended | Recommended | Use distinct event_name |
| Per-provider login rate | Yes | Yes | Yes (default aggregation) |
❓Frequently asked questions
What event name should we use per provider?
login_google, login_apple, login_facebook, etc. — one per provider you support. Most apps have 2–3 providers; that's a comfortable taxonomy size. The aggregation gives you per-provider login rate without storing provider account IDs.
Should we track the difference between first-time social login and returning?
Yes, with distinct event names: account_created_google (first-time) and login_google (returning). The two answer different product questions — acquisition vs retention — and conflating them blurs both.
What about Sign in with Apple's hide-my-email relay?
Doesn't change anything from Respectlytics's perspective — the event you fire is login_apple regardless of whether the user used a real email or the relay. Apple's hide-my-email is between the user and your auth backend; Respectlytics wasn't going to receive an email anyway.
Should we instrument social login button views?
Useful for funnel diagnosis. login_screen_viewed + login_google gives you the per-button conversion rate. Don't bother with hover / focus events on mobile — they don't carry signal.