Kotlin Multiplatform Help

Adding dependencies on multiplatform libraries

Every program requires a set of libraries to operate successfully. A Kotlin Multiplatform project can depend on cross-platform libraries that support multiple target platforms, platform-specific libraries, and other multiplatform projects.

If you have experience developing Android apps, adding a multiplatform dependency is similar to adding a Gradle dependency to a regular Android project. The main difference is that you need to add the dependency to a specific source set rather than to the module as a whole.

This page describes the overall approach to managing dependencies in a multiplatform project. For some platform specifics, see Adding Android dependencies and Adding iOS dependencies.

Dependency types

There are two types of dependencies that you can use in Kotlin Multiplatform projects:

  • Multiplatform dependencies. These are multiplatform libraries that support multiple targets and can be used in the common source set.

    Many modern Android libraries already have multiplatform support, like Koin, Coil, and SQLDelight.

    Find more multiplatform libraries on klibs.io, a catalog of published Kotlin Multiplatform libraries.

  • Native dependencies. These are platform-specific libraries from corresponding ecosystems. In native projects, you typically manage these libraries through platform-specific tools such as Gradle for Android and Swift Package Manager for iOS.

    When you work with a multiplatform project module, you typically still need native dependencies to use platform APIs such as secure storage, system calls, and so on. In the build script, you specify native dependencies in the configuration of native source sets, for example, androidMain and iosMain.

For both types of dependencies, you can use local and external repositories.

Gradle version catalogs

When using Gradle, we recommend using version catalogs to manage dependencies.

With version catalogs, you define the artifact name and the version in the catalog and then reference this definition in build script files.

For example, here's a basic catalog file:

# libs.versions.toml, a default catalog file [versions] my-library = "1.0" [libraries] my-library = {module = "com.example:my-library", version.ref = "my-library"}

And here's an example of using that catalog to add a dependency:

// build.gradle.kts dependencies { // 'libs' is the first part of the catalog file name // 'my.library' is the name of the artifact without // the namespace and dots instead of dashes implementation(libs.my.library) }

Dependencies on core Kotlin libraries

Standard library

Each source set in a Kotlin Multiplatform project automatically depends on the Kotlin standard library (kotlin-stdlib). The version of the standard library is the same as the version of the applied Kotlin Multiplatform Gradle plugin.

For platform-specific source sets, Gradle automatically uses the corresponding platform-specific variant of the library, while the common standard library is added to the rest. For JVM targets, the Kotlin Gradle plugin selects the appropriate JVM standard library depending on the compilerOptions.jvmTarget compiler option of your Gradle build script.

Learn how to change the default kotlin-stdlib dependency resolution.

Testing libraries

For multiplatform tests, the kotlin.test API is available. As it is a multiplatform library, you can add test dependencies to all source sets by specifying a single dependency for the commonTest source set:

kotlin { //... sourceSets { // Makes kotlin.test classes available in all test source sets commonTest.dependencies { implementation(kotlin("test")) } } }
kotlin { //... sourceSets { // Makes kotlin.test classes available in all test source sets commonTest { dependencies { implementation kotlin("test") } } } }

kotlinx libraries

kotlinx libraries are multiplatform libraries maintained by the core Kotlin team at JetBrains (primary examples are kotlinx.serialization and kotlinx.coroutines).

As with any other multiplatform library, to add a dependency, refer to a library artifact in the corresponding source set.

Dependencies on Kotlin Multiplatform libraries

You can add dependencies on libraries that have adopted Kotlin Multiplatform, such as SQLDelight. The authors of such libraries usually provide guides for adding their dependencies to your project.

Look for Kotlin Multiplatform libraries on klibs.io

Sample Gradle version catalog

When using Gradle, it's recommended to use version catalogs. Here's the version catalog that defines all libraries used in the examples below:

[versions] ktor = "3.5.2" kotlinx-coroutines = "1.11.0" sqlDelight = "2.3.2" [libraries] ktor-clientCore = { module = "io.ktor:ktor-client-core", version.ref = "3.5.2" } kotlinx-coroutinesCore = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "1.11.0" } sqldelight-nativeDriver = { module = "com.squareup.sqldelight:native-driver", version.ref = "2.3.2" }

Library shared for all source sets

If you want to have access to the library from all source sets or to write shared code using it, add it only to the common source set. The Kotlin Multiplatform Gradle plugin automatically resolves the corresponding platform-specific artifacts for other declared source sets.

kotlin { //... sourceSets { commonMain.dependencies { implementation(libs.ktor.clientCore) } androidMain.dependencies { // The dependency on a platform-specific part of ktor-client // is resolved at build time } } }
kotlin { //... sourceSets { commonMain { dependencies { implementation(libs.ktor.clientCore) } } androidMain { dependencies { // The dependency on a platform-specific part of ktor-client // is resolved at build time } } } }

Libraries to be used in specific source sets

If you want to use a multiplatform library just for specific source sets, you can add it exclusively to them. Then the library declarations are only available in those source sets.

Use a common library name in such cases, not a platform-specific one: the Kotlin Multiplatform Gradle plugin resolves such references automatically. The exact name is likely covered in the library's documentation.

Here's an example that uses native-driver instead of native-driver-iosx64 for platform-specific SQLDelight:

kotlin { //... sourceSets { commonMain.dependencies { // kotlinx.coroutines is available in all source sets implementation(libs.kotlinx.coroutinesCore) } androidMain.dependencies { // Place for Android-specific dependencies } iosMain.dependencies { // SQLDelight is available in the iOS source set, // but not in the Android or common source sets implementation(libs.sqldelight.nativeDriver) } } }
kotlin { //... sourceSets { commonMain { dependencies { // kotlinx.coroutines is available in all source sets implementation(libs.kotlinx.coroutinesCore) } } androidMain { dependencies { // Place for Android-specific dependencies } } iosMain { dependencies { // SQLDelight is available in the iOS source set, // but not in the Android or common source sets implementation(sqldelight.nativeDriver) } } } }

Dependency on another multiplatform project

One multiplatform project can depend on another. To set this up, add a Gradle project dependency to the source set that needs it. If you want to use a project dependency in all source sets, add it to the common source set. In this case, the compiler automatically provides platform-specific artifacts of the project to other source sets.

kotlin { //... sourceSets { commonMain.dependencies { implementation(project(":some-other-multiplatform-module")) } androidMain.dependencies { // Platform-specific declarations of :some-other-multiplatform-module // will be resolved automatically } } }
kotlin { //... sourceSets { commonMain { dependencies { implementation project(':some-other-multiplatform-module') } } androidMain { dependencies { // Platform-specific declarations of :some-other-multiplatform-module // will be resolved automatically } } } }

What's next?

Check out other resources on adding dependencies in multiplatform projects and learn more about:

Get help

01 October 2026