Skip to main content

Migration Guide: stytch-android → stytch-mobile (Android)

Our new Kotlin Multiplatform SDK is still in Public beta. If you’re looking for a stable version, we recommend using our stytch-android package for the time being.
This guide covers what changed when moving from the com.stytch.sdk:sdk artifact (the original Android-only SDK) to com.stytch.sdk:consumer-headless or com.stytch.sdk:b2b-headless (the new Kotlin Multiplatform SDK).

What Changed at a Glance


Kotlin Version

The new SDK requires Kotlin 2.3.0 or later. Update your project’s Kotlin version before proceeding:

Installation


Configuration

Before: auto-configured from a string resource

The old SDK read your public token automatically from a STYTCH_PUBLIC_TOKEN string resource and configured itself when you called configure(context):

After: explicit configuration

The new SDK requires you to pass the token explicitly. Remove the STYTCH_PUBLIC_TOKEN string resource and initialize the client directly:
Store the returned instance — it’s a singleton, but you should hold a reference to it rather than relying on a global StytchClient object. The STYTCH_PUBLIC_TOKEN string resource used to also auto-register OAuth redirect activities. With the new SDK, that’s handled by the SDK’s internal activity management — you only need to add your custom URL scheme’s intent filter for magic links / password reset deeplinks.

Error Handling

Before: StytchResult sealed class

After: throws StytchError

This aligns with standard Kotlin coroutine error handling and removes the need to chain when blocks around every call.

Method Naming

Most method names are the same, but a few have changed. Key differences: The parameter types are generated from the OpenAPI spec. When in doubt, let IDE autocomplete guide you — the shape (field names, types) is consistent with the old SDK’s parameters.

Authentication State and Session Access

Before: multiple sources of truth

The old SDK had several ways to observe and access session/user data:

After: one StateFlow

The new SDK consolidates everything into a single StateFlow:

Before

After

The new authenticate() takes a String URL rather than a URI object. Call uri.toString() if you have a URI from the intent. If you need the token type directly without authenticating:

OAuth

The OAuth flow has been significantly simplified. The old SDK had two patterns: an activity-result callback approach, and a getTokenForProvider() approach. Both required two steps (start + authenticate). The new SDK collapses this into a single start() call that manages the browser, handles the redirect, and returns the fully authenticated response.

Before (activity result callback pattern)

Before (direct token capture pattern)

After

No oAuthRequestIdentifier, no setOAuthReceiverActivity(), no separate authenticate() call.

Google Credential Manager (formerly Google OneTap)

The old SDK exposed Google OneTap as a separate googleOneTap client. In the new SDK, native Google Credential Manager is used automatically when you provide GoogleCredentialConfiguration in the StytchClientConfiguration. The call site is identical to any other provider:
If no GoogleCredentialConfiguration is provided, or if Google Credential Manager fails on the users device, oauth.google.start() falls back to a browser-based OAuth flow.

Note: Google Credential Manager is only supported in the consumer SDK. Google Credential Manager is not supported in the B2B SDK.


B2B SDK

If you used the B2B client in the old SDK (StytchB2BClient), the migration is the same pattern. Replace the artifact and swap createStytchConsumer for createStytchB2B:
The B2B auth state uses B2BAuthenticationState with .authenticated (carrying member, memberSession, organization), .unauthenticated, and .loading cases.

Callback Extensions

The old SDK generated callback overloads for every method automatically. The new SDK ships them in a separate artifact. If your codebase uses callbacks, swap the dependency:

Pre-Built UI

StytchUI is not available in the new SDK. The new SDK is intentionally headless — you have complete control over every pixel of your authentication experience, which means no constraints on layout, styling, navigation, or branding. Your existing screens remain yours; you just wire them to the SDK methods directly.

Automatic Session Migration

There’s nothing you need to do. On first launch after upgrading, the new SDK automatically reads and decrypts your users’ existing sessions from the old SDK’s SharedPreferences store and migrates them into the new SDK’s storage format. Users who were logged in will remain logged in.