Docs

AppsFlyer's SDK Sunset Cycle: Tracking Version Coverage

AppsFlyer now retires legacy SDKs on a fixed six-month cycle. Learn what version-adoption data to track before attribution silently breaks.

Acquisition

AppsFlyer has moved to a fixed six-month deprecation cycle for its iOS and Android SDKs, splitting versions into two tiers: “deprecated” (still sends data, but unsupported and discouraged) and “end-of-support” (measurement stops entirely). That second tier is the one that catches teams off guard, because nothing crashes and no error appears — install and event attribution for anyone still on that build simply stops being counted, silently.

The risk isn’t the SDK version in your latest release. It’s the long tail: users who haven’t updated in months, older app versions still live on low-end devices, and white-label or legacy builds nobody actively maintains. Without visibility into what fraction of your installed base is running a soon-to-be-unsupported SDK version, a scheduled sunset date turns into an unexplained drop in attributed installs weeks later, with no obvious cause in your dashboards.

Data Points to Track

  • appsflyer_sdk_version — captured on every session, not just install, since version drift shows up over time
  • sdk_support_status — derived client- or server-side by comparing the installed version against AppsFlyer’s current deprecated/end-of-support lists
  • app_version and build_number — to map SDK version back to the release train that shipped it
  • platform and os_version — legacy SDK usage often clusters on older OS versions that can’t take a newer SDK without other dependency upgrades
  • install_source — so you can see whether unsupported-SDK traffic is concentrated in a specific channel or partner integration
  • days_since_last_update — a proxy for how much of your unsupported-SDK cohort is even reachable by a forced update prompt

Setup Steps

  1. Log SDK version on session start. Add appsflyer_sdk_version as a standard property on your session-start event so you have continuous visibility, not just a one-time install-time snapshot.
  2. Build a version-status lookup. Maintain a small mapping of SDK versions to deprecated/end-of-support status, checked against AppsFlyer’s published bulletins, and join it against your session data.
  3. Segment your installed base by support status. Create a dashboard view showing the percentage of active sessions running deprecated or end-of-support SDK versions, broken down by app version and platform.
  4. Set an alert threshold. Trigger a warning when end-of-support SDK usage crosses a defined percentage of daily active sessions, well ahead of the actual sunset date.
  5. Cross-reference with forced-update capability. Check whether the app versions carrying old SDKs are still eligible for a forced or soft update prompt — some won’t be, which changes your remediation options entirely.

Actionable Insights

A dashboard that shows SDK support status as a share of sessions turns an abstract deprecation bulletin into a concrete migration deadline: if 12% of your daily sessions are on an end-of-support build, that’s the ceiling on the attribution data you’ll lose the day the sunset takes effect. Cross-referencing with install_source often reveals that unsupported SDK usage is concentrated in one partner SDK wrapper or white-label build rather than spread evenly, which tells you exactly where to focus a migration push instead of chasing the whole user base. Tracking days_since_last_update alongside SDK version tells you which fraction of that cohort a forced-update campaign can actually reach, versus users who are effectively unreachable until they reinstall.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert