KMP For Teams

If you’re reading this, you are likely aware of Kotlin Multiplatform. Most people with an understanding of native mobile development, developers, managers, whoever, tend to put KMP into the larger “cross-platform” bucket of technologies. That leads to some assumptions and fairly meaningless comparisons. I wouldn’t argue that KMP isn’t “cross-platform” as much as the term “cross-platform” is far too broad to be very meaningful.

Code Sharing

KMP, in the context of native mobile, would be better classified at a “code sharing” framework. In that sense, it is much more similar to C++ or Rust, when used to write shared code libraries.

This is in contrast to, say, Flutter, React Native, or Ionic. These are “shared UI” or “shared ‘everything’” platforms. When thinking about “cross-platform”, this is closer to what comes to mind. The functional difference being, they’re designed to implement the whole app. UI and all.

Of course, with Compose UI for KMP, you could also write the whole app. One very important distinction is that KMP is designed to blend with, and interop with, the native platforms.

“Optional” Sharing

In the context of native mobile code sharing, KMP is unique, in multiple ways. The primary distinction is the fidelity and expressiveness of the interop.

Not interop with Android code. The default language of Android is Kotlin. No “interop” required.

In this context, the important interop is with Swift. It is excellent, at least relative to other code-sharing platforms. When using C++, Rust, JS, Python, etc, your app code communicates with the shared code through a “dumbed down” API. The more “modern” or “user-friendly” features of these languages aren’t available.

With Swift talking to Kotlin, Swift gets to call a much high-level API surface. We’ll certainly debate how “excellent” the “out of the box” KMP interop is, and there is plenty of room for improvement, but still. KMP’s Swift interop is far better than other options.

That helps make KMP’s code-sharing “optional”. You can use a little, you can use a lot. You don’t need to write the “whole app” in KMP. Start small, and grow.

That optionality greatly reduces platform risk. You don’t need to make “big decisions”. Reducing risk, in general, is valuable. We’ll be discussing risk in several places in this guide.

Platform Maturity and Adoption

Apps have been putting KMP in production for years. Touchlab started working with KMP after it was announced, back in 2017, and have worked with many teams who have successfully added KMP to their native mobile projects.

KMP is stable. Not just “in general”. After years of intense effort by the JetBrains team, the platform itself has been officially designated “stable”. While some teams were reluctant to adopt KMP while it was in Alpha or Beta, we are beyond that point now.

At Google I/O, the Android team officially endorsed KMP for code sharing. Google is adopting KMP for some of their larger, public mobile apps.

KMP Compose UI

Although we won’t discuss shared UI much in this guide, the emergence of Compose UI for iOS presents some very interesting possibilities for building “mostly native” apps. You could share all of your logic, and most of the “lower traffic” app screens. Things like settings, etc. For your main screens, where your uses spend the vast majority of their time, you could build native iOS UIs on top of the shared KMP code (Compose is already the suggested UI for Android).

Sounds great! Why the guide?

The technical potential of KMP is huge. In theory, you could significantly boost your teams development efficiency with zero impact on app quality or the user experience.

However, adding KMP effectively in teams is not necessarily easy. For reasons we’ll discuss over the following sections, sharing KMP code at scale is difficult. This is not because the technology is flawed. As mentioned, KMP is unique. This very uniqueness presents issues.

Existing teams tend to apply existing patterns. Code sharing with KMP requires some new patterns.