▸Install the React Native SDK
npm install @respectlytics/react-native
# or
yarn add @respectlytics/react-native
JavaScript-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
The ATT prompt's denial rate ranges 50–80% depending on category and phrasing — gaming and ad-heavy apps see the highest denials. The product consequence is that any analytics tied to IDFA effectively works for the minority who consent. Respectlytics produces the same data for 100% of users because it does not depend on IDFA at all.
App Review historical pattern: apps that ship NSUserTrackingUsageDescription in Info.plist while their code never actually calls ATTrackingManager.requestTrackingAuthorization are flagged as inconsistent — the key implies tracking that the code doesn't perform. Remove the key when you remove tracking; don't leave it as a relic.
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
| ATT prompt behaviour | Firebase Analytics | Mixpanel | AppsFlyer | Respectlytics |
|---|---|---|---|---|
| Triggers ATT prompt by default | Yes (when IDFA enabled) | Yes (optional) | Yes (always) | No |
| Requires NSUserTrackingUsageDescription | Yes (when collecting IDFA) | Conditional | Yes | No |
| Behavior when user denies ATT | Limited tracking | Limited tracking | Restricted IDFA | Identical (ATT not in path) |
| Conversion-rate impact of prompt | Negative (~10–30% denial) | Negative | Negative | No prompt |
❓Frequently asked questions
Should we still implement ATT for other reasons?
Only if another SDK in your app needs it — e.g., an Ads SDK that uses the IDFA. If you remove all such SDKs, you can also remove the NSUserTrackingUsageDescription key. The presence of the key without a matching requestTrackingAuthorization call is itself a signal Apple considers.
What about post-install attribution from ad campaigns?
Use Apple's SKAdNetwork (deterministic, deterministic install attribution without IDFA) or AdAttributionKit (iOS 17.4+). Both work without ATT. These are not Respectlytics features — they're Apple frameworks your app implements directly. Respectlytics doesn't ingest install attribution.
Will the App Store reject my app if there's no ATT prompt?
No, as long as no SDK in your app actually tracks across other apps. Apps that genuinely don't track are not required to show ATT. The risk is the inverse: showing the prompt without backing the choice in code (or vice versa) gets flagged. Respectlytics's posture is consistent — no tracking, no prompt.
Does Respectlytics affect ATT prompt timing for OTHER SDKs in our app?
No. Each SDK calls requestTrackingAuthorization independently. Respectlytics's silent-on-ATT behavior doesn't influence other SDKs. If Firebase, AdMob, or Branch in the same app needs ATT, those SDKs still trigger the prompt according to their own logic.