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.
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)
1 year ago
- IO is definitely the big one, as everyone else is mentioning
- Multiplatform parameterized tests
1 year ago
• 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.
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!