Mobile SDKs lifecycle policy
Last updated: October 7, 2026
Checkout.com's lifecycle policy defines how long we support each version of our mobile SDKs, and what support means at each stage.
The policy applies to the following SDKs:
| SDK | Platforms | Distribution |
|---|---|---|
Card Issuing SDKs ( | iOS, Android |
|
3DS SDKs ( | iOS, Android |
|
The CheckoutOOB SDK ships inside every Card Issuing SDK release and follows the Card Issuing SDK's lifecycle exactly. It has no separate support window.
Each platform sets its own version numbers and release cadence, but the rules in this policy are the same for every SDK and platform.
We version and release all the components in a platform bundle together, following standard semantic versioning: MAJOR.MINOR.PATCH.
- Major – Introduces API changes that are not compatible with previous versions.
- Minor – Introduces new functionality that is backward compatible with previous versions.
- Patch – Introduces backward-compatible bug fixes.
A pre-release version has a suffix after the version number, such as -rc.N for a release candidate. Pre-release versions sit outside the lifecycle policy. They have no status and no support commitment, and you must not use them in production.
A version enters the lifecycle only when it ships without a suffix.
Every released version has exactly one of three statuses:
| Status | Meaning | Updates you receive | Production use |
|---|---|---|---|
Supported | The single latest released version. | New features, bug fixes, and security patches. | Recommended. |
Maintenance | A version that a later release replaced. Its support window is still open. | Critical security and bug fixes only. No new features. | Supported, but time limited. Plan your upgrade. |
Not supported | Every other version, including expired Maintenance lines and versions that never entered Maintenance. | None. | Not supported. Upgrade to the Supported version. |
There is always exactly one Supported version per SDK and platform.
The Maintenance window a version receives depends on the type of release that replaces it:
| Type of new release | Maintenance window for the previous latest version | Updates during the window |
|---|---|---|
Major – for example, | 6 months | Patch updates only, such as |
Minor – for example, | 3 months | Patch updates only, such as |
Patch – for example, | None | None. The previous patch moves straight to Not supported. |
Patch releases do not open a Maintenance window, because we only support the latest patch within the current major or minor line. There is no timeline to migrate to a patch, because any fix to an older patch becomes a new patch itself.
We set the window once, on the day a later release replaces the version, based on the type of that release. We never shorten, reset, or extend it, no matter what ships afterward. A version with a 6-month Maintenance window keeps those 6 months even if five more releases ship in the same month.
A patch that we ship during a Maintenance window, such as a critical fix on an older 4.2.x line, becomes the new supported patch for that line. It does not get a window of its own. Instead, it inherits the end date already set for that major or minor line.
When a version's window ends, that version and its whole line move straight to Not supported.
The following examples show how a new release changes the status of the versions before it.
The latest version is 4.2.6, and we release 5.0.0:
| Version | Status | Details |
|---|---|---|
| Supported | The new current major version. |
| Maintenance | 6 months from |
Every version older than | Not supported | Upgrade to |
The latest version is 4.2.6, and we release 4.3.0:
| Version | Status | Details |
|---|---|---|
| Supported | The new current minor version. |
| Maintenance | 3 months from |
Every version older than | Not supported | Upgrade to |
The latest version is 4.2.6, and we release 4.2.7:
| Version | Status | Details |
|---|---|---|
| Supported | The new current patch version. |
| Not supported | Patches do not open a Maintenance window, because we only support the latest patch within a major or minor line. |
Every version older than | Not supported | Upgrade to |
We track the status of each released version in the README of each SDK's GitHub repository, and update it with every release:
The patches you receive depend on the version's status:
- Supported – New features, bug fixes, and security patches.
- Maintenance – Critical security and bug fixes only, released as new patches on the same line, until the window ends.
- Not supported – None. We may make exceptions at our discretion, for example to meet an urgent card scheme or legal mandate.
We only change minimum platform requirements in major releases:
- iOS – The minimum deployment target changes. For example, we may drop support for iOS 15.
- Android – The
minSdkorcompileSdkchanges. For example, we may raise theminSdkfrom 24 to 26.
This gives you the previous major version's full 6-month Maintenance window to adapt to the change. We announce any planned increase in advance on this page, in the repository's README, and in the changelog, and we record the last compatible SDK version for each platform version we drop.
Note
Avoid relying on an SDK that appears to still work on an unsupported platform version. It can break in any release without a changelog entry.
We deprecate APIs in two stages:
- We deprecate the API in a minor release, but it keeps working as normal. We mark it as deprecated with migration hints, using each platform's native mechanism:
@available(*, deprecated:)on iOS and@Deprecatedon Android. - We remove the API in the next major release.
We communicate SDK releases and status changes through the following channels:
- Release notes – We publish release notes for every version in GitHub Releases.
- Version support – We update the version support tables in each SDK repository's README with every release.
- Status changes – We announce moves to Maintenance and Not supported in release notes, in the documentation, and through our merchant communication channels.
- In-SDK notices – Where possible, the SDK shows a one-time notice when you initialize it on a Maintenance version. The notice points to the current Supported version, and the date your version becomes Not supported.