Hey folks! The KMM team is wondering what libraries you lack the most? Please share areas where you would like to have more libraries in the comments.

Url parsing! (Although there might be something in ktor now that I think about it?)

There is but it feels somewhat limited.

Why not Okio for IO? (don't want to divert this thread though so I could take this question somewhere else)

For something as fundamental as IO, I would much rather use a 1st party library. Although if Jetbrains officially say they are never going to revisit kotlinx-io, then I'll use okio. Otherwise, I'd rather not get too involved with fragmentation.

well, since Android 5.0 httpurlconnection uses okhttp internally, so I’d argue that okio is somewhat 1st party 🙂

DI and mocking

Having 1st party, multiplatform DI library would be really awesome @Dominaezzz this answer from Kotlin’s team member seems to indicate there is not going to be any development effort in a near future in kotlinx-io: https://www.reddit.com/r/Kotlin/comments/nm2eaf/kotlin_team_ama_3_ask_us_anything/gzn9abw

IO and DI

DI 💉 and

kotlinx-coroutines-test

🙏

Ah yeah, coroutines test plus fix this issue before IO and DI https://github.com/Kotlin/kotlinx.coroutines/issues/1204

Regarding IO, it would be nice to have something that could integrate with kotlinx-serialization, whether its okio or kotlinx-io.

Assuming we’re talking about first-party libraries to address gaps that are often provided by frameworks like Java or Apple Foundation. • UUIDs (currently using https://github.com/benasher44/uuid) • Ability to read/write gzip streams (currently using JVM, so this part of my codebase is not multiplatform) • Database (wrote a wrapper to support wrapping DBs in the future, although currently using currently using Exposed in the JVM target. This is for a non-mobile app, so SQLDelight isn’t ideal). • Coverage (currently using Jacoco for commonMain/jvmMain but lack coverage for code under jsMain and native targets)

- IO is definitely the big one, as everyone else is mentioning - Multiplatform parameterized tests

• Coroutines testing in MPP. With time control • Official logging API in MPP. Community can build implementation. But I think Kotlin MPP should have unified API which should be used in all MPP kotlin libraries. Current situation is that there is like 10 different interfaces to implement to have unified logging when app is using http lib, AB testing, graphql client, auth, analytics, etc, because every lib provides it's own.

Yes, logging! I’d love to see an official SLF4J-type thing for Kotlin

Another thing I've seen people looking for a bunch (though I don't know that it needs a first party solution) is mocking

By the way, @Dominaezzz, you can check out this project for multiplatform cryptographic primitives: https://github.com/appmattus/crypto and also : https://github.com/korlibs/krypto

In the C++ world there are the Boost libraries. Many of the libraries developed under that project eventually get folded into the standard library. I think an organization like this would be good for Kotlin Multiplatform library development and the community - using only Kotlin and no platform specific library dependencies so it is truly multiplatform. The community appears to be quite fractured in developing many libraries having overlapping feature sets and few with critical mass of adoption. @Big Chungus has developed this nice catalog of all the Kotlin libraries on Github - 4479 in total!

Firebase.

mocking library