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?

Is https://search.maven.org/ down? No matter what I search, it doesn't find any results

How do you organize your package names? Do you do 1 artifact == 1 packageName? Or is it OK to reuse packageNames between artifactIds?

Need API advice. Have a library, kmp-file , and want to add an async API in order to support more Js/WasmJs functionality. • Currently, only supporting use of

Node.js

synchronous API under the hood. • Adding the Async API would allow use of

Node.js

callback API. • Adding the Async API would allow supporting (in a limited context such as WebWorkers) browser functionality. For Js/WasmJs I need the

suspendCancellableCoroutine

function from

kotlinx-coroutines

All other targets (Jvm/Native) would simply call the blocking functions from their

xxxAsync()

actual function definitions Should I 1. Suck it up and add the

kotlinx-coroutines

dependency to the Js/WasmJs source sets 2. Expose public functions for Js/WasmJs with a

Continuation

argument marked as

@OptIn(InternalApi::class)

and have a separate extension module

kmp-file:async

with the

kotlinx-coroutines

dependency and all

xxxAsync()

functions defined. 3. Something else? Like wrapping the callback function from Kotlin in

js("async { block() }")

I would really like to avoid the additional dependency...

I have a question, do the kotlinx-io contributors work on the library full time, or as a side project? Seems the library still has a lot of works to do.

On KMP with interfaces, is binary compatibility preserved if I add a new member as long as the new member has a body? The answer seems to be yes (at least on the multiplatform targets I tested with), but I wasn't able to find any reassurance while poking through documentation

Anyone have experience with binary compatibility tooling in a mixed java/kotlin codebase? Is using binary-compatibility-verifier sufficient for tracking both Java and Kotlin changes, or is there Java-specifiic tooling I should consider as well?

I'm working on my first library (its an android library). It's definitely been a bit of a journey to get it "production" ready. on of my release readiness steps is trying to comb over all of my dependencies and whether or not they should be defined as api vs implementation. are their any hard/fast rules regarding api vs impl. should i just make every dep api?

Anyone know if I have an inline function with a

contract

defined, and another

inline

function points to it, do I also have to specify the

contract

in that inline function? E.g. Does

foo

also need the

contract

defined?

public inline fun foo(block: () -> Unit): Boolean = bar(block)

@OptIn(ExperimentalContracts::class)
public inline fun bar(block: () -> Unit): Boolean {
    contract { callsInPlace(block, InvocationKind.AT_MOST_ONCE) }
    // ...
}

Hello, library author noob here. I'm prepping to release my first library (an android library to be exact) and since it's my first time, I'm looking for any advice in the form of a pre-release checklist. Similar to how android has a checklist for apps https://developer.android.com/studio/publish/preparing I was wondering if anyone has a checklist handy for publishing a library. Here's the list that I've put together so far: 1. Create dokka docs and ship with the library 2. Go over your public API in your classes 3. Go over your dependencies to make sure you don't pollute consumers classpath 4. Proguard? (is that a thing for lib development) 5. Anything else?

Poll: Do you proguard your library before distribution?

If I change a class from

public final class MyClass(something: Any)

to

public open class MyClass(something: Any)

, will that break backward compatibility?

When you're building a library (non android library) and you want to include values in the build at compile time, what's the "goto" way to do that? Is it just a properties file or env vars? Basically... im a long time android dev (just getting into library dev) and I'm used to using

BuildConfig

to insert api keys and other values into my build to be able to access programatically. But in a plain' ol kotlin/java library there is no BuildConfig. I have seen some other libraries or plugins that attempt to be BuildConfig but in the regular library world but that just seems... off?

Just learned about explicit api mode. Seems like a no brainer for every library to enable that flag. Am I wrong in thinking that? Do you enable explicitApi mode?