Multiplatform Libraries

The main ones are kotlinx-coroutines-core for async work, kotlinx-serialization for turning objects to/from JSON, kotlinx-datetime for dates and times, and kotlinx-io for reading and writing bytes. All work in shared code.

expect declares a shared API in common code with no body; each platform (Android, iOS, JS) provides an actual implementation. So you call one function everywhere and the right platform version runs.

List, Set and Map are read-only views — they have no add/remove. MutableList, MutableSet, MutableMap add modification methods. buildList gives you a mutable list to fill in a lambda and returns it as a read-only List.

You mark a class with @Serializable and a compiler plugin generates the conversion code at build time. Because it doesn't use runtime reflection, it works on platforms like iOS and JS where reflection isn't available.

kotlin.random.Random is the multiplatform random generator. Use Random.nextInt() for one-off values, and create Random(seed) with a fixed seed to get the same sequence every run, on any platform.

A multiplatform library publishes a small common piece plus one piece per platform. Gradle reads extra metadata that lists all these pieces and automatically picks the correct one for each target you build.

Dispatchers.Main is one common name, but each platform runs it on its own UI loop: Android's main Handler, iOS's main run loop, JS's event loop. On Android you must add the kotlinx-coroutines-android artifact so the real Main dispatcher is present.

Ktor gives you one common HttpClient, but the actual network calls run through a pluggable engine you choose per platform: OkHttp or CIO on Android, Darwin on iOS, Js on the web. You configure the client in shared code and supply the engine per target.

kotlin.math gives you sqrt, sin, pow, abs, PI and so on for every platform, so commonMain doesn't need java.lang.Math. It follows IEEE-754: things like 0.0/0.0 give NaN, and there are safe rounding helpers like roundToInt.

Collection operators like map/filter build a new list at each step. A Sequence is lazy: it processes one element through all steps before moving on, so it avoids intermediate lists and can stop early. Use sequences for long pipelines or large/infinite data.

Coroutines work in common code, but some thread-based dispatchers and blocking calls only make sense on the JVM. kotlinx-io gives platform-neutral Buffer/Source/Sink so shared code can read and write bytes without java.io.

java.time only exists on the JVM, so KMP provides kotlinx-datetime. Instant is an exact moment in time; LocalDateTime is wall-clock date and time with no zone; a TimeZone converts between them.

SQLDelight turns your .sq files into a common typed database API, but you must hand it a platform-specific SqlDriver to actually talk to SQLite: Android, native (iOS), and a web/JS driver. You build the driver per platform and pass it into the generated Database.

In shared code you only get lightweight class tokens via ::class (a KClass), with names and type checks. Listing properties or calling members needs JVM-only reflection, so for portable code you avoid reflection and use serialization plugins or type tokens instead.

Use expect/actual when there is exactly one natural implementation per platform that callers shouldn't choose. Use a plain interface injected per platform when you want multiple implementations, easy mocking, or looser coupling. Interfaces are more flexible; expect/actual is more rigid but compiler-enforced.