Versions and build info

Documentation versionCopy Anchor Link

Every page of this site shows, next to the Copy Markdown button, the SDK version and the date of the SDK sources the page describes, for example SDK 0.1.0 · 9 October 2026. The site is built from the same sources as the SDK, so the date is the date of the last change to those sources at the time of the build, not the date the page was written. The Markdown copy of each page, llms.txt and llms-full.txt carry the same version and date, in the line Folio SDK <version>, documentation as of <date>.

Compare the version with lib.version of the build info of the package you installed, and the date with the release date of that package. A package released after the date on the page can contain changes these pages do not describe yet; a page dated after your release can describe names that your package does not have.

Package versionsCopy Anchor Link

The version of each package is set in its manifest. The table shows the versions of this preview. Install the version Folio gives you, written <version> in the setup guides.

Pin the exact version you install, so your package manager does not move to a newer one on its own.

The SDK is a pre-release. While its version is 0.x, a version number alone does not identify a build: a 0.x release can be published again under the same number, and its interface can change from one 0.x release to the next. To tell which build your app runs, read the source revision from SdkBuildInfo (the revision of its Stamped product) and report it together with the version when you contact Folio. Bindgen.revision of the build info constant is the revision of the generator, not of the SDK. See iOS, Android and Web for the install steps and Selfie capture for the selfie engine.

Each release also has a provenance file that records its source revision, the generator and the SHA-256 digest of the files of that release: PROVENANCE.json at the root of the iOS package repository and of the web package repository at the release's tag, and provenance/<version>.json at the root of the Android Maven repository. The Android record covers the files of the version directories id/folio/sdk/<version>/ and id/folio/sdk-native/<version>/, the version directories of the selfie engine artifacts the release depends on, and the top-level files VERSION, ABIS, README.md and LICENSE as published with that release. The maven-metadata.xml index of each artifact and its checksum files are rewritten by every release and are not recorded. The npm package holds dist, LICENSE, README.md and package.json; PROVENANCE.json and VERSION stay in the repository, so they are not in node_modules/@folio/sdk.

Read the version at run timeCopy Anchor Link

Your app reads versions from these places:

InquiryLifecycle is in the state of the inquiry store. See Inquiry store.

if case let .ready(sdkVersion) = inquiry.state.lifecycle, let sdkVersion {
    print("Folio SDK", sdkVersion)
}

Build infoCopy Anchor Link

Each package carries a constant that describes the SDK core it was built with. It is FolioSDKBuildInfo in the FolioSDK module on iOS, the object id.folio.sdk.FolioSDKBuildInfo on Android and folioSDKBuildInfo, of the type FolioSDKBuildInfo, exported from @folio/sdk on the web:

Bindgen.modified is a boolean and Bindgen.formatVersion an integer; the other values of Lib and Bindgen are strings. On the web lib.crates lists the Rust crates of the core, lib.exports the names of the exported types and lib.dependsOn the modules it depends on, none for FolioSDK.

native says whether the package contains a built native library:

A package that carries only the generated bindings reports Unbuilt. In Built, profile has the build profile name, debug or release, the compiler settings optLevel, lto, panic and strip as strings, and features, the build features as a list of strings. binaries maps each native binary to its targets, sha256 and size. On Android sha256 is the digest of the library in the Maven repository, not of the copy the Android Gradle plugin strips into your APK; see Android. The debug feature marks a development build. A build made with the release profile can still carry the debug feature, so read features, not name, to tell the two apart.

let coreVersion = FolioSDKBuildInfo.Lib.version
var developmentBuild = false
if case let .built(profile, _) = FolioSDKBuildInfo.native {
    developmentBuild = profile.features.contains("debug")
}

SdkBuildInfoCopy Anchor Link

FolioSdk.sdkBuildInfo() is a static function of the runtime object: try FolioSdk.sdkBuildInfo() in Swift, FolioSdk.sdkBuildInfo() in Kotlin and TypeScript. It describes the SDK core that is loaded. It returns an SdkBuildInfo:

SdkProduct has two cases. Stamped carries:

Unstamped carries nothing: the build has no version, sends no identification headers and reports READY without sdkVersion. SdkProfile carries name, debug or release, and features, the build features such as debug. SdkGenerator carries the same values as Bindgen in the build info constant.

if case let .stamped(_, version, revision, _) = try FolioSdk.sdkBuildInfo().product {
    print("Folio SDK", version, revision)
}

Every runtime also writes its build info to the log when it starts, in an entry that begins with Folio SDK <version> ✓ ready, followed by the platform, the CPU architecture and the build profile. It lists the product and its revision, bindgen, the interface digest, the build features and, in a stamped build, your app's version and build. See Logging.

Client identificationCopy Anchor Link

A stamped SDK identifies your app to the Folio backend on every request it sends. It reads the version and build of your app from the platform, not from FolioSdkConfig; see Application identity. The identifier of your app is not sent.

X-Folio-User-AgentCopy Anchor Link

Every request carries the X-Folio-User-Agent header, a structured-field dictionary with three members:

sdk="<sdk version>";revision="<revision>";modified=?0, platform=<os>[;type=<form factor>][;v="<os version>"], product=<module>;v="<app version>";build="<app build>"

• sdk: the version of the SDK core crate, the source revision and modified: modified=?0 for a clean build, a bare modified for a build from changed sources.
• platform: the operating system, its version when the platform reports one, and on Android and the web the form factor.
• product: always sdk for FolioSDK, with your app's version and build.

For example, version 4.0.0 build 812 of a web app sends sdk="0.1.0";revision="d709d4b";modified=?0, platform=web;type=desktop, product=sdk;v="4.0.0";build="812". A missing or empty version or build makes create fail with the CoreError NotInitialized. A value longer than 128 bytes or with characters outside printable ASCII makes it fail with InvalidInput. An unstamped build sends no X-Folio-User-Agent and cannot build DPoP proofs, so the requests that need one fail.

User-AgentCopy Anchor Link

On iOS and Android the SDK also sets the standard User-Agent header, when the request has none:

FolioSDK/<sdk version> (<module>; <os> <os version>; <device model>[; <form factor>]) <module>/<app version>

The OS version is left out when the platform reports none, and the form factor is added on Android, where the device model is the Build.DEVICE name of the device. For example, an app with version 4.0.0 on Android 14 sends FolioSDK/0.1.0 (sdk; android 14; <device>; phone) sdk/4.0.0 when the SDK core is 0.1.0. On the web the browser's own User-Agent is kept.

Embed loader versionCopy Anchor Link

The script-tag loader of the inquiry embed carries the major version of the SDK in its file name, embed.v<major>.js. The loader of the 0.1.0 release of @folio/sdk is named embed.v0.js, and every later 0.x release keeps that name. When the inquiry reports READY, the loader compares the major of sdkVersion with the major in its own URL and, on a mismatch or a missing sdkVersion, reports FAILED with an EMBED error whose reason is VERSION_MISMATCH. To move to a new major version, change the loader URL in your page. Versions and caching describes the releases a loader URL receives and how long each file is cached.