Upgrading from 1.x

This upgrade is required. The endpoints SDK 1.x uses now answer 426 Upgrade Required. Apps built with 1.x keep showing the strings they cached but receive no further updates until you ship a build with SDK 2.1.0 or later.

Most apps need only a new dependency version and a new token. Your cached strings, FAQs and Device-ID survive the upgrade.

1. Update the dependency

Upgrade from 1.x straight to 2.1.0:

dependencies {
    implementation("com.stringboot:stringboot-android-sdk:2.1.0")
}

SDK 2.0 requires Android 7.0 (API 24) and Kotlin 1.9 or later.

Check your dependencies

SDK 2.0 brings fewer libraries into your app. If your app used any of these only because the SDK pulled them in, declare them in your own build.gradle.kts:

Retrofit
Material 3, Compose runtime and Compose Material 3
WorkManager
androidx.activity:activity-ktx
androidx.lifecycle:lifecycle-viewmodel

The SDK now brings OkHttp, Kotlin coroutines, androidx.lifecycle:lifecycle-process and androidx.compose.ui:ui-text. You don’t need to add any permissions or ProGuard rules for it.

2. Use a Client Token

SDK 2.0 authenticates with your App’s Client Token (sb_...), which travels in the URL path. There is no X-API-Token header any more. Create a Client Token in the dashboard (see API Tokens) and put it in the manifest:

<meta-data
    android:name="com.stringboot.api_token"
    android:value="sb_YOUR_CLIENT_TOKEN" />

A Figma Plugin Token, or a revoked or expired token, gets 401: the SDK then stops syncing and keeps serving cached strings until it’s initialized again with a valid token. Set com.stringboot.api_url to https://api.stringboot.com (a leftover /api/v1 suffix is ignored).

3. Update your code

Most apps need no code changes. Check these:

1.x	2.0
Retrofit `StringbootApi` interface	`StringbootApi.create(baseUrl, clientToken)`. Code that passes `AuthInterceptor(token)` to `create(baseUrl, client)` still compiles (deprecated) and works.
`FAQProvider.initialize(context, cacheSize, api)`	The `api` parameter is ignored: FAQs come with the Catalog.
`refreshFromNetwork(lang): Boolean`	Unchanged. `sync(lang): SyncResult` gives the detailed outcome.
No built-in sync scheduling	From 2.1.0 the SDK syncs by itself at start-up and when the app returns to the foreground. `sync()` and `startAutoRefresh()` (checks every 60 s in the foreground) are optional.
`StringSyncV2Client`, `FAQSyncClient`, `DeltaSyncWorker`, `ManifestInterceptor`, `IntegrityVerifier`, `ApiResult` and the 1.x response models	Removed.

Upgrading from 2.0.x to 2.1.0

Automatic sync. 2.1.0 syncs at start-up and on returning to the foreground by itself. Apps that already call sync() or startAutoRefresh() need no changes; the SDK shares concurrent syncs, so there are no extra requests. To keep the 2.0.x behaviour, pass autoSync = false to initialize or set com.stringboot.auto_sync to false in the manifest.
Token changes. Switching to a different Client Token or base URL now keeps the previously stored strings until the new configuration succeeds. 2.0.x discarded them right away.
Libraries. A library compiled against 2.0.x that calls StringProvider.initialize with default arguments must be recompiled against 2.1.0.

Experiments

The server no longer assigns variants or records anything. The SDK buckets each Device from the Catalog with the same function the server used, so Devices keep their variants. StringbootAnalyticsHandler.onExperimentsAssigned keeps its signature. To log exposures, add a StringbootExposureListener. See A/B Testing.

onExperimentsAssigned is now called when assignments change, and once with an empty map when the last experiment stops. Make sure your analytics code handles an empty map.

Default locale

com.stringboot.default_locale no longer overrides the language the user chose on every start. The saved language is restored before the first sync.

4. Certificate pinning

SDK 2.0 ships new built-in pins for com.stringboot.enable_ssl_pinning; nothing to do for them. If you copied pins into your own network_security_config.xml, replace them with the current pin-set from Troubleshooting: the old pins fail TLS.

What happens to installed apps

On the first launch after the upgrade:

Cached data. Cached strings and FAQs are kept, so the app works offline right away. The first successful sync replaces them.
Device-ID. The existing Device-ID is kept and now sent on every request.

Checklist

Dependency is 2.1.0 or later
com.stringboot.api_token holds a Client Token starting with sb_
com.stringboot.api_url is https://api.stringboot.com
Analytics code handles an empty assignments map
Pins copied into your own network security config (if any) are updated
A fresh install shows your strings, and an edit in the dashboard appears within about two minutes

Getting Started

Android SDK

iOS SDK

Web SDK

Dashboard

1. Update the dependency

Check your dependencies

2. Use a Client Token

3. Update your code

Upgrading from 2.0.x to 2.1.0

Experiments

Default locale

4. Certificate pinning

What happens to installed apps

Checklist

​1. Update the dependency

​Check your dependencies

​2. Use a Client Token

​3. Update your code

​Upgrading from 2.0.x to 2.1.0

​Experiments

​Default locale

​4. Certificate pinning

​What happens to installed apps

​Checklist

1. Update the dependency

Check your dependencies

2. Use a Client Token

3. Update your code

Upgrading from 2.0.x to 2.1.0

Experiments

Default locale

4. Certificate pinning

What happens to installed apps

Checklist