Kotlin Multiplatform in 2017: Shared Logic Across Tiers

In this GOTO Berlin 2017 talk, JetBrains engineer Dmitry Jemerov presents the then-experimental Kotlin 1.2 multiplatform approach. Tooling, platform support and APIs described in the talk are historical and may have changed.

Jemerov introduces Kotlin as a statically typed language designed to interoperate with existing ecosystems. He describes the JVM, JavaScript and native targets available or under development at the time.

For the browser, Kotlin source can compile to JavaScript and use external declarations for typed access to JavaScript libraries. He also demonstrates a dynamic type, which gives up compile-time checks for those accesses.

Jemerov describes React bindings and development tooling available at the time, including build integration, debugging and reloading. The exact setup is specific to the 2017 toolchain.

The central idea is to share platform-independent business logic while retaining platform-specific modules. He does not propose hiding every difference between platforms behind a single abstraction.

Common code declares expected functionality, and each target supplies an actual implementation. His example uses different date facilities on the JVM and in JavaScript.

The expect/actual mechanism can cover more than interface methods, including constructors and top-level functions. Jemerov explains how it can connect existing platform types to common declarations.

He walks through the Gradle configuration and common and platform-specific library artifacts used in the early implementation. These build details are not a current setup guide.

In a demo, the server renders initial messages and the browser renders later messages using shared model, serialization and HTML-rendering code. He runs common tests against both JavaScript and JVM targets.

Jemerov describes the early LLVM-based Kotlin/Native toolchain and iOS support, including access to platform libraries. He calls the memory-management design preliminary and emphasizes that the native integration was still evolving.

During questions, he says common tests can check that platform implementations satisfy shared expectations, while some behavior may intentionally differ by platform. He also describes interop limitations as they stood in 2017.