What is Kotlin Multiplatform?
Here is a precise definition of what Kotlin Multiplatform is:
- Kotlin Multiplatform is optional, natively-integrated, open-source, code sharing platform, based on the popular, modern language, Kotlin. It facilitates non-ui logic availability on many platforms.
What’s included in this introduction to Kotlin Multiplatform?
The ultimate guide in plain English to understand Kotlin Multiplatform (KMP):
- In-depth explanations of why we define Kotlin Multiplatform as: optional, natively-integrated, open-source, code sharing platform, based on the popular, modern language, Kotlin. Kotlin Multiplatform facilitates non-ui logic availability on many platforms.
- Technical explanations of Kotlin Multiplatform
- Our introduction to Kotlin Multiplatform presentation from 2019 ØreDev Conference (video recording and slide presentation)
- Useful links for getting started quickly and minimal risk with Kotlin Multiplatform
Let’s get started…here’s how we think about Kotlin Multiplatform:
It’s madness, really. An app is written for the web. Then for Android. Oh, and then it needs to be written for iOS, too. (At the same time.) Same app, different code. The question is, “Why?”
Development teams are essentially tripling their coding and testing efforts to ensure multiplatform coverage. It’s costly. It’s time-consuming.
And – this might be the craziest part – it’s uncertain what the shelf-life of the code will be. As we know, the future is unwritten.
As always, the goal is to be able to implement products more efficiently, and with better testing across platforms. And up to now, every multiplatform coding solution that has come along really hasn’t worked that well.
Kotlin Multiplatform is really about pragmatic programming to help meet the growing demand to develop mobile applications on multiple platforms – a clean, clear way to avoid having to write the code twice.
Let’s start to expand on our definition of Kotlin Multiplatform, but first remember that “cross-platform” isn’t just one thing
It is important to discuss the differences in “cross platform” tools. Obviously they all have different plusses and minuses, but we regularly get into discussions where suddenly “cross platform” is a singular thing. It’s not.
Optional sharing. Low risk. No big decisions.
Start with a little shared. Feature by feature. Do a test in one sprint. You don’t need to commit to a (capital B) Big Decision. Risk is often under estimated with the developers we talk to, but is a big thing for management. It’s why Flutter is going to have a really hard time getting serious traction.
Natively integrated. Smooth interop.
Kotlin is designed to interop with the underlying platform. No 3rd environment. No VM. No “bridge”. That is a huge, fundamental difference.
Pretty self explanatory, but we’re watching an entire ecosystem emerge over time, and Jetbrains and Google have created the Kotlin Foundation to help ensure open and independent development.
Code sharing, not cross-platform
Allows sharing of logic, optionally. It is not trying to be a single application unit able to run on all platforms.
It is important to note that Kotlin is popular, which means an existing, large community, and intense excitement about the language and the future. More support, libraries, hiring, training opportunity, etc.
The language itself is “modern”, but more than just the syntax. They are making arguably tough but forward thinking decisions WRT language and runtime design. Watch the Kotlinconf 2018 Keynote to hear about Saner Concurrency. They’re not simply bringing status quo to a new language. Also, it’s not “done”. Kotlin is evolving rapidly as time goes on.
Not UI – well, not necessarily UI
People will definitely try to build shared UI frameworks for Kotlin. They are now. I’ve seen demos.
Shared UI is a history of pain and failure.
Shared logic is the history of computers.
– Kevin Galligan
For native especially.
IDE and tooling – JetBrains make it
“I started using Kotlin in Android apps in mid-2014. Back then I assumed it would be popular because JetBrains made the language and IDE. Even back in 2008 for the ADC, I would edit my code in Intellij, then tab to Eclipse to build. JetBrains makes the good stuff.” – Kevin Galligan
- High efficiency
- Low risk
- Modern language and tools
- Highly engaged community
More than just native mobile
KMP is far more than just native mobile, but that’s where most of our experience is, and we think that’s where it’ll have a lot of the early traction. The “killer app” as it were.
Mobile is easy
They’re basically the same under the label. Threads, sql, files, networking, etc. They extremely similar. Sharing logic and architecture will be very doable with Kotlin Multiplatform.
Technically, though – what is Kotlin Multiplatform?
Multiplatform is a compile-time construct. It is a way to represent “shared” code but have it be able to compile down and deploy to multiple platforms. JVM, JS, and Native are the broad targets.
There are many specific permutations that you can compile to.
In Java-land, you can target the raw JRE, or Android-specific.
JS can output code meant for browser or server.
Native has a whole bunch of targets. iOS (phone, watch, tv), MacOS, Linux, Windows, Android native, WebAssembly.
Conceptually speaking, these are the broad categories.
Also, we’re largely focused on native mobile, so our examples and much of our library work lives here.
How does Kotlin Multiplatform work?
On iOS, the Kotlin Native compiler “merges” the common code and other source sets in that target’s hierarchy.
There can be multiple layers of specific sourcesets, but often with apps it’s just one for common and one for iOS.
That compiles down and, assuming you’re building an app, you create a framework that Xcode can consume.
Similarly, the Android side does some similar things. Although the pipeline can be a bit more direct. Kotlin has had more time to get friendly with Android.
“This is also a good time to reinforce the idea that sharing is “optional”. Your actual apps aren’t all-or-nothing moving to shared Kotlin. One of the most important features is the native integration, and the ability to incrementally start sharing logic in existing apps.”
– Kevin Galligan
Introduction to Kotlin Multiplatfrom presentation By Kevin Galligan (Øredev Conference, 2019)
Kotlin Multiplatform is a true multiplatform language
Kotlin enables you to write once, and test once. No siloed development teams. The same code can be used across Android, iOS and Web apps with no changes, eliminating the need for a translation layer. In essence, you’re reducing the amount of business logic coded by frontend developers by consolidating it efficiently with native code, but not oversimplifying abstractions.
What’s not to love about that?
No wonder there’s a groundswell of enthusiastic support in developer communities around the world. There are 1.5 million developers currently using Kotlin, with 96,000 GitHub repositories containing 100 million lines of code. And the numbers keep growing. It’s one of the top two languages that developers are hungry to learn.
Kotlin was developed as a completely new language eight years ago, built from the ground up as a pragmatic approach to coding – a way to develop cleanly, clearly, and quickly.
Simply put, Kotlin is more readable, reusable, interoperable, and safer, offering a first-rate developer experience.
Kotlin Multiplatform for your complete tech stack
It’s a low-risk way to code because it dovetails seamlessly with the native platforms on Java, iOS, and the web. It’s a modern language that enables you to build on what you’ve already coded, without re-working or re-inventing what you already have. Plus, because the code you share is optional, you can start small and increment as desired.
Kotlin is really an extension of Java, so it’s not a big leap for Java developers to start using Kotlin at all. In other words, you don’t have to make a big, potentially expensive decision to get started.
In fact, on Android, Kotlin was built for direct JVM interoperability. On iOS, Kotlin is ready for prime time, and the first half of 2020 will see rapid mainstream adoption. And Google officially recommends Kotlin as a language of choice.
The big considerations for any development team are cost, time, resources, and risk. And the big problem with the siloed approach is that organizations are often tripling them.
At the same time, the wrong teams are working on the wrong projects. Back-end developers should focus on architecture as well as APIs – but not UI. Enabling your back-end developers to code and test the client and server features as a unified whole enables more rapid development with safer, higher quality and identical implementation.
And that, my friends, is all there is about Kotlin Multiplatform. If you ever find someone feeling left behind and wondering, “What is Kotlin Multiplatform?” you know where you can point them too.
So you have this handy ultimate guide to Kotlin Multiplatform, bookmark the link.
Can you think of someone right now who should read this? Feel free to share this introduction to Kotlin Multiplatform.
Our experience with Kotlin Multiplatform so far?
No siloed teams.
More streamlined workflows.
Real multplatform functionality.