Replace Segment (Twilio): fewer SDKs

Q: How do we audit our current dependency tree?

iOS: `swift package show-dependencies` (SPM) or `pod outdated` (CocoaPods) lists the tree. Android: `./gradlew :app:dependencies --configuration releaseRuntimeClasspath`. RN: `npm ls --all`. Flutter: `flutter pub deps`. Our [Dependency Privacy Scanner](/tools/dependency-privacy-scanner/) parses lockfiles from any of these and tells you which deps are forcing which privacy labels.

▸Example Segment (Twilio) call (the "before")

kotlin Respectlytics

import com.segment.analytics.kotlin.android.Analytics

val analytics = Analytics("YOUR_WRITE_KEY", context) {
    collectDeviceId = true
    flushAt = 20
}

analytics.identify(userId, traitsOf("email" to email, "plan" to "pro"))
analytics.track("Paywall Purchase", buildJsonObject {
    put("value", price)
    put("currency", "USD")
})

Every third-party SDK is a supply-chain surface — manifest permissions, network endpoints, transitive dependencies. The biggest reduction in privacy footprint often comes from simply shipping fewer SDKs. Respectlytics has zero ads, attribution, or routing dependencies — it's one HTTPS endpoint.

☑Remove Segment (Twilio) cleanly

1
Remove the Segment Analytics SDK from your build (Analytics-Swift / analytics-android / @segment/analytics-react-native / segment_analytics_flutter)
2
Remove Analytics.client(writeKey: ...) and analytics.track(...) call sites — replace with Respectlytics.track("event_name")
3
Critically: review your Segment destinations and decide which destinations you still need data flowing to from Respectlytics (most don't — that's the point)
4
Delete the Segment workspace's mobile source once events have stopped flowing
5
Audit and remove the downstream destination SDKs that Segment was the only reason to forward to (e.g., Facebook Pixel, Google Ads)

⇋Segment (Twilio) vs Respectlytics — fewer third-party sdks

	Segment (Twilio)	Respectlytics
Direct ad / tracking dependencies	— see tool note above	Zero
Pulls Google Play Services	— typically yes	No
Auto-merged manifest permissions	Often (AD_ID, ACCESS_NETWORK_STATE, etc.)	None added
Number of HTTP endpoints contacted	Multiple (varies)	One (Respectlytics API)
Open-source SDK	— varies by tool	Yes (MIT-licensed)

❓Frequently asked questions

How do we audit our current dependency tree?

iOS: swift package show-dependencies (SPM) or pod outdated (CocoaPods) lists the tree. Android: ./gradlew :app:dependencies --configuration releaseRuntimeClasspath. RN: npm ls --all. Flutter: flutter pub deps. Our [Dependency Privacy Scanner](/tools/dependency-privacy-scanner/) parses lockfiles from any of these and tells you which deps are forcing which privacy labels.

What if we still need install attribution?

First-party alternatives without an SDK: Apple SKAdNetwork (iOS), AdAttributionKit (iOS 17.4+), Google Play Install Referrer API (Android). These are built into the OS — your ads platform reads them directly. No mobile SDK required.

What about crash reporting and push notifications?

Those are separate concerns with their own SDKs — Sentry / Crashlytics / Bugsnag for crashes; OneSignal / FCM / APNs for push. Respectlytics doesn't bundle them in; you pick the dedicated SDK for each surface.

Does shipping fewer SDKs measurably improve app size or cold start?

Often, yes — measurably. Removing Firebase + AppsFlyer + Segment from a typical RN app can shave several megabytes of bundle and 100-300ms off cold start. See the [SDK Bundle-Size Comparator](/tools/sdk-bundle-size-comparator/) for specific numbers.

⇢Related migration guides

Replace Segment (Twilio) to ship fewer third-party SDKs