▸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
Apple's review team flags ~3% of apps for incorrectly omitting NSUserTrackingUsageDescription when their SDKs need ATT. The mirror case is also true: adding the key when your code does not call ATTrackingManager is a flag in the other direction. Don't add it on Respectlytics's account.
Most teams arriving here are migrating from a Firebase-style integration where IDFA was collected with consent. The simplification is not just removing the field — it's removing the consent UX, the privacy label tier, the conditional analytics paths in code, and the legal-team follow-up question "what do we do with the data?". Respectlytics's answer is: there is no IDFA, so there's nothing to do.
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
| IDFA handling | Firebase Analytics | Mixpanel | AppsFlyer | Respectlytics |
|---|---|---|---|---|
| Calls ATTrackingManager | Yes (with consent) | Yes (optional) | Yes (mandatory) | No |
| Stores IDFA in events | Yes (when consented) | Optional | Yes | Never |
| Re-requests IDFA after restart | Yes | Yes | Yes | N/A |
| Behavior when consent denied | IDFA absent | IDFA absent | Limited tracking | Identical (no IDFA path) |
| App Store Privacy Label impact | Triggers "Identifiers" tier | Triggers "Identifiers" | Triggers "Identifiers" | No "Identifiers" entry from us |
❓Frequently asked questions
How do we measure unique users without IDFA?
By session, not by user. Respectlytics's session_id rotates every two hours and on app restart, so unique-session counts (not unique-user counts) are what surface in dashboards. For most product decisions — funnel rates, feature reach, release deltas — sessions are the right unit. Per-user counts for billing or financial reporting live in your account system, not your analytics pipeline.
Do we still need an `NSUserTrackingUsageDescription` Info.plist key?
No — and you should NOT add one for Respectlytics. The presence of that key implies your app tracks across other apps and websites, which Apple interprets as a signal even if your code never calls ATTrackingManager.requestTrackingAuthorization. Add the key only if another SDK in your app legitimately needs it.
Will Respectlytics ever collect IDFA in a future version?
No. The 5-field event schema is enforced at the API boundary — additions would be a versioned breaking change with explicit migration. The privacy posture is architectural, not policy-level.
What about IDFV (vendor identifier) — is that collected?
Also no. The SDK does not read UIDevice.current.identifierForVendor. Session-scoped analytics doesn't need a per-device or per-vendor identifier — the session_id is sufficient for funnel grouping and rotates before any cross-day tracking would emerge.