Should all KMP libraries target all available Kotlin platforms? For example, a KMP library for mobile apps (Android/iOS). Is it ok to have only Android/iOS* platform targets? Or do you expect to have other targets available but just a message saying the library doesn't support it?

Hi, can someone help with this?: https://kotlinlang.slack.com/archives/C19FD9681/p1740569844948529

Let's say I have two interfaces

interface FooA {
    fun foo(name: String, value: Int)
}

interface FooB {
    fun foo(value: Int)
}

The two interfaces represent two different ways of interacting with a single entity. In some contexts, the library provides an instance of the first interface, and in some contexts, the library provides an instance of the second interface. However, since they are both used to interact with a single entity, it's more convenient for the library author to implement a single instance that can be viewed as both:

private class FooImpl : FooA, FooB {
    override fun foo(name: String, value: Int) {}
    override fun foo(value: Int) {}
}

So far, everything is good I think. I think however there is a risk that a user would use a cast to change their access context even if it's not allowed.

withFooA {      // provided by the library
    it as FooB  // will succeed because FooImpl does implement FooB
    it.foo(4)   // illegal call to FooB.foo in the context of FooA, but will compile and run
}

Should this be considered a risk? Should I split the implementations of the two interfaces to stop this usage? Or should I consider that this is bad code anyway and I should ignore the fact that users could write it?

👋 I have a kmp lib that is a tool for developers. Because of that, there should be 2 variants of the library. One for debug (the library code is fully integrated into developer artifact - apk, jar, ...) and one for release (the library code that is integrated into developer artifact has only the public code with empty bodies). How would you design this in order to avoid to switch between 2 variants each time when the developer needs a new artifact? Unfortunatly, in kmp we do not have debugImplementation and releaseImplementation.

What is the number of overloads to a single function that is simply too many? I have a case where I would need ~600 overloads for a single function, and that sounds like a bad idea.

Hey folks, question about

@UnsafeVariance

. If I am defining some

Container<out T>

class and I want one of its methods to return

Optional<T>

(for Java users), then is it safe/reasonable to do

Optional<@UnsafeVariance T>

? I don't want to do

Optional<out T>

since that will end up being

Optional<? extends T>

for Java users, which is annoying to work with. I think using

@UnsafeVariance

here makes sense because

Optional

is an immutable container so you can only get

T

out of it; you can't put a new

T

into an existing

Optional<T>

. It's just that Java obviously does not define

Optional

with

out T

at it's declaration (since it's not Kotlin) Am I making sense? Am I missing anything here?

Guys, how do you use

@Sample

? Usually samples are not part of the main source set, so doesn't that mean samples will always not resolve?

I have different kotlin multiplatform libraries and I am publishing them on github CI. I keep getting flaky fails with the error

* What went wrong:
Execution failed for task ':kotlinStorePackageLock'.
> Lock file was changed. Run the `kotlinUpgradePackageLock` task to actualize lock file

Simply rerunning the action makes the build pass. To mitigate this, I have tried running the task

kotlinUpgradePackageLock

on CI, before running the build task, but even, that task itself fails sometimes. Anyone facing this issue? How do I solve this?

Hi there, I have a kotlin multiplatform library (published on Maven Central), that targets android, jvm, js, wasm, and ios. This library has a lot of common code, and a few platform specific code on every listed platform above. I am depending on this library, on an application that targets ios, jvm, wasm and android. When compiling to ios, jvm, and wasm everything works well. But when compiling the android part, compiler fails to resolve those platform specific. What is the issue here?

Hey guys! I have a mono repo with lots of gradle modules. I now want to publish some of them as external libraries (really just one, but that transitively will require others). The issue is that I want to be on the latest Kotlin version internally, but allow users of my library to use let’s say Kotlin 1.8. (What in your view is a reasonable min requirement at this point btw?) Afaik I can only have one Kotlin gradle plugin in the classpath. So does this require a gradle composite build? Or is it enough to set api and language compatibility and make sure to depend on older versions of f.ex ktor, serialisation etc? (Even that seems annoying as I will have two versions of the same libs in libs.versions.toml right? 🤔)

Hey guys 👋 just wondering if some of you succeeded in migrated to new Maven Central API. For me package upload is taking x8 times initial time compared to s01 server 🐌🐌🐌 taking me 38 min to release 😕

Hi all. Trying to understand why my publishing task is getting skipped with here

Task :publishAllPublicationsToMavenCentralRepository UP-TO-DATE

I was able to run this locally but seems to be always skipping on CI 🤔 has anyone run into this problem before?

I have a mountain of open source libraries at Lightning Kite, and while there's still polish I want to do on some of them before I publicize them, I honestly have no idea how to begin publicizing them. How do you guys go about publicizing your libraries for adoption?

Hey everyone, i'm building a kmp library and i'm trying to include it in debug builds in my Android app as a composite build, i have a simple setup

settings.gradle

val isDebug = gradle.startParameter.taskNames.any {
    it.contains("debug", ignoreCase = true)
}

if (isDebug) {
    println("Including local KMP library project for debug")
    includeBuild("../sdk")
}

and as a dependency

implementation("dev.ahmedmourad.sdk:core")

it builds and compiles fine, problem is that the IDE (both Android Studio and IntelliJ) fail to resolve anything from the sdk, it's all in red but it build fine I have Android Studio 2025.1.1 and IntelliJ 2025.1.1.1, both have the Kotlin Multiplatform plugin installed If anyone has any idea how to get around this please let me know, thank you!

I built an SDK for Android, which uses KTOR internally. I use KTOR version 3.0.0. My main client informed me they have a transitive dependency to KTOR 2.3.13 so they experience a crash. I see many suggestions online for shadowing, fat aar. Assuming the client is not ready to upgrade to 3.0.0, what is my best course of action?

I have a Java library setup with Gradle, that I am converting to Kotlin. Before I start converting it, I'd like to dump the ABI so that I can make sure that there are no breaking changes after converting to Kotlin. What tool can I use that will dump the Java ABI, and then also be able to compare with the Kotlin ABI to make sure there are no breaking changes?

I've got questions about the grants for open-source libraries (https://kotlinfoundation.org/grants/) - is there a specific place I can ask them? I'm just stupid it's at #C04RQTY5PBP.

Hey folks 👋 Working on a library and a new major version is coming up. I'm deprecating a bunch of things with

@Deprecated

, but this obviously gives warnings on all usages of the given classes. The aim is to warn users to not use these classes, but internally I have to keep support for them. Is there a way to suppress deprecation warnings of my own code without suppressing deprecations from let's say other libraries etc?

Somewhat related: this is probably debatable, but I wish typealiases of a deprecated type would not trigger a deprecation warning. This would help libraries “soft rename” types.

@Deprecated("Use NewName instead")
class OldName

typealias NewName = OldName

// ...
val x = OldName() // <- warning
val y = NewName() // <- warning too, bummer.

Is anyone here actively maintaining a KMP UI framework that isn't CMP? We are (KiteUI), but I'm wondering who else is - I think Compose Web's approach (canvas-based rendering) isn't a good idea due to size/performance/accessibility and it seems there are at least some others who agree with the sentiment. I'm wondering if it might be possible for us to unify our effort? It might be hopeless since we'll probably all have different visions of what it should be, but I'd at least like to see.

Looking for feedback: https://github.com/lightningkite/kiteui What would keep you from trying to adopt this framework?

What is good polish in a library for people to use? Unit tests, docs, coverage, markers, publication, anything else? We have internal stuff, but the transition from internal to public is a struggle for me. I'm still figuring out how to bridge the gaps.

Hey everyone! Running into a weird KMP issue that's got me stumped. I've tried clean builds with refresh dependencies, invalidating IDE cache - nothing's working. Setup: • 3 KMP libraries, all on Kotlin 2.2.0 + Compose 1.8.2 • Publishing to private GitHub repo • 2 libraries have iOS targets commented out, 1 has them active (via convention plugin) • CI uses Ubuntu runners so iOS binaries aren't published (intentional) Convention plugin config: kotlin

import org.gradle.accessors.dm.LibrariesForLibs
plugins {
  id("com.android.kotlin.multiplatform.library")
  id("id-cmp")
}
val libs = the<LibrariesForLibs>()
kotlin {
  jvm("desktop")
//  iosX64()
//  iosArm64()
//  iosSimulatorArm64()
  androidLibrary {
    experimentalProperties["android.experimental.kmp.enableAndroidResources"] = true
    compileSdk = libs.versions.android.compileSdk.get().toInt()
    minSdk = libs.versions.android.minSdk.get().toInt()
  }
}

The Problem: For the 2 libraries WITHOUT iOS targets - when I try to import them in feature modules of separate apps, I can't access anything from

commonMain

. However, I CAN access them from

androidMain

and

desktopMain

source sets. Plot twist: The same applications can access classes/packages from their own

composeApp

modules just fine. Anyone seen this before or have ideas? Is this a known KMP issue with partial target configurations?

KMP library authors, did you bump your KGP to 2.2 already?

Just submitted KiteUI and service abstractions to the Kotlin Foundation Grant program. I'm not terribly hopeful honestly, but still excited!

Hello 👋. I've been thinking about the challenges of maintaining backwards compatibility in libraries and wondered at what points would you use the Deprecation Levels? I've been using

WARNING

by default and then removing the signatures on a major version bump. But why, for example, shouldn't I just mark everything as

HIDDEN

by default? What approaches do you take?

I'm switching to the new KGP-based abi validation. Is this on purpose that

checkLegacyAbi

is not a dependency of

build

anymore? My CI builds are mostly running

./gradlew build

so they have effectively not been checking the ABI any more.

Also somewhat related,

legacy

feels weird, my current ABI is not "legacy", it's just a tiny bit "older" than the tip of

main

Hi all 👋 , In this talk by Arkadii Ivanov about Kotlin Library compatibility - . It is mentioned that a method changing to

synthetic

is ABI compatible. Could anyone please help share some resources about this?

Hi all 👋 , Should we exclude generated files from databinding, dagger, etc in API dump when using kotlin binary compatibility validator plugin?