By now, you've likely built a few KMP projects that live and die within a single repository. But the real power of Kotlin Multiplatform comes when you package your logic into a library that other teams—or your future self—can actually use. Let's use a hypothetical library called KlockWork, a small utility for formatting timestamps across Android, iOS, and Desktop, as our example.

Do I have to publish a separate library for every single target?

This is the first thing that usually trips people up. You might think you need to publish klockwork-jvm, klockwork-iosarm64, and klockwork-js as entirely different projects. You don't. Gradle handles this via something called Gradle Module Metadata.

When you publish a KMP library, Gradle creates a "root" publication. This root publication doesn't contain code itself; instead, it acts as a map. When a consumer adds implementation("com.yourname:klockwork:1.0.0") to their project, Gradle looks at that map, checks which platform the consumer is building for, and automatically pulls the correct platform-specific artifact. It's honestly a bit of magic, and it's why KMP feels so seamless for the end user.

How do I actually set up the publishing block in my Gradle file?

You'll need the maven-publish plugin. I've found that the most straightforward way to handle this is by configuring the publishing block in your build.gradle.kts. Here is a stripped-down version of what that looks like for our KlockWork library:

plugins {
    kotlin("multiplatform")
    `maven-publish`
}

group = "com.yourname.klockwork"
version = "1.0.0"

publishing {
    publications {
        // The KMP plugin automatically creates publications for each target
        // but you can customize them here if you need to add POM info
    }
    repositories {
        maven {
            name = "OSSRH" // This is the standard Sonatype repo for Maven Central
            url = uri("https://s01.oss.sonatype.org/service/local/staging/deploy/maven2/")
            credentials {
                username = project.property("ossrhUsername").toString()
                password = project.property("ossrhPassword").toString()
            }
        }
    }
}

Notice I'm using project.property for the credentials. Whatever you do, do not hardcode your passwords in the build script. Put them in your local gradle.properties file and add that file to your .gitignore. I learned that the hard way early in my career, and it's a mistake you don't want to make.

What's the deal with GPG signing and Maven Central?

If you're just sharing a library with a coworker, you can just publish to mavenLocal() and call it a day. But if you're going for the big leagues (Maven Central), they require every artifact to be signed with a GPG key. This proves that the code actually came from you and wasn't hijacked by someone else.

To do this, you'll need to install GPG and generate a key pair. Then, you add the signing plugin to your build script. It looks something like this:

plugins {
    signing
}

signing {
    sign(publishing.publications)
}

Fair warning: getting your first package accepted into Maven Central is a bureaucratic nightmare. You have to create an account, verify your identity, and wait for approval. If you're just prototyping or doing an internal company project, I highly recommend using JitPack or a private GitHub Packages repository instead. They skip the GPG and verification headaches entirely.

📋 Practical Task

Configure a Local Maven Publication for KlockWork

Instead of dealing with the complexity of Maven Central, your task is to set up a local publication flow. This allows you to test your library in a separate "consumer" project without actually uploading it to the internet.

1. Create a new KMP library project named KlockWork with at least two targets (e.g., jvm() and iosArm64()).
2. Apply the maven-publish plugin in your build.gradle.kts.
3. Define the group as "com.mentorship.klockwork" and the version as "1.0.0-SNAPSHOT".
4. Run the Gradle task publishToMavenLocal from the terminal or the Gradle tool window.
5. Create a second, completely separate Kotlin project. In its settings.gradle.kts, add mavenLocal() to the dependencyResolutionManagement block.
6. Try to implement the KlockWork library in this second project using the coordinates you defined.