▸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
Firebase Analytics on Android typically ships ~15–25 transitive dependencies, including ad-tech libraries (Google Mobile Ads, play-services-ads-identifier) that contribute permissions to the merged manifest. Most teams discover this only after Google Play flags the Data Safety form. Respectlytics's dependency-light architecture means the merged manifest doesn't grow.
A useful audit habit: search your build output for any User-Agent string emitted by SDKs you didn't intentionally install. Branch, AppsFlyer, Adjust, Singular, mParticle, and others emit identifiable User-Agents — if your build has them and you didn't add the SDK, something transitive pulled it in.
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
| SDK supply chain | Firebase Analytics | Mixpanel | AppsFlyer | Respectlytics |
|---|---|---|---|---|
| Direct ad/tracking dependencies | Many (FCM, Google Mobile Ads, …) | Few | Many (Branch, partner SDKs) | Zero |
| Pulls Google Play Services | Yes (mandatory) | No | Yes | No |
| Adds `AD_ID` to merged manifest | Yes (auto) | Conditional | Yes | No |
| Network calls outside the analytics path | Yes (FCM, Crashlytics, …) | Yes (campaign tracking) | Yes (referrer SDKs) | No |
| Number of HTTP endpoints contacted | 5+ | 2–3 | 3+ | 1 |
❓Frequently asked questions
How do we verify the dependency tree?
On iOS: swift package show-dependencies (Swift Package Manager) lists the entire transitive tree. On Android: ./gradlew :app:dependencies --configuration releaseRuntimeClasspath shows everything in the release classpath. On RN: npm ls --all. On Flutter: flutter pub deps. Respectlytics's tree should be a single node with no children outside the standard library.
What about `URLSession` / `OkHttp` / `fetch`?
Those are platform standard libraries, not third-party trackers. They ship with the OS or the framework. Respectlytics uses them directly and doesn't introduce additional HTTP libraries on top.
Is open-sourcing the SDK enough to verify this?
Helpful but not sufficient. The dependency manifests (Package.swift, build.gradle, package.json, pubspec.yaml) are the authoritative source — those say what gets pulled at build time. Reading those is a 5-minute audit; reading the source is helpful for behavioral verification but not necessary for the dependency claim.
Are there any optional dependencies (Crashlytics-style) we'd need?
No. Respectlytics doesn't bundle crash reporting, push notification, feature flags, or experiments — those are separate concerns with their own SDKs (e.g., Sentry, OneSignal, GrowthBook). You can pair Respectlytics with whichever you need; we don't bundle them in to inflate the surface.