Fire on the framework's "screen became visible" callback: viewDidAppear on iOS, onResume on Android, useFocusEffect on RN, RouteObserver.didPush on Flutter. Don't pass the screen title, route path, or query parameters as metadata.
▸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 SwiftUI
extension View {
func trackScreen(_ name: String) -> some View {
self.onAppear { Respectlytics.track(name) }
}
}
// Use one distinct event_name per major screen:
ProductDetailView()
.trackScreen("screen_product_detail")For UIKit, override viewDidAppear(_:) and call Respectlytics.track("screen_*") there. Don't auto-track every view — pick 10–20 product-meaningful ones.
✦Privacy & implementation notes
A common failure mode: 200 distinct screen names accumulate over time as engineers add screens without coordinating. Maintain the screen taxonomy as an explicit document, not a String literal scattered through code. Respectlytics's funnel auto-discovery surfaces patterns across all event names — a clean taxonomy makes it useful; a noisy one makes it noise.
Screen views are typically 70%+ of total event volume in apps that auto-track. Most of that volume carries no decision-grade signal. Manually instrumenting 10–20 screens you actually care about is more useful than 200 auto-tracked ones, and keeps your analytics pipeline interpretable.
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
| Screen view event | Firebase Analytics | Mixpanel | Respectlytics |
|---|---|---|---|
| Screen name as parameter | Recommended (`screen_name`) | Recommended | Use distinct event_name |
| Screen class as parameter | Recommended | N/A | Use distinct event_name |
| Time-on-screen | Per-user | Per-user | Session-scoped derivation |
| Per-route parameter (`product_id`) | Recommended | Recommended | Forbidden (use bucketed event_name) |
| Screen sequence within session | Per-user | Per-user | Session-scoped |
❓Frequently asked questions
How do we handle screens with parameters like `/products/{id}`?
Bucket. Fire screen_product_detail for all product detail screens, regardless of which product. The product ID is content-routing data, not analytics data — your support and product-mgmt tools have it. If you absolutely need a top-N breakdown (your 10 most-viewed products), encode those into distinct event names by name; bucket the long tail.
Should we track every screen, or just the major ones?
Just the major ones. "Auto-tracking every screen" sounds comprehensive but produces a flood of events that drown the high-signal funnel events. Pick 10–20 product-meaningful screens; instrument those by hand.
How do we measure time-on-screen?
Compute it server-side from consecutive timestamped events in the same session. The interval between screen_view_a and screen_view_b is the time spent on a. Don't store duration as an event property — Respectlytics rejects parameters.
What about modals and sheets?
Track them as their own events with distinct names: modal_settings_opened. Don't conflate modal-presentation with screen-view; they answer different product questions and obey different lifecycle rules.