Replace Firebase Analytics: RAM-only events

Q: What's the actual flush cadence?

30 seconds by default, plus a flush on `applicationDidEnterBackground` (iOS) / `onPause` (Android). Most events reach the network within seconds of being fired.

▸Example Firebase Analytics call (the "before")

swift Respectlytics

import FirebaseAnalytics

// Default Firebase event with rich per-user metadata:
Analytics.logEvent("purchase", parameters: [
    "value": price,
    "currency": "USD",
    "transaction_id": UUID().uuidString,
    "user_id": userId,
])

Most analytics SDKs back the unsent event queue with SQLite or UserDefaults / SharedPreferences — so a phone that's been confiscated, jailbroken, or restored from backup still contains analytics state. Respectlytics's queue is RAM-only, flushed on a 30-second timer; unsent events on force-quit are lost by design, in exchange for zero on-device forensic surface.

☑Remove Firebase Analytics cleanly

1
Remove pod 'Firebase/Analytics' from Podfile (and any Firebase/Core pulled by it that isn't needed elsewhere)
2
Remove implementation 'com.google.firebase:firebase-analytics-ktx' from build.gradle.kts
3
Remove @react-native-firebase/analytics from package.json
4
Remove firebase_analytics: from pubspec.yaml
5
Remove FirebaseApp.configure() and Analytics.logEvent call sites — replace with Respectlytics.configure() and Respectlytics.track("event_name")
6
Delete the GoogleService-Info.plist and google-services.json if no other Firebase product remains in the app
7
Run ./gradlew :app:dependencies and confirm play-services-ads-identifier is no longer in the runtime classpath

⇋Firebase Analytics vs Respectlytics — ram-only event queue

	Firebase Analytics	Respectlytics
Event queue persistence	SQLite / UserDefaults / SharedPreferences	In-memory ring buffer
Disk usage for analytics	0.5–10 MB typical	0 bytes
Forensic data on jailbroken / rooted devices	Persistent identifiers + queued events	None
Survives force-quit before flush	Yes	No (events lost — by design)

❓Frequently asked questions

Doesn't this reduce data quality?

Marginally — typical force-quit-before-flush event loss is 0.5–2% depending on platform. For aggregate metrics (funnel rates, feature adoption, release deltas) this is invisible. For per-event reconciliation it would be a problem, but per-event reconciliation isn't a use case Respectlytics supports.

What's the actual flush cadence?

30 seconds by default, plus a flush on applicationDidEnterBackground (iOS) / onPause (Android). Most events reach the network within seconds of being fired.

Is this safe for crash analytics?

Crash analytics is a separate concern — use Sentry, Crashlytics, or Bugsnag (with their own crash-aware queues). Respectlytics is product analytics; crash data has different recoverability requirements and lives in different tools.

Why is this a privacy feature?

Devices that are jailbroken, rooted, restored from backup, or forensically imaged routinely surface analytics artifacts — distinct_ids, queued events, user properties — that survive uninstall in some cases. RAM-only storage moves the dump-recovery surface to zero.

⇢Related migration guides

Replace Firebase Analytics with a RAM-only event queue