Since the release of Kotlin Multiplatform Mobile about 9 months ago, more and more developers have decided to give it a try and start to share their code between mobile platforms. Some do this in their free time while working on pet projects. Some integrate KMM into existing apps. And some even base their brand new applications on the KMM technology.
The technology is already helping many developers all across the world, but its ecosystem has plenty of space to build on and for new libraries to be added. We would like to encourage you to help build this ecosystem and create libraries in order to help more developers realize the benefits of sharing code between mobile platforms with Kotlin.
In this article, we will provide a brief overview of the most popular Kotlin Multiplatform Mobile libraries and shed some light on what motivated the authors to create them and hopefully inspire you to contribute yourself.
SQLDelight, Alec Strong
I started writing SQLDelight because we weren’t happy with the existing libraries for working with SQLite on Android. We had the idea to write an IntelliJ/Gradle plugin pair to make working with SQLite easier, so we gave it a shot and really liked the result. It was also a great opportunity to try Kotlin out before using it in our Android app (this was all the way back in 2015), and because it had no product-specific components we kept it open source.
At its core, SQLDelight is about code generation. Although the first version generated Java code that was extremely hard to use. So about two years ago, we began rewriting the library from scratch with pure Kotlin-generated code, and we thought this would be a great opportunity to keep it platform-agnostic. Because SQLDelight’s only required dependency is SQLite, which itself is available on essentially every platform, it made sense to embrace KMM. We didn’t make this choice with any particular use case in mind, but rather with the knowledge that we were protecting ourselves from doing too much in the library. Working on 10 platforms forces us to keep our level of abstraction very close to that of SQLite itself.
In the last few years, SQLDelight has turned into a massive community effort, so much so that the majority of the IDE features are now contributed, the entire native stack is contributed, other SQL dialect support is contributed, the js driver was contributed, and an enormous amount of other features, improvements, and bug fixes all come from external contributors. We’ve received a lot of support from the KMM community, which has helped get SQLDelight to where it is today. I’m really glad we chose to embrace KMM when we did, since it helped shape SQLDelight into a well-defined, single-purpose library, and brought many community contributions that have helped the library across all platforms.
Decompose, Arkadii Ivanov
Decompose contains Kotlin Multiplatform lifecycle-aware business logic components (aka BLoC) with routing functionality and a pluggable UI. The library provides a simple way to split code, shared or unshared, into decoupled reusable components. The library also provides navigation between components with strongly typed arguments, so this logic can be shared as well. Decompose works best with declarative UI frameworks, such as Jetpack Compose for Android/Desktop, SwiftUI, React, and so on. However, common Android Views are also supported (experimental).
KMM allows developers to share the parts of code they want to share, and it doesn’t force them to stop at the business logic. That was my motivation for trying to cover the missing part in the ecosystem of the Kotlin Multiplatform libraries – navigation and componentization. This was also a good chance to play with declarative UI frameworks and see how they work with Kotlin Multiplatform.
You can listen to a detailed explanation of the Decompose library from Arkadii Ivanov in this episode of Talking Kotlin.
Realm Kotlin Multiplatform SDK, Nabil Hachicha
Realm is a database designed from the ground up for mobile development, available on iOS and Android. It’s open-source, easy-to-use, and helps mobile developers build better apps faster.
With the emergence of Kotlin/Native and the Multiplatform initiative, developers using the Java version of Realm started wondering about the possibility of supporting Realm in a Multiplatform context. This need was driven primarily by the prospect of writing a shared persistence logic across iOS/Android, since some users using Realm were duplicating the same logic across the Cocoa SDK and the Java SDK on their products.
We also believe that the bottom-up approach to building a cross-platform application is more appealing and less risky for developers. Business logic, network, serialization, and persistence are more likely to be shared between platforms than the UI is, so we wanted to position Realm as an option for KMM developers.
Recently we decided to write a Kotlin-first Realm SDK in order to integrate more seamlessly with current reactive frameworks from Kotlin’s structured concurrency libraries. At the same time, we wanted to build it as a Multiplatform library to cater to existing Java users while also opening the door for developers who might want to try the new cross-platform paradigm.
For more details check out the “Realm Kotlin Multiplatform SDK” article on our blog and the episode of the Talking Kotlin podcast featuring the authors of the project.
Multiplatform Settings, Russell Wolf
Multiplatform Settings is a multiplatform key-value storage library that allows developers to persist simple data in their applications. It wraps around typical platform key-value APIs to make migration and interoperation with pre-existing platform-specific code using these APIs easier. The first version was publicly announced in May 2018, making it one of the first community-developed multiplatform libraries. While it started as just a mobile library targeting Android and iOS (long before KMM was a phrase anyone was using), it has since grown to include implementations on JS, the JVM, and native macOS and Windows.
My biggest inspiration for jumping into library development came from talks and articles by Kevin Galligan (long before I joined Touchlab). I’d been loosely following the early development of Kotlin/Native in 2017 and was attracted to the idea that we might someday use it to share Kotlin code to iOS. Kevin highlighted how, as developers were starting to write multiplatform apps, there would be a need for libraries for them to make use of, and pointed out how it was a good moment to get in early and make a significant impact before the ecosystem got crowded.
While I’d already begun to get involved in community events like meetups, this was my first major open source contribution. It opened a lot of doors, leading to my first conference talk at Droidcon NYC 2018, with others to follow. It’s a really nice feeling when you move from sitting in the audience at events to being someone other people recognize and ask questions to. It’s also been a great resume-booster, helping me short-cut the job interview process more than once, since I had public demonstrations of my technical ability.
Ktor, Hadi Hariri
We developed Ktor to give the Kotlin community a library that made use of Kotlin’s DSL capabilities as well as coroutines. Built from the ground up using Kotlin, Ktor provides developers with the ability to create not only server-side applications, but also client-side ones. It is used heavily in Kotlin Multiplatform Mobile applications that require HTTP connectivity, as the client supports Kotlin/Native as well as Kotlin/JVM and Kotlin/JS.
Joining many other libraries that are Kotlin Multiplatform, Ktor provides developers the ability to focus on their application logic and business needs, as opposed to worrying about infrastructure code.
Kotlin Multiplatform Mobile is growing increasingly popular, with big companies and independent developers adopting it in their user-facing apps. As the number of developers using KMM to share code between mobile platforms increases, the demand for libraries will rise proportionally.
This provides a great opportunity for anyone who would like to contribute. Join the community of library authors by following our special series of articles that explain all the aspects you will need to know about creating your KMM library.
If you still not sure where best to direct your efforts, you may consider working in one of these areas:
- Testing and code coverage
- DI and mocking
We encourage you to build libraries, share your knowledge, and help other KMM developers achieve professional success. There are a lot of open needs in the community, and your involvement will be truly appreciated!
Read and watch more:
- What’s New in KMM Since Going Alpha blog post
- Kotlin Multiplatform Multiverse, a series on our YouTube Channel
- Creating Your First Kotlin Multiplatform Library
Learn more from the Kotlin and KMM docs: