Have you tried Kotlin Multiplatform? Have you heard about Kotlin Multiplatform, but aren’t really sure what it’s about?
Did you know you can use Kotlin to build applications for the web, iOS, Mac, Linux, Android, and more?
Kotlin Multiplatform makes this possible. And while the technology is still rapidly evolving, it’s quickly reaching the point of viability beyond the early adopter audience.
What is Kotlin Multiplatform?
So what exactly is Kotlin Multiplatform? A Kotlin Multiplatform (KMP) project enables the sharing of common code across your various build targets.
Building For Multiple Targets
Business logic, data objects, interfaces, repositories, etc can all be defined within a common module. That module is included in your platform-specific projects, and consumed as if it was any other third-party library.
Imagine you are building an Android and an iOS app. You might define a common declaration in common code, and then provide a platform specific implementation for both Android and iOS. These concrete implementations exist within the specific platform modules, and are then consumed by the native Android and iOS apps as if they were any other module.
Sharing Code Between Different Build Targets
These platform specific implementations work using the expect and actual keywords.
Using expect, you add your class/property/etc declaration to your shared module. In the following example, we’ve defined a Platform object which will need to be defined for each target platform.
expect object Platform {
val name: String
}
By using the actual keyword, you define the actual platform specific implementation of the expected declaration. In this example, we’ve defined actual declarations of the Platform object for both Android and iOS.
actual object Platform {
actual val name: String = "Android"
}
actual object Platform {
actual val name: String = "iOS"
}
This allows a developer to take into account any platform specific dependencies or technical requirements that are necessary.
While expect/actual provide a language specific mechanism for this type of multiplatform development, it’s also still possible to simply define a common interface and implement that interface for each build target as well.
Targeting Different Platforms With Kotlin
Currently, it’s possible to build for the following targets:
- Javascript
- Windows, Linux, WebAssembly
- JVM, Android
- macOS, tvOS, iOS, watchOS
- And more…
For each build target you include in your configuration, you can include specific platform dependencies, write platform implementations of common classes and apis, and ultimately generate a unique build artifact to be consumed by each individual platform application.
What Is The Value Proposition Of Kotlin Multiplatform?
Why are Kotlin Multiplatform projects an interesting approach to cross platform development?
Using a KMP approach, you can share code using a modern, high-level language, without having to cover the entire api surface of target platforms. Kotlin Multiplatform aims to simplify code sharing by leaving it up to the developer to decide how much code needs to be shared.
Only want to share one specific, core algorithm? That’s fine. You can build a Kotlin Multiplatform project that includes a single function, or the majority of your app’s logic, models, etc.
Because Kotlin Multiplatform projects aren’t aiming to build an entire cross-platform application, the shared code is consumed as you would any other library or module. This makes it a straightforward task to swap that module out for something else if it fails to meet your needs.
This flexibility enables teams to integrate Kotlin Multiplatform without locking themselves into a new tech stack for their entire application. This lowers the barrier to entry for trying this method of code sharing and for making a determination about whether it might be viable for your project or team.
How Does Kotlin Multiplatform Differ From Other Cross-Platform Approaches?
How is a Kotlin Multiplatform project different from other cross-platform approaches? Why does it exist when we already have solutions such as Flutter or React Native?
Sharing Only What’s Needed
These are understandable questions. To me, while Kotlin Multiplatform is similar to these other cross-platform solutions, it’s not in direct competition with them. A KMP project isn’t promising a build once deploy everywhere solution. Kotlin Multiplatform isn’t trying to unify all platform apis. It’s not trying to simplify or recreate the UI framework for target platforms.
Kotlin Multiplatform projects are completely focused on the sharing of common code, but leaves developers to build each platform application however they see fit.
This lets developers share as much, or as little, code as necessary. Building with Kotlin Multiplatform is not an all or nothing approach. If you’re targeting Android and iOS, you’ll still be building two separate native applications. However, if done properly, you can encapsulate the bulk of the logic within shared code so that building those native applications is ideally a smaller, and very similar task.
Deferring To Native UI
For each platform application target, the UI will be completely native. However you currently build your UI for a specific target is how you would continue to build UI with a Kotlin Multiplatform approach. This keeps native developers using the tools they are familiar and productive with. It also reduces the number of layers within your application architecture as there is no bridging or other non-native layer between the native platform apis and your code.
What Are The Current Limitations Of Kotlin Multiplatform?
Where is Kotlin Multiplatform today? What are the main limitations to building multiplatform applications with Kotlin?
Rapidly Evolving Support
Kotlin Multiplatform is still evolving rapidly. As such, it’s been difficult to keep up with how to setup and configure a project. Tutorials and samples become quickly out of date as the support and tooling changes.
Speaking of tooling, the quality of tooling support for Kotlin Multiplatform projects varies quite a bit from platform to platform. Support for JVM/Android projects is great as that is where the primary Kotlin experience is focused. However, support for iOS or native targets is not as polished; particularly when trying to debug from your native application into the shared Kotlin code.
Thankfully, there is focused work being done on this front. At KotlinConf 2019, it was announced that a new Android Studio plugin is in development to simplify the running and debugging of Kotlin code on an iOS simulator.
Supporting Multiplatform Dates And Coroutines
There are a couple other areas where support varies across platforms, but that should be addressed pretty soon.
One is a multiplatform solution for dates. There are currently multiple third-party implementations for date/time support, but the JetBrains team is working on a first-party solution for this.
The other area of need is in multi-threaded coroutine support. Support for this is present on JVM/Android but is not quite ready for native platforms. Within the past couple of months, Kevin Galligan from Touchlab wrote about the state of native coroutines and about the draft PR that indicates that this native coroutine support is close.
Having full support for multithreaded coroutines across all platforms will be a big step forward for the Kotlin Multiplatform ecosystem and should hopefully open the doors for more third-party libraries to be created.
What Are Some Examples Of Kotlin Multiplatform Projects?
There are several production apps out there right now that are using Kotlin Multiplatform:
At KotlinConf 2019, JetBrains announced their new team collaboration tool Space which is built from the ground up using Kotlin Multiplatform.
- JetBrains Spaces app
- Droidcon NYC app
- Twitter thread with other examples
I also came across a recent Twitter thread in which quite a few developers have shared their experience in using Kotlin Multiplatform so far. As someone that’s been watching this technology for a while now, it’s exciting to see how many are experimenting with it and
Frequently Asked Questions
Kotlin Multiplatform is an approach to sharing key buisness logic across a variety of build targets including JVM, Android, iOS, Mac, Windows, etc. A Kotlin Multiplatform project doesn’t try to wrap all platform apis or wrap the native platform UI. Instead, common code is packaged into a reusable library module to be consumed within a native application.
Yes. Kotlin can be used across a variety of platforms including JVM, Android, macOS/iOS/tvOS/watchOS, Linux, Windows, WebAssembly, JavaScript, etc. With Kotlin Multilpatform, it’s possible to share common Kotlin code across multiple platforms at the same time.
Yes. It’s possible to write Kotlin code, compile that into a native framework , and consume that framework within an iOS application. This process can be streamlined using cocoapods; updating the framework dependency anytime the Kotlin build output is updated.
Yes. Kotlin Multiplatform projects exist in production today. Most notable, the team management app Space from JetBrains is built using Kotlin Multiplatform. However, the Kotlin Multiplatform ecosystem is quite new, and there are still challenges. Debugging of native code, multi-threaded coroutines and third-party library support are all areas where support is limited but improving.
Kotlin Native is probably not quite production read on its own. Multi-threaded coroutines are coming soon, but not yet supported. Debugging of shared Kotlin code is still difficult from native applications. These things are not deal breaks, but do present a significant challenge if trying to ship a production application with Kotlin Native today.
Where Can You Learn More?
Are you intrigued yet? If you are, and you want to start exploring Kotlin MultiPlatform, here are a number of resources to help guide you in the right direction: