Nov 19, 2019 · 9 min read Posted by Touchlab

Kotlin Multiplatform Frequently Asked Questions

Touchlab is building a community of mobile code sharing and Kotlin Multiplatform enthusiasts. We answer Kotlin Multiplatform frequently asked questions.

Can I use Kotlin Multiplatform for an existing app?

Sam: Yes, being able to optionally share even small parts of your application lets you plug KMP in where it makes the most sense for you.

What Kotlin Multiplatform libraries is Touchlab using today?

Touchlab’s libraries

Stately: Stately is a state utility library to facilitate state management in Kotlin Multiplatform.
SQLiter: Sqlite driver for Kotlin Native
xcode-kotlin: Xcode plugin for Kotlin debugging and source formatting

Jetbrains’ libraries

Ktor: Client/Server networking
Kotlinx.Coroutines: Support library for coroutines.
Kotlinx.Serialization: Kotlin cross-platform / multi-format reectionless serialization

Community Libraries We Use

Multiplatform Settings: A Kotlin Multiplatform library for saving simple key-value data
SqlDelight: Multiplatform SQLite model facilitation library.
Koin: Service Locator/DI. Multiplatform in progress.

Libraries We Find Interesting

Sample Apps

Kotlinconf App: From JetBrains
DroidconKotlin: From Touchlab

Sam: One of the great things about KMP is that you have a lot flexibility in how much code is shared. As a rule we don’t recommend trying to share your UI code. Creating high quality UI is generally best accomplished using the tools and environment of each platform. Everything else is fair game. In practice you will find that the code you share will be the most critical business logic and the layers your platform developers are sick of doing twice.

How much weight does KMP add to our apps?

Kevin: Minimal relative to other options, and proportional to how much you use. There is no re ection, and the standard library is small, so the Kotlin compiler includes only what’s actually being used. In general, minimal us- age of Kotlin in a native app will add a binary size in the 100’s of K’s. Major logic will likely get into the low megabytes.

We use Swift. How’s the interop with KMP?

Kevin: It currently presents to Swift/Objc as an Objc library. The usual Swift Objc interop issues will apply, but the generated header takes advantage of many of the naming you can insert for Swift. You can also now have ge- nerics (I highlight that because we did that, too). With ABI stability, direct Swift interop will be more of a priority. Possibly early next year, but there is no timeline yet from the team.

What type of ecosystem and tool are available?

Justin: The existing, mature, and exciting ecosystems of native Android and iOS development are available. Not everything can be pulled into shared code, but the beauty of sharing business logic is that most of it can be shared. A mature and loved library that is already in Kotlin is very close to joining the KMP ecosystem. For example, once SqlDelight was set up to output Kotlin, it didn’t take long to make it compatible with shared code…and iOS developers love that they don’t need to deal with CoreData anymore but they can keep all the other stuff they love.

Kevin: Major libraries have been appearing over the last year, from JetBrains and other groups. This will continue as more libraries from the mobile world are ported. The Kotlin community on Android is already one of the most active in technology, so there is an existing and active develop- er base. As for tools, Jetbrains makes tools as a core business. They have tools already for multiplatform, and will continue to improve them. One of the main reasons why Kotlin is successful now, and why Kotlin Multi- platform will be successful in the near future, is because JetBrains will be building the tools.”

How will KMP affect our ability to recruit and onboard new iOS devs?

Justin: Equal or better. Some iOS devs will be happy to spend time on getting the UI and platform-specific stu right. Some iOS devs want to become mobile devs and will be happy to start learning Kotlin. All iOS devs will be happy to know that it doesn’t force them out of the ecosystem and lose their identity.

Sam: Kotlin Native will be much better received by new iOS developers than many other code sharing schemes. The ability to code UI natively while treating the common code as a normal framework is much less foreign than tools which require them to learn an all new framework.

Kevin: Developers tend to prefer the platform they use, but the idea that they are all violently opposed to change is overblown. Developers are skeptical to new tech, and often for good reason. Hopefully, including Kotlin will attract developers interested in new tech. In general, the decision to move to any “cross-platform” technology is not coming from the developers but from the management level, and it is often a mandate to pick something. It’ll be much easier to recruit iOS developers if they get to embrace Swift- UI and other new Apple tools and learn Kotlin code sharing as opposed to learning React Native or Flutter.

How fast is the compilation time?

Kevin: Not super fast, but the general dev process is to code on the JVM side first, which is more optimized, then rebuild the Xcode framework and call it from iOS. The next major version of Kotlin should be focused on various performance improvements (compilation being one of them).

Thoughts on handling concurrent operations in Kotlin Multiplatform?

Kevin: Kotlin Native’s concurrency model is different than the “classical” mod- els of the JVM and Swift/Objective C. It is something that new developers, coming from either Android or iOS backgrounds, will need to understand. It can be confusing at first, but the goal of these changes is less error- prone concurrency. There are some early libraries to assist with concurrency, but later this year we expect multithreaded coroutines to emerge for Native. At that point, most concurrency will be managed by libraries (like most concurrency is managed now). You’ll need to understand how it works, but the libraries will handle the heavy lifting for you.

Justin: Focus on well-established architecture principles of keeping the UI layer thin and modularizing code. Something new may be separating Android-specific libraries from common code but this is often a small amount because business logic is, by its nature, less platform-specific.

What’s the value-add over other technologies?

Justin: Kotlin is THE language for Android. KMP doesn’t significantly change the way you develop native Android apps. KMP interop is native so there is very little run-time overhead and less boiler-plate code while developing. KMP outputs a standard iOS framework so iOS devs are still in familiar territory. By its nature, it keeps up with platform-specific technologies that motivate and excite strong native developers and those looking to join the space (retention and hiring). It doesn’t create its own ecosystem so it’s not a ‘B’ big decision, easy to iterate and revert, very little up-front cost compared to others.

Sam: It’s optional, meaning you can do some, and no big decisions. Natively integrated: the interop is platform native, which is unlike pretty much all other options. Open source. Code sharing, so you can write and test your critical logic and architecture, but don’t build a dissatisfying UI. The language is popular and modern. That is important for libraries, hiring, and productivity.

Does KMP work with Android WearOS, Apple WatchKit, TVOS?

Kevin: Kotlin 1.3.60 will add support for WatchKit and TvOS. Anything on the Android side already uses Kotlin, so there are no compatibility issues (Kotlin is the preferred language for Android).

How mature and stable is KMP?

Kevin: The language and tooling have gone through significant change over the past couple years, but the build tools and features of the ecosystem have stabilized. The tooling and support libraries will continue to mature rap- idly during the remainder of 2019 and into 2020. As for stability, there is no “multiplatform” at runtime. It is a build time construct. Kotlin JVM is super stable. Kotlin Native’s runtime is stable, although you will occasion- ally run into things you don’t expect. Usually a result of cryptic messaging. That will also improve over the next year. Major apps are releasing Kotlin Native into production now.

What’s the best way to set up the dev experience for iOS devs?

Kevin: I think it’s important to establish that the plan is not to start writing everything in Kotlin. The shared code will support the native development experience of Swift and Xcode, especially as SwiftUI takes over UI development on iOS. Introduce Kotlin as a modern language that shares much of the syntax and concepts of Swift, and at an architectural level, it’s important to start thinking of our teams as “mobile developers” rather than specifically Android and iOS. Having an Xcode plugin for Kotlin means iOS developers can start reading and debugging Kotlin in the shared code without needing to dive in with new languages and tools. Once that knowledge is learned, the iOS team can start pushing code that the Android (and possibly web) teams will use. It’s important to minimize the idea that the iOS teams will just be getting code from the Android app, although that is often the initial reaction, as Kotlin is an ‘Android thing’.

How do you start migrated a codebase to KMP?

Kevin: Pick one part that needs to happen on both platforms, ideally something that the iOS team isn’t excited about. SQLite is a good option, if you’re us- ing it. Nobody likes Coredata. SqlDelight is a far better option. From there, possibly networking, analytics, or any logic intensive operations that need solid testing. Because it’s “optional” sharing and natively integrated, it’s easy to weave shared code into existing code.

Can I hire for Kotlin Multiplatform?

Justin: The community is growing quickly but this is new technology. At this point, there are very few experts, some devs with experience, and many more getting to know it. The greatest thing WRT hiring for KMP is that Kotlin is an easy language to hire for, and since it integrates well with new tech like Jetpack Compose and SwiftUI, even the people who built their careers on Android or iOS welcome it.

Kevin: In general, hiring for positions that are seen as forward-thinking and working with popular technology will be appealing to developers. KMP is new, so there isn’t a lot of experience out there. However, there are many developers experienced with Kotlin for Android, and a lot of developer community interest in KMP. Competing for talent will be easier if you embrace technologies that developers are excited about. KMP is certainly no exception. Today, you should expect some ramp-up time for people with experience writing Kotlin for Android. However, offering experienced Android developers the chance to focus on KMP will increase the pool of candidates interested.