Modern mobile applications need to store data locally for many different reasons.

An application may need to remember:

• Whether a user has completed onboarding
• Login/session information
• Application settings
• Theme preferences
• Language selection
• User preferences
• Cached API data
• Recently viewed items
• Offline data
• Authentication state

In a Kotlin Multiplatform (KMP) application, local storage becomes especially important because Android and iOS use different native storage technologies.

Android commonly uses technologies such as DataStore, while iOS provides storage mechanisms such as UserDefaults and Keychain.

Kotlin Multiplatform allows developers to create shared storage abstractions and reuse data-management logic across platforms while still using the appropriate native storage technology underneath.

In this complete guide, you’ll learn how local storage works in Kotlin Multiplatform, when to use DataStore, how Preferences storage differs from secure storage, how to design a shared storage layer, how to store authentication information safely, and how to choose the right storage solution for your KMP application.

---

What Is Local Storage?

Local storage means saving application data directly on the user’s device.

Unlike server-side storage:

Mobile App
    ↓
Internet
    ↓
Backend Server
    ↓
Database

local storage works directly on the device:

Mobile App
    ↓
Local Storage
    ↓
Device

This allows applications to access certain information without making a network request every time.

For example, an app can remember:

isOnboardingCompleted = true
selectedLanguage = "English"
darkMode = true

even after the application is closed and reopened.

---

Why Does KMP Need Local Storage?

Kotlin Multiplatform allows you to share application logic between platforms.

For example:

             Shared KMP Code
                    |
          +---------+---------+
          |                   |
       Android               iOS
          |                   |
      Android Storage     iOS Storage

The business logic can be shared while platform-specific storage implementations handle the underlying operating-system APIs.

This is particularly useful for:

• Authentication
• Preferences
• Caching
• Offline support
• App configuration
• User settings

---

Types of Local Storage

Not all data should be stored in the same way.

A typical application may use several storage categories.

Local Storage
│
├── Preferences
│
├── Secure Storage
│
├── Database
│
├── Cache
│
└── Files

Each one has a different purpose.

---

1. Preferences Storage

Preferences are small key-value values.

Examples:

onboarding_completed = true
theme = dark
language = en
notifications_enabled = true

Preferences are useful for simple application settings.

---

2. Secure Storage

Secure storage is intended for sensitive credentials or secrets.

Examples:

Access Token
Refresh Token
Sensitive Credentials
Encryption Keys

On Android, secure storage can be backed by platform security mechanisms such as the Android Keystore.

On iOS, sensitive credentials can be stored using the Keychain.

---

3. Database Storage

Databases are appropriate for structured and larger datasets.

For example:

Users
Products
Orders
Messages
Offline Records

A database is better than preferences when your application needs:

• Multiple records
• Relationships
• Queries
• Sorting
• Filtering
• Transactions

---

4. Cache Storage

Cache storage is temporary or replaceable data.

For example:

API Response
 ↓
Cache
 ↓
Display Data

If the cache is deleted, the application should generally be able to retrieve the information again from the server.

---

5. File Storage

Files are useful for:

• Images
• PDFs
• Videos
• Documents
• Exported files
• Large offline resources

Files should not generally be used as a replacement for a database or secure credential store.

---

DataStore and Kotlin Multiplatform

DataStore is a modern Android data-storage solution designed by Google for storing small amounts of application data.

It provides a safer and more structured alternative to the older SharedPreferences API on Android.

However, when designing a Kotlin Multiplatform application, you need to consider the multiplatform support and architecture of the specific DataStore version and libraries you choose.

For a fully shared KMP storage layer, many teams use a multiplatform-compatible abstraction/library or define their own interface and provide platform implementations.

The key architectural idea is:

Shared Storage Interface
          |
     +----+----+
     |         |
 Android      iOS
     |         |
 DataStore   Native Storage

---

Preferences vs Secure Storage

One of the most important distinctions is between ordinary preferences and secure storage.

Data	Recommended Storage
Theme	Preferences
Language	Preferences
Onboarding status	Preferences
Notification setting	Preferences
Selected country	Preferences
Access token	Secure storage
Refresh token	Secure storage
Password	Do not store
Encryption key	Secure storage
User profile cache	Database
Product cache	Database/Cache

A common mistake is storing authentication tokens in ordinary preferences.

Sensitive authentication credentials should be protected using an appropriate secure-storage mechanism.

---

Why Not Store JWT Tokens in Preferences?

Suppose you have:

accessToken = eyJ...
refreshToken = abc...

These tokens can provide authenticated access to backend resources.

Storing them as ordinary unprotected preference values is not ideal.

Instead:

Android
→ Secure platform storage

iOS
→ Keychain

Your KMP shared code can communicate with these platform-specific implementations through an abstraction.

---

KMP Storage Architecture

A clean architecture can look like:

                     Shared KMP
                         |
                  Storage Interface
                         |
              +----------+----------+
              |                     |
          Android                   iOS
              |                     |
          DataStore             UserDefaults
                                  / Keychain

Notice that different types of data may use different platform storage mechanisms.

For example:

Preferences
Android → DataStore
iOS → UserDefaults

Sensitive Tokens
Android → Secure storage
iOS → Keychain

---

Creating a Shared Storage Interface

Instead of allowing application code to directly access DataStore or UserDefaults, define an abstraction.

For example:

interface PreferencesStorage {

    suspend fun putString(
        key: String,
        value: String
    )

    suspend fun getString(
        key: String
    ): String?

    suspend fun putBoolean(
        key: String,
        value: Boolean
    )

    suspend fun getBoolean(
        key: String
    ): Boolean?

    suspend fun remove(key: String)

    suspend fun clear()
}

Your business logic can now depend on this interface.

---

Why Create an Interface?

Without an abstraction:

ViewModel
   ↓
Android DataStore

The shared business logic becomes platform-dependent.

With an abstraction:

ViewModel
   ↓
PreferencesStorage
   ↓
Platform Implementation

This makes your application easier to:

• Test
• Maintain
• Replace
• Extend
• Share between platforms

---

Example: Onboarding Preference

Suppose your application needs to know whether onboarding has been completed.

You can save:

preferencesStorage.putBoolean(
    "onboarding_completed",
    true
)

Then read:

val completed =
    preferencesStorage.getBoolean(
        "onboarding_completed"
    ) ?: false

The UI can then decide:

Completed
    ↓
Home Screen

Not Completed
    ↓
Onboarding

---

Storing Theme Preferences

You can store the selected theme:

preferencesStorage.putString(
    "theme",
    "dark"
)

Retrieve it:

val theme =
    preferencesStorage.getString(
        "theme"
    ) ?: "system"

Possible values:

light
dark
system

---

Storing Language Preferences

For multilingual applications:

preferencesStorage.putString(
    "language",
    "en"
)

You might store:

en → English
hi → Hindi
fr → French
es → Spanish

The application can read the preference during startup.

---

DataStore Concepts

On Android, DataStore is commonly used for storing small amounts of data.

There are two major approaches:

Preferences DataStore
Proto DataStore

---

Preferences DataStore

Preferences DataStore stores key-value data.

For example:

theme = dark
language = en
notifications = true

It is useful when your data doesn’t need a predefined schema.

Conceptually:

Preferences
│
├── theme
├── language
├── onboarding
└── notifications

---

Proto DataStore

Proto DataStore uses a predefined schema.

This can be useful when you want strongly typed structured data.

Conceptually:

UserPreferences
│
├── theme
├── language
├── notifications
└── onboardingCompleted

Proto DataStore is more structured than simple key-value preferences.

However, when designing a shared KMP application, always check whether the exact storage approach and libraries fit all of your target platforms.

---

DataStore vs SharedPreferences

DataStore was designed to address several limitations of SharedPreferences.

A simplified comparison:

Feature	DataStore	SharedPreferences
Modern Android storage	Yes	Older API
Asynchronous	Yes	Mostly synchronous
Kotlin Flow support	Yes	No native Flow API
Type-safe Proto option	Yes	No
Transactional updates	Better suited	Limited
KMP suitability	Depends on chosen implementation	Android-specific

For new Android-only projects, DataStore is generally preferred over SharedPreferences for modern preference storage.

For KMP, focus on the shared abstraction rather than directly coupling all shared code to an Android-only API.

---

Using Flow With Preferences

Reactive preference changes can be useful.

Conceptually:

val themeFlow: Flow<String> =
    preferencesStorage.observeString("theme")

Then:

User changes theme
       ↓
Storage updates
       ↓
Flow emits new value
       ↓
ViewModel receives update
       ↓
UI updates

This is useful for settings that should immediately affect the UI.

---

Local Storage With Coroutines

Many storage APIs are asynchronous.

Therefore, KMP applications commonly use coroutines.

For example:

suspend fun saveUserPreference() {

    preferencesStorage.putString(
        "language",
        "en"
    )
}

This prevents storage operations from unnecessarily blocking the main thread.

---

Secure Storage Architecture

A secure storage abstraction can look like:

interface SecureStorage {

    suspend fun save(
        key: String,
        value: String
    )

    suspend fun get(
        key: String
    ): String?

    suspend fun remove(
        key: String
    )

    suspend fun clear()
}

Then:

commonMain
     |
 SecureStorage
     |
 +---+---+
 |       |
Android  iOS
 |       |
Keystore Keychain

---

Token Storage Example

Your authentication repository could use:

class AuthRepository(
    private val authApi: AuthApi,
    private val secureStorage: SecureStorage
) {

    suspend fun login(
        email: String,
        password: String
    ) {

        val response = authApi.login(
            LoginRequest(
                email = email,
                password = password
            )
        )

        secureStorage.save(
            "access_token",
            response.accessToken
        )

        secureStorage.save(
            "refresh_token",
            response.refreshToken
        )
    }
}

This keeps authentication logic independent from the underlying platform storage implementation.

---

Android Secure Storage

Android applications have platform security facilities that can be used to protect cryptographic keys and sensitive credentials.

A common architecture is:

KMP Shared Code
      ↓
SecureStorage
      ↓
Android Implementation
      ↓
Android secure cryptographic facilities

Depending on your chosen library and security requirements, encrypted storage may be built around Android Keystore-backed keys.

The exact implementation should be selected based on the Android versions and security requirements of your application.

---

iOS Secure Storage

On iOS, sensitive credentials are commonly stored in the Keychain.

Architecture:

KMP Shared Code
      ↓
SecureStorage
      ↓
iOS Implementation
      ↓
Keychain

The Keychain is designed for securely storing sensitive information.

---

UserDefaults on iOS

For ordinary preferences, iOS provides UserDefaults.

For example:

theme = dark
language = en
onboarding = true

A KMP application can hide this behind the same shared interface:

PreferencesStorage
       ↓
iOS UserDefaults

But don’t use UserDefaults as a secure vault for sensitive authentication credentials.

---

DataStore and iOS

One important KMP architectural point is that Android DataStore is not automatically the universal answer for every KMP target.

Your shared application should define what it needs:

save preference
read preference
observe preference
remove preference

Then each platform can use the appropriate implementation.

This provides flexibility.

---

Using expect and actual

Kotlin Multiplatform can use expect and actual declarations for platform-specific functionality.

For example:

// commonMain

expect class PlatformStorage {
    suspend fun save(
        key: String,
        value: String
    )

    suspend fun get(
        key: String
    ): String?
}

Android can provide an actual implementation, while iOS provides another.

This approach is useful when platform APIs are fundamentally different.

However, an interface plus dependency injection is often more flexible for testing and larger applications.

---

Interface vs Expect/Actual

Both approaches are useful.

Interface + Dependency Injection

Interface
   ↓
Android Implementation
iOS Implementation
Fake/Test Implementation

Advantages:

• Easy testing
• Flexible
• Clear dependency boundaries
• Easy mocking

Expect/Actual

expect
  ↓
actual Android
actual iOS

Advantages:

• Convenient for platform APIs
• Built directly into Kotlin Multiplatform
• Useful for small platform-specific abstractions

Choose based on your architecture.

---

Local Database in KMP

Preferences are not suitable for everything.

Suppose you need to store:

1000 products
500 orders
200 messages

A database is a better choice.

The architecture could be:

Repository
    |
    +---- Remote API
    |
    +---- Local Database

This enables offline-first or cache-first approaches.

---

Remote + Local Data Architecture

A common mobile architecture is:

             Repository
             /        \
            ↓          ↓
       Remote API    Local DB
            |          |
            ↓          ↓
         Backend     Device

The repository decides:

• When to fetch remote data
• When to read cache
• When to update local data
• When to synchronize

---

Offline-First KMP Applications

Local storage becomes especially important when your app needs offline functionality.

For example:

User opens app
      ↓
No Internet
      ↓
Read local data
      ↓
Show cached content

When the network becomes available:

Internet Available
      ↓
Fetch latest API data
      ↓
Update Local Database
      ↓
Refresh UI

This creates a better user experience.

---

Cache vs Permanent Data

Not all local data should live forever.

Permanent Preferences

Examples:

Language
Theme
Onboarding status

Authentication Data

Examples:

Access token
Refresh token

These require secure storage and lifecycle management.

Cache

Examples:

API responses
Images
Temporary content

Cache can be deleted and recreated.

Database

Examples:

Offline orders
Messages
Saved products

These may need more durable structured storage.

---

Clearing Local Storage

Your application should know what needs to be cleared during logout.

For example:

Logout
 ↓
Clear access token
 ↓
Clear refresh token
 ↓
Clear session-specific cache
 ↓
Keep non-sensitive preferences
 ↓
Login screen

Don’t blindly clear every local preference if settings such as language or theme should survive logout.

---

Authentication and Local Storage

Authentication is one of the most important use cases.

A common architecture is:

AuthRepository
       |
       +--- AuthApi
       |
       +--- SecureStorage

After login:

Login
 ↓
API
 ↓
Tokens
 ↓
SecureStorage

On application startup:

App Start
 ↓
Read Token
 ↓
Validate/Refresh Session
 ↓
Authenticated

On logout:

Logout
 ↓
Clear SecureStorage
 ↓
Clear Session Data

---

Don’t Store Passwords Locally

A common mistake is:

email = john@example.com
password = password123

being stored on the device so the user can automatically log in later.

This is generally not the right approach.

Instead:

Password
 ↓
Login
 ↓
Access/Refresh Tokens
 ↓
Secure Storage

The application should use the authentication session rather than storing the user’s password for persistence.

---

Protecting Sensitive Data

Sensitive data includes more than tokens.

Depending on your application, it can include:

• Private credentials
• Encryption keys
• Sensitive identifiers
• Confidential application secrets
• Recovery credentials

Always classify your data before deciding where to store it.

---

Don’t Store Backend Secrets in KMP

A mobile application should never contain private backend credentials such as:

Database password
Private server secret
Master API key
Cloud service private key

KMP shared code is still shipped to client devices.

If a secret is embedded in the mobile application, assume a determined attacker may eventually extract it.

---

Storage Key Constants

Avoid repeating storage key strings everywhere.

Instead of:

storage.get("access_token")
storage.save("access_token", token)

define constants:

object StorageKeys {

    const val ACCESS_TOKEN = "access_token"
    const val REFRESH_TOKEN = "refresh_token"
    const val LANGUAGE = "language"
    const val THEME = "theme"
}

Then:

storage.save(
    StorageKeys.ACCESS_TOKEN,
    token
)

This reduces typing mistakes.

---

Creating a Preference Manager

A wrapper can make storage easier to use.

class AppPreferences(
    private val storage: PreferencesStorage
) {

    suspend fun setLanguage(
        language: String
    ) {
        storage.putString(
            StorageKeys.LANGUAGE,
            language
        )
    }

    suspend fun getLanguage(): String {
        return storage.getString(
            StorageKeys.LANGUAGE
        ) ?: "en"
    }
}

Now the rest of your application doesn’t need to know the actual storage keys.

---

Storage Layer Architecture

A scalable application can use:

                    Data Layer
                        |
          +-------------+-------------+
          |             |             |
     Preferences   Secure Storage   Database
          |             |             |
       Settings        Tokens       App Data

This separation prevents one storage technology from becoming responsible for everything.

---

Example Project Structure

A KMP project could look like:

shared/
│
└── src/
    │
    ├── commonMain/
    │   │
    │   ├── data/
    │   │   ├── storage/
    │   │   │   ├── PreferencesStorage.kt
    │   │   │   ├── SecureStorage.kt
    │   │   │   └── StorageKeys.kt
    │   │   │
    │   │   ├── database/
    │   │   │
    │   │   └── repository/
    │   │
    │   ├── domain/
    │   │   └── repository/
    │   │
    │   └── presentation/
    │
    ├── androidMain/
    │   └── storage/
    │       ├── AndroidPreferencesStorage.kt
    │       └── AndroidSecureStorage.kt
    │
    └── iosMain/
        └── storage/
            ├── IosPreferencesStorage.kt
            └── IosSecureStorage.kt

This structure is easy to scale as the application grows.

---

Storage Repository Pattern

You can also create a dedicated repository.

interface UserSettingsRepository {

    suspend fun getTheme(): String

    suspend fun setTheme(
        theme: String
    )

    suspend fun getLanguage(): String

    suspend fun setLanguage(
        language: String
    )
}

Implementation:

class UserSettingsRepositoryImpl(
    private val storage: PreferencesStorage
) : UserSettingsRepository {

    override suspend fun getTheme(): String {
        return storage.getString(
            StorageKeys.THEME
        ) ?: "system"
    }

    override suspend fun setTheme(
        theme: String
    ) {
        storage.putString(
            StorageKeys.THEME,
            theme
        )
    }

    override suspend fun getLanguage(): String {
        return storage.getString(
            StorageKeys.LANGUAGE
        ) ?: "en"
    }

    override suspend fun setLanguage(
        language: String
    ) {
        storage.putString(
            StorageKeys.LANGUAGE,
            language
        )
    }
}

This keeps storage details away from the UI.

---

Local Storage With ViewModel

The ViewModel can use a repository:

class SettingsViewModel(
    private val repository: UserSettingsRepository
) {

    suspend fun changeTheme(
        theme: String
    ) {
        repository.setTheme(theme)
    }
}

The UI doesn’t need to know whether the data is stored using:

DataStore
UserDefaults
Database
Custom storage

That implementation detail stays inside the data layer.

---

Reactive Storage With StateFlow

For settings that should update the UI immediately, you can expose state.

For example:

private val _theme =
    MutableStateFlow("system")

val theme: StateFlow<String> =
    _theme.asStateFlow()

When the stored value changes:

Storage
 ↓
Repository
 ↓
ViewModel
 ↓
StateFlow
 ↓
UI

This works particularly well with reactive UI architectures.

---

Local Storage Testing

Storage code should be tested.

For example:

Save Value
 ↓
Read Value
 ↓
Verify Value

Test cases should include:

• Save string
• Read string
• Update string
• Remove value
• Clear values
• Missing value
• Boolean preferences
• Token storage
• Logout cleanup

---

Testing With Fake Storage

Because we created an interface, testing becomes easier.

Example:

class FakeStorage : PreferencesStorage {

    private val values =
        mutableMapOf<String, String>()

    // Test implementation
}

Then:

ViewModel
 ↓
Fake Storage

instead of:

ViewModel
 ↓
Real Device Storage

This makes unit tests faster and more predictable.

---

Common Local Storage Mistakes

Mistake 1: Using Preferences as a Database

Don’t store hundreds or thousands of records as individual preference keys.

Use a database for structured datasets.

---

Mistake 2: Storing Tokens Insecurely

Avoid using ordinary preferences as your only protection for sensitive authentication credentials.

---

Mistake 3: Storing Passwords

Don’t save user passwords simply to maintain login state.

---

Mistake 4: Storing Secrets in Shared Code

KMP shared code is client-side code.

Don’t embed private backend secrets.

---

Mistake 5: Mixing Storage Logic With UI

Avoid:

Screen
 ↓
DataStore

Prefer:

Screen
 ↓
ViewModel
 ↓
Repository
 ↓
Storage

---

Mistake 6: Clearing Everything on Logout

Logout should remove authentication/session-specific information without unnecessarily deleting harmless user preferences.

---

Best Practices for KMP Local Storage

1. Choose Storage Based on Data Type

Use:

Preferences → Small settings
Secure Storage → Sensitive credentials
Database → Structured data
Cache → Replaceable data
Files → Large binary data

---

2. Create Shared Abstractions

Use interfaces for:

PreferencesStorage
SecureStorage
Database

---

3. Keep Platform APIs Isolated

Android-specific and iOS-specific APIs should stay behind platform implementations.

---

4. Secure Authentication Data

Tokens should be protected appropriately.

---

5. Keep Storage Keys Centralized

Avoid hardcoding keys across many files.

---

6. Test Storage

Make sure save/read/remove behavior works correctly.

---

7. Don’t Store More Than You Need

Local storage should contain only the information the application actually requires.

---

8. Consider Data Lifecycle

Ask:

How long should this data exist?

For example:

Theme → Long-term
Access Token → Until session ends/rotates
Cache → Temporary
Offline Database → Potentially long-term

---

DataStore vs Preferences vs Secure Storage

These terms can sometimes become confusing.

A useful way to think about them is:

Preferences
     ↓
What settings should the app remember?

DataStore
     ↓
A modern Android mechanism for storing preferences/structured data.

Secure Storage
     ↓
Where should sensitive credentials be protected?

DataStore itself should not automatically be treated as a secure credential vault simply because it is a modern storage API.

For highly sensitive credentials, use an appropriate secure-storage architecture.

---

Recommended KMP Storage Architecture

For a production application, a practical architecture is:

                    KMP Application
                          |
                     Repository
                          |
          +---------------+---------------+
          |               |               |
          ↓               ↓               ↓
     Preferences     Secure Storage    Database
          |               |               |
          ↓               ↓               ↓
       Settings          Tokens        App Data
          |               |               |
     +----+----+      +---+---+       +---+---+
     |         |      |       |       |       |
 Android      iOS  Android   iOS   Android    iOS
 DataStore UserDefaults Secure  Keychain  DB      DB

The exact database and secure-storage technologies can vary by project.

---

Complete KMP Local Storage Data Flow

A typical application can follow:

User Action
     ↓
UI
     ↓
ViewModel
     ↓
Use Case
     ↓
Repository
     ↓
Storage Abstraction
     ↓
Platform Implementation
     ↓
Device Storage

For authentication:

Login
 ↓
Auth Repository
 ↓
Ktor API
 ↓
Tokens
 ↓
Secure Storage

For preferences:

Theme Selection
 ↓
Settings Repository
 ↓
Preferences Storage
 ↓
Device

For offline data:

API
 ↓
Repository
 ↓
Database
 ↓
Offline UI

---

Frequently Asked Questions

What is local storage in Kotlin Multiplatform?

Local storage is the mechanism used to persist application data on Android, iOS, and other supported platforms.

Can I use DataStore in Kotlin Multiplatform?

DataStore is primarily associated with Android. For KMP, you should use a multiplatform-compatible approach or create a shared storage abstraction with platform-specific implementations.

What should I use to store preferences in KMP?

Use a multiplatform-compatible preferences solution or create a PreferencesStorage abstraction backed by suitable platform storage.

Where should JWT tokens be stored in KMP?

Use secure platform-specific storage. Android can use a Keystore-backed approach, while iOS commonly uses Keychain.

Should I store access tokens in DataStore?

For sensitive authentication credentials, ordinary preference storage should not be treated as the preferred secure storage mechanism. Use a dedicated secure-storage solution.

Can KMP share local storage code?

Yes. The storage interface, repositories, data models, and business logic can be shared while platform-specific implementations handle native storage APIs.

Is UserDefaults secure?

UserDefaults is intended for ordinary application preferences, not as a secure vault for authentication secrets.

Is DataStore encrypted?

DataStore should not automatically be assumed to provide the same security properties as a dedicated secure credential store. If sensitive information requires encryption or protected key management, design an appropriate secure-storage solution.

Can KMP store offline data?

Yes. Kotlin Multiplatform applications can use shared database/storage solutions to support caching and offline functionality.

Should local storage replace a backend database?

No. Local storage and server-side databases have different purposes. Local storage is primarily for device-side persistence, caching, preferences, and offline functionality.

---

Conclusion

Local storage is an essential part of modern Kotlin Multiplatform applications.

The key is to understand that not all data should be stored using the same technology.

A good KMP architecture separates storage based on the type and sensitivity of the data:

Preferences
→ Theme, language, onboarding

Secure Storage
→ Access tokens, refresh tokens, sensitive credentials

Database
→ Products, orders, messages, offline data

Cache
→ Replaceable API data

Files
→ Images, documents, videos

For KMP applications, the best architecture is usually to define shared abstractions and keep platform-specific implementations behind those abstractions.

For example:

commonMain
    ↓
PreferencesStorage
SecureStorage
Database
    ↓
androidMain / iosMain
    ↓
Platform-specific implementations

This approach keeps your application modular and makes it easier to share business logic between Android and iOS.

When building authentication systems, remember that secure token storage is different from ordinary preferences. Access tokens and refresh tokens should be handled with appropriate platform security mechanisms, while settings such as theme and language can use ordinary preference storage.

The goal of Kotlin Multiplatform isn’t to force Android and iOS to use exactly the same storage technology. Instead, it allows you to share the storage architecture, interfaces, repositories, and business logic while each platform uses the most appropriate implementation underneath.