> For the complete documentation index, see [llms.txt](https://docs.idlayr.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.idlayr.com/get-started/sdks/versioning.md). # SDK versioning IDlayr's mobile SDKs follow **Semantic Versioning** (SemVer): `MAJOR.MINOR.PATCH`. Each SDK release is tagged with a version number that signals the scope of change. | Component | Meaning | | --------- | --------------------------------------------------------------------------------------------------------------------------------------- | | **MAJOR** | Breaking change. Imports, public APIs, behaviour, or distribution channels that no longer match the previous major. | | **MINOR** | Backwards-compatible feature additions — new methods, new optional parameters, new error codes. Existing integrations continue to work. | | **PATCH** | Backwards-compatible bug fixes and internal improvements. Existing integrations continue to work. | ## iOS and Android version independently The iOS SDK (`IDlayrKit`) and the Android SDK (`idlayr-sdk-android`) are **separate products with separate release cadences**. At any given moment they are unlikely to be at the same version — at the time of writing, iOS is at **2.4.1** while Android is at **2.3.6**. These numbers drift as each SDK is released. The reason is practical: each platform has its own constraints. iOS releases are driven by changes in `NWConnection`, SwiftPM, and Xcode toolchain support; Android releases are driven by `minSdk` / `targetSdk` bumps, `ContentProvider` behaviour, and Gradle changes. Pinning the two versions together would block legitimate releases on one platform while waiting for the other. When documenting an integration, refer to each platform's current version separately. The source of truth for the current version is the respective package registry: * **iOS** — Cloudsmith Swift Package Registry (`https://swift.cloudsmith.io/idlayr/sdk-ios-swift/`) and the IDlayr CocoaPods Specs repository. * **Android** — Cloudsmith Maven (`https://dl.cloudsmith.io/basic/idlayr/sdk-android-maven/maven/`). For change-by-change release history, see the [Changelog](https://docs.idlayr.com/changelog). ## SDK versioning is separate from API versioning This is the most important point on the page, because it's the most common source of confusion: > **The API version (`/v1/`) and the SDK version (e.g. `IDlayrKit 2.4.1`) are independent.** | | API contract | Mobile SDK | | ------------- | -------------------------------------------------------- | ---------------------------------------------------------------- | | Scheme | Major-only URI versioning (`/v1/`, `/v2/`) | SemVer (`MAJOR.MINOR.PATCH`) | | What it names | The HTTP API contract — endpoints, schemas, error shapes | The mobile SDK package — public methods, behaviour, distribution | | Bumps when | The API contract makes a breaking change | The SDK makes a breaking change | | Affects | Every client of the IDlayr REST API | Only customers integrating one of the mobile SDKs | Implications: * **An SDK upgrade does not change the API contract.** Moving from `IDlayrKit 2.4.0` to `2.5.0` doesn't change what the IDlayr API accepts or returns — it changes the SDK's internals or its public surface. * **An API version bump doesn't force an SDK upgrade.** If we publish `/v2/` in the future, your `IDlayrKit 2.x` integration continues to call `/v1/` until your backend chooses to migrate. (The mobile SDKs target the backend-facing redirect chain, not specific API paths — your backend determines the API version it talks to.) * **An SDK major bump may or may not coincide with an API major bump.** They are scheduled independently. For the API contract versioning policy — breaking-change definition, legacy maintenance window, error behaviour on unsupported versions — see [API versioning](/get-started/concepts/api-versioning.md). ## Support policy We support the **current major and the immediately previous major** for each platform's SDK. Older majors continue to function but are not actively developed. * **Current major**: full feature development, bug fixes, security patches. * **Previous major**: security patches only. * **Older majors**: best-effort. We may publish a patch for a critical security issue, but no functional changes. Specific EOL dates are not pre-scheduled — they're announced via the [Changelog](https://docs.idlayr.com/changelog) when a major is deprecated. ## Breaking changes Breaking changes — anything that requires a major bump — are documented in the SDK migration guide (Help Center) and the [Changelog](https://docs.idlayr.com/changelog). The Changelog entry calls out the breaking change, the migration steps, and the corresponding new major. Examples of changes that have warranted a major bump in the past: * Renaming the SDK package (e.g. `tru-sdk-ios` → `IDlayrKit`). * Moving distribution from a public registry to a private Cloudsmith repository. * Removing or renaming public methods. * Changing the way the SDK is initialised (e.g. removing `initializeSdk(...)` and switching to auto-initialisation via `ContentProvider` on Android, in v2.3.0). ## Non-breaking changes The following do not trigger a major bump: * Adding a new public method or a new overload. * Adding a new optional parameter to an existing method. * Adding a new error code to the SDK error set. * Internal performance or stability improvements. * Bug fixes that align behaviour with documented behaviour. These ship in minor or patch releases and are safe to upgrade to without changing your integration. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.idlayr.com/get-started/sdks/versioning.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.