At a glance: Learn about the AppsFlyer SDK version control policy and what versions we maintain.
For a complete picture of the AppsFlyer version control policy, be sure to read these articles:
Throughout the years, AppsFlyer has released many versions of the SDK. Each SDK version calls a specific API version. The intent of the version control policy is to define how long an API will serve the SDK versions.
Why do we need version control?
The purpose of version control includes the following:
- Helps you understand in advance when an API for the SDK versions that are integrated into your apps will sunset. This is important because version adoption takes time, meaning it may take some time until your users upgrade to a newer app version.
- Improves stability (backward compatibility is for 2.5 years), thus eliminating unexpected errors when using very old SDK versions.
- Lets you take advantage of new features that require SDK upgrades.
SDK version lifecycles
An API version is guaranteed to run for 2.5 years. Whenever a new major or minor version of the SDK is released, AppsFlyer will set a sunset date for the previous minor version (including all of its patch versions).
The following table shows an example of the SDK version lifecycle for V5.0.x. When V5.1.0 was released, the sunset date for all 5.0.x versions was set. We calculated 2.5 years from the latest patch release date.
|SDK version||Release date||Sunset date|
What happens when an SDK version is sunset?
Once a version of the SDK is sunset, AppsFlyer servers will no longer measure installs, sessions, and in-app events. Events that reach these endpoints will simply be rejected.
Since adoption takes time, it is highly recommended that your developer upgrade to the latest SDK version well in advance of the sunset date.