W3cubDocs

/Kotlin

Multiplatform Programming

Multiplatform projects are an experimental feature in Kotlin 1.2 and 1.3. All of the language and tooling features described in this document are subject to change in future Kotlin versions.

Working on all platforms is an explicit goal for Kotlin, but we see it as a premise to a much more important goal: sharing code between platforms. With support for JVM, Android, JavaScript, iOS, Linux, Windows, Mac and even embedded systems like STM32, Kotlin can handle any and all components of a modern application. And this brings the invaluable benefit of reuse for code and expertise, saving the effort for tasks more challenging than implementing everything twice or multiple times.

How it works

Overall, multiplatform is not about compiling all code for all platforms. This model has its obvious limitations, and we understand that modern applications need access to unique features of the platforms they are running on. Kotlin doesn't limit you to the common subset of all APIs in the world. Every component can share as much code as needed with others but can access platform APIs at any time through the expect/actual mechanism provided by the language.

Here's an example of code sharing and interaction between the common and platform logic in a minimalistic logging framework. The common code would look like this:

enum class LogLevel {
    DEBUG, WARN, ERROR
}

internal expect fun writeLogMessage(message: String, logLevel: LogLevel)

fun logDebug(message: String) = writeLogMessage(message, LogLevel.DEBUG)
fun logWarn(message: String) = writeLogMessage(message, LogLevel.WARN)
fun logError(message: String) = writeLogMessage(message, LogLevel.ERROR)

├compiled for all platforms

├expected platform-specific API

├expected API can be used in the common code

It expects the targets to provide platform-specific implementations for writeLogMessage, and the common code can now use this declaration without any consideration of how it is implemented.

On the JVM, one could provide an implementation that writes the log to the standard output:

internal actual fun writeLogMessage(message: String, logLevel: LogLevel) {
    println("[$logLevel]: $message")
}

In the JavaScript world, a completely different set of APIs is availiable, so one could instead implement logging to the console:

internal actual fun writeLogMessage(message: String, logLevel: LogLevel) {
    when (logLevel) {
        LogLevel.DEBUG -> console.log(message)
        LogLevel.WARN -> console.warn(message)
        LogLevel.ERROR -> console.error(message)
    }
}

In 1.3 we reworked the entire multiplatform model. The new DSL we have for describing multiplatform Gradle projects is much more flexible, and we'll keep working on it to make project configuration straightforward.

Multiplatform Libraries

Common code can rely on a set of libraries that cover everyday tasks such as HTTP, serialization, and managing coroutines. Also, an extensive standard library is available on all platforms.

You can always write your own library providing a common API and implementing it differently on every platform.

Use cases

Android — iOS

Sharing code between mobile platforms is one of the major Kotlin Multiplatform use cases, and it is now possible to build mobile applications with parts of the code, such as business logic, connectivity, and more, shared between Android and iOS.

See: Multiplatform Project: iOS and Android

Client — Server

Another scenario when code sharing may bring benefits is a connected application where the logic may be reused on both the server and the client side running in the browser. This is covered by Kotlin Multiplatform as well.

The Ktor framework is suitable for building asynchronous servers and clients in connected systems.

How to start

Tutorials and Documentation

New to Kotlin? Take a look at the Getting Started page.