▸Install the React Native SDK
npm install @respectlytics/react-native
# or
yarn add @respectlytics/react-nativeJavaScript-only — no native modules, no auto-linking, no New Architecture migration concerns. Bundle size: ~14KB minified+gzipped. Works in any Expo project (managed or bare) without expo prebuild.
▸Initialize Respectlytics in React Native
// App.tsx (or App.js)
import { useEffect } from 'react';
import Respectlytics from '@respectlytics/react-native';
export default function App() {
useEffect(() => {
Respectlytics.configure({ appKey: '<YOUR_APP_KEY>' });
}, []);
return <YourApp />;
}Initialize once in your top-level component. No native config; no Info.plist or AndroidManifest changes. The SDK is Hermes- and JSC-compatible.
✦Privacy & implementation notes
iOS keychain dumps and Android file-system dumps from rooted/jailbroken devices routinely surface analytics artifacts: distinct_ids, device_ids, queued events sometimes containing PII. The typical retention is months to years because most analytics SDKs don't expose a clear-data API and users don't think to clear analytics state. Respectlytics's RAM-only approach moves the dump-recovery surface to zero.
The 30-second flush cadence + RAM-only queue makes Respectlytics well-suited to apps with strict device-data policies: telehealth, fintech, and government apps where forensic recoverability of analytics data is itself a documented risk. The trade-off — losing events on force-quit — is an acceptable cost in those contexts.
The React Native SDK is JavaScript-only — no Objective-C/Swift bridging on iOS, no Java/Kotlin bridging on Android. Side effects: no react-native link, no auto-linking, no New Architecture migration concerns, no platform-channel exception surfaces. Trade-off: no access to platform-only metadata (which we don't want to collect anyway).
Works in Expo managed workflow without expo prebuild. No config plugin is required. EAS Build users: nothing to configure. This is the smoothest integration path on RN — most analytics SDKs require ejecting from managed.
⇋How this compares to other analytics SDKs
| Device storage for analytics | Firebase Analytics | Mixpanel | Amplitude | Respectlytics |
|---|---|---|---|---|
| Persistent event queue on disk | Yes (sqlite) | Yes (sqlite) | Yes (sqlite) | No (RAM only) |
| User-defaults / preferences usage | Yes (instance ID) | Yes (distinct_id) | Yes (device ID) | No |
| Survives force-quit before flush | Yes | Yes | Yes | No (events lost — by design) |
| Disk space used | 0.5–5 MB typical | 1–10 MB | 1–5 MB | 0 bytes |
| Forensic data on device | Persistent identifiers, queues | Same | Same | None |
❓Frequently asked questions
What happens if the app is force-quit before events are flushed?
Those events are lost — and we treat that as the correct behaviour, not a bug. A handful of dropped events is the price of a privacy-by-architecture posture: nothing on disk means there's nothing on the device for an attacker, a forensic tool, or an unintended share to recover. Empirically, force-quit between visible activity and the SDK's flush interval (default 30 seconds) is a small fraction of all events.
Doesn't this reduce data quality?
Marginally. The trade-off is real — most analytics SDKs would rather lose 0% of events than 1%. We accept the 1% loss in exchange for eliminating an entire category of forensic and supply-chain risk. For aggregate analytics — funnel rates, feature adoption, release deltas — 1% loss is not material. For individual user reconstruction, it would be — but that use case doesn't apply to Respectlytics anyway.
What about the SDK's own configuration / app key?
The app key is in your bundled app code (it's a build-time constant, not a secret). The SDK doesn't write it back to disk. The session_id lives in process memory only and rotates.
Does this affect debug builds or local testing?
No — the SDK behaves identically in debug. If you want to introspect the queue during development, the SDK exposes a debug API that prints queued events to the console (still no file writes).