Musings on the Current State of Kotlin Multiplatform (Q3 '19)

I’ve spent a lot of time chatting in Slack and on Twitter about the state of Kotlin Multiplatform. These are usually piecemeal conversations but often center around common themes. To spread the word better and help streamline these conversations, I’m going to write periodic posts about the current state of the KMP ecosystem.

Catching Up

I think we can start by revisiting some predictions I had last year around KMP in 2019.

Mainstream Adoption

The overall prediction was that we’d be seeing recognizable names diving into KMP and releasing serious apps. Not exactly a wild guess. It is safe to say that was correct, although with a caveat. We’ve been having lots of conversations with teams evaluating and shipping KMP, but these are mostly private. Similarly, if you installed an app using KMP on iOS, you wouldn’t know it, which is the point. I expected tech companies to be a little more forward about the interesting tech they’re using, as I think it really helps with recruiting, but it turns out that not everybody thinks that way.

It is still early days, and you still need to know what you’re doing, but production code is certainly shipping with KMP in Q3.

Multithreaded Coroutines

Not yet. I was *way* off on that. Will discuss later.

Compiler Plugins

This is also “not yet”, although if you want something very specific you could persuade the Kotlin Native team to let you bake something in (if you’re looking for something serious to work on, mockk native). The Kotlin compiler in general is going through big changes. There’s a consolidation happening that will be good long term, but we’ll be waiting for official plugin support in the short.

Other Libraries 

I mean, sure.

Paid License Debugger 

This prediction is interesting, and meta for me. We released an Xcode pluginthat lets you debug Kotlin. Jetbrains has also released a version of App Code that can be used for debugging, and recently a native debugger for Intellij, although all of these tools will need some future polish.

Reactive Library

Yes, ish. I was thinking that would happen after Multithreaded coroutines. There is Reaktive. It is more of a “traditional” Rx-like library. I think most apps at this point use something built in-house.

Q3 2019

Rather than just a big rundown of where things are at, I’m going to create sort of a composite character and consolidate multiple conversations I’ve had recently.

Q: Is anybody currently using KMP in their apps? There have been a lot of blog posts from earlier in the year, but the situation seemed flakey. Has there been much progress since then?

A: Yes! People are using KMP in apps. KMP is relatively new, generating lots of excitement, and moving very fast. That means there’s been a lot of aging content. If getting started or looking for updated info, it’s best to check out the Kotlin Slack, check out some tutorials, and see more detailed docs. If you’re looking for a super quick intro, check out our getting started series. We should have a few more coming out soon. They’re quick, and we’re going to keep them updated with each release, so they don’t age too fast.

Q: We are exploring the possibility of using Kotlin MPP for business logic and architecture (storage, networking, etc). Is that feasible and how much logic can be shared?

A: That is really what KMP is designed to do, so it’s definitely feasible. It will not be easy to build UI’s, certainly not shared ones (although there will certainly be shared UI options in the future). What’s really missing at this point are some libraries you might want to use, like date/time support, or local file access. The good news is that 1) library work is accelerating as the community grows, and 2) Kotlin has an optional interop design, so it’s easy to plug in whatever you want from the native platform to implement a missing feature. If you can’t find a library for something you want to do, it’s easy to just code it “native”. Date formatting, for example.

Q: I’ve heard coroutines aren’t supported on iOS, and they’re needed for concurrency. How does that work?

A: Interesting topic. Coroutines in native (and JS) are single-threaded. That’s not the same as unsupported. You cannot, however, do all the stuff you would on JVM/Android. That has definitely put off some developers, but this is really multiple questions. Coroutines are not needed for concurrency. In the context of native mobile development, we usually want to do something off the main thread, then return to the main thread. You can do this, and it’s straightforward to write. We use suspend functions in the Droidcon app where the main thread suspends, a background task is run, then execution resumes in the main thread. Flow is more complex, but we’re using it in a Firestone SDK wrapper currently (not public yet). Ktor uses suspend functions instead of callbacks for network calls.

However, the whole community expects multithreaded coroutines will significantly increase adoption. There are no target dates, but there is ongoing work and I’d bet something to appear around Kotlinconf.

Understanding native concurrency helps the discussion. I have a couple of blog posts (and that’s what I’m talking about at Kotlinconf):

Kotlin Native Stranger Threads Ep 1

Kotlin Native Stranger Threads Ep 2

Q: What’s the Swift and general iOS interop situation like?

A: There are the mechanical interop details, then there’s what I’d call the Swift developer interop, which is related, but different. Swift interop with Kotlin is through an Objective-C interface generated by the Kotlin compiler. That means whatever issues a Swift developer will encounter with Swift to Objc interop will be present. On the other hand, Apple has spent considerable time trying to make that interop as painless as possible. That means Swift naming overrides, generics handling, etc. The Kotlin Objc output is constantly improving, and currently supports many of those features.

There are no details yet, but I have it on good authority that direct Swift interop may be a priority in the not-too-distant future.

The politics of shared code and Kotlin on iOS are a different story. The goal is to steadily improve the tooling experience for everybody, including iOS developers. That is certainly a huge goal of ours. That should help, but there’s going to need to be some selling on the idea too. Need to start seeing Kotlin talks as iOS meetups!

Q: Our iOS team is really excited about SwiftUI and said we should hold off on Kotlin until we figure that out.

A: Not in the form of a question, but I’ll rephrase: “Can you use Kotlin with SwiftUI?” Yes. Not the actual “UI” part, but the logic and architecture, which is what KMP is really for, sure. SwiftUI doesn’t change the equation much. We’re all pretty excited about it too.

You cannot have structs coming out of Kotlin. That is true. The data you use in SwiftUI does not need to be a struct. Struct support from Kotlin is an ongoing discussion, and we may implement something in the future that extends the interop, and/or down the road there may be formal support in Kotlin. For now, though, if the lack of structs is a show-stopper, then you’ll have an issue.

What’s Happening at Touchlab?

Touchlab is hiring full time and looking for contractors. Mostly Android, some multiplatform in the future: http://go.touchlab.co/trdw

We recently launched The Touchlab Refactory; an incremental refactoring service with KMP which focuses on a single feature at a time with no disruption to your current development workflow. Learn more here: http://go.touchlab.co/refactory