Kotlin Multiplatform Library Development

Kotlin Multiplatform stands for the use of Kotlin for the development of applications on Android, Web, Desktops, IOS, etc. It uses Kotlin-JVM for Android, Java-8, Java-6; Kotlin-JS for Browser, Node; and Kotlin-Native for other platforms like IOS, macOS, Linux, Windows, Android/NDK, etc.

Kotlin Multiplatform allows the use of shared code/modules between all or some of the target platforms. In the current state, the multiplatform module is a good way to share data/domain codebase between different platforms(Android/IOS) to reduce business logic fragmentation.

This post is going to cover a little bit of how it all works and more about library development using Kotlin Multiplatform for Android and IOS(may be Web later) as I keep exploring.

Kotlin Multiplatform is a code-sharing mechanism and not cross-platform frameworks like PhoneGap, Xamarin or React Native. JetBrains has planned Kotlin to be a portable language that can be rendered to many different platforms. Not just the JVM. These include Javascript and Native, which is an LLVM compiler capable of outputting to iOS, Windows, Linux, Web assembly, and many other platforms.

Kotlin-Native is the tool you use to compile Kotlin code meant to run on platforms other than JVM or Web-based platforms like IOS, macOS, etc.

Kotlin-Native processes the source code in 2 steps to reach the executable bits. As shown in the below diagram there is a frontend part and backend part to the whole flow. The intermediate representation is a format that the LLVM compiler understands and this representation could be converted to native code for all the platforms supported by LLVM.

From here, I am going to narrow down the discussion to Mobile Multiplatforms — Android and IOS.

There are multiple ways of including platform-specific logic in the shared module, common ones are —

Expected is used inside the commonMain to notify the compiler that shared part of your code requires some platform-specific implementation, while actual is the way of telling the compiler that you have provided a platform-specific implementation and shared module is ready to go.

It looks very close to Interfaces, but the difference is that we could have only one implementation for each platform. So far writing tests against this approach is still hard and doesn’t have an easy approach identified as of now.

Always use interfaces for “service” objects.

Enables testing! I didn’t find a good way to test with expect/actuals as it’s possible to have only one implementation.

— Android

It’s just like any other source dependent library setup in Android Studio.

— IOS

Xcode Plugin for kotlin. (basic syntax highlighting, step through Kotlin Source, inspect variables )

Limitation: Can’t step from Swift/ObjectiveC into Kotlin. Explicit breakpoint needed on Kotlin Source

— JS

Kotlin/Native has no version compatibilities. This means when a new Kotlin version comes out, the native apps who want to use your library won’t be able to update to the new version unless you upgrade to the latest.

Relatively small number of support libraries as the ecosystem is fairly new and still in beta as of writing.

Jetbrains libraries(most of the available libraries outside Jetbrains are experimental at this point) available as of now(Jan 2020) are:

Networking, Concurrency, and Data Persistence libraries are available.

Related posts:

Inactivity has become an epidemic that leads to many health issues. Moving more is the first step towards better physical and mental health. However, training mistakes or improper form can increase…

In the era where our mobile phone devices have come to satisfy so many of our needs and have become so minutely integrated in all our daily functioning it is only logical that the features of the…