Where do Kotlin Multiplatform dependencies live, and what gets scanned?

In Kotlin Multiplatform, dependencies are declared per source set, such as commonMain, androidMain and iosMain, not once per module. A complete inventory therefore has to cover every source set and target. Reading only the Android dependencies, or only the common block, will miss components that ship in other builds.

How the declarations work

The Kotlin documentation explains that each source set has its own dependencies block. Dependencies in commonMain are available to all targets, and only multiplatform libraries can go there because common code must compile for every declared target. Platform source sets hold platform-specific dependencies.

kotlin {
    sourceSets {
        commonMain.dependencies {
            implementation(libs.kotlinx.coroutinesCore)
        }
        androidMain.dependencies {
            // Android-specific dependencies
        }
        iosMain.dependencies {
            implementation(libs.sqldelight.nativeDriver)
        }
    }
}

In the docs example, the SQLDelight native driver is available in the iOS source set but not in the Android or common source sets.

You declare one name, Gradle resolves many artifacts

You declare a common library name, not a platform-specific one. The Kotlin Multiplatform Gradle plugin resolves the matching platform artifacts for each target. The standard library is added to every source set, with the platform variant in platform source sets. Project dependencies work the same way.

That is convenient for developers and awkward for inventory, because one line in a build file turns into several artifacts, different for each target.

What to check in your inventory

Gradle version catalogs are the recommended way to manage versions here, and the Kotlin docs recommend them for Multiplatform projects. Remember that catalog versions are requests, not guarantees.

Steps to build a trustworthy inventory

1. List the targets the project builds: Android, iOS, desktop, web, server.
2. For each target, resolve its runtime classpath or equivalent, not only the declared list.
3. Combine the results into one SBOM, tagging which target each component belongs to.
4. Scan the combined list, then filter findings by the target that ships.
5. Repeat on every release, since resolved versions can change without a build file change.

For the broader picture of a mobile project spanning several package managers, see how many dependency ecosystems are in a React Native or Flutter app, which applies to Kotlin Multiplatform as well.

Try it yourself

Click through it at your own pace, or open it full screen.

Look at how direct and transitive components are listed together, then ask whether your own inventory shows each target the same way.

Safeguard's SBOM and dependency scanning build an inventory from a repository you connect, and the free scan at gold.safeguard.sh/scan is a way to see what it finds.

Quick check

Sources

• Kotlin: Add dependencies to a multiplatform project

Last reviewed: 19 October 2026.