Kotlin Multiplatform Library

Kotlin Multiplatform Library

The following blog post is an overview on Kotlin Multiplatform libraries by the KMP experts, Touchlab. You’ll find a. list of recommended libraries we use today for Kotlin Multiplatform development (including some of our own) b. video recording of Kevin presenting at Øredev 2019 on library development for Kotlin Multiplatform and c. slides from that presentation. 

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

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

Useful introduction to Kotlin Multiplatform resources 

Kotlin Multiplatform Frequently Asked Questions

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

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

How much of my code are we going to be able to share with KMP? 

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?   

KevinIt 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? 

JustinThe 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.

KevinMajor 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? 

JustinEqual 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.

SamKotlin 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? 

KevinNot 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? 

KevinKotlin 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.

How do I encourage optimal code sharing from the beginning? 

JustinFocus 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? 

JustinKotlin 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.

SamIt’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?

KevinKotlin 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?

KevinThe 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?

KevinI 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?

KevinPick 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.

Useful introduction to Kotlin Multiplatform resources 

Introduction to Kotlin Multiplatform

Introduction to Kotlin Multiplatform

Introduction to Kotlin Multiplatform

Using the Kotlin language to program logic that can be used on all platforms of your app, it creates common logic that the native UI of any app can call upon.

KMP 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.

The philosophy that has driven Kotlin since its inception is about enabling developers to code for all platforms. Kotlin is a modern language that allows you to develop applications more cohesively, and dovetails with native platforms on Java, iOS, and the web, so you can build on what’s already been coded. You focus on sharing code that is data, business, or presentation logic, and leave platform-specific components to be implemented natively.

It’s important to note that multiplatform does not mean compiling all code for all platforms. In mobile app programming, for example, you determine which modules are platform-specific and which are common to Android and iOS. Those which you identify as common to both can be programmed using KMP, writing in Kotlin Native.

KMP is a low-risk way to avoid repeating logic to develop applications for iOS and Android more expeditiously and effectively. Ultimately, KMP leads to better code overall. And it’s one of the many reasons why Touchlab is now fully committed to Kotlin as the most viable way forward for development teams today.

As a programming language, Kotlin keeps growing in popularity throughout the world, and with the introduction of Kotlin Multiplatform (KMP), there’s been more and more chatter among the mobile developer community about the possibilities it can bring.

Users’ needs are the same, whether they’re using an Android or an iOS device. Development teams, however, remain siloed by discipline, whether they’re programming for web or Android or iOS.

So, as a software development team, you have some challenging questions. Can you provide consistent quality on all devices when you have different development teams with varying skillsets developing the same apps for different devices? And can you ultimately justify the amount of time, budget, and resources it takes to produce viable solutions? We believe KMP is the best possible way to answer to these questions.

KMP: ready right now

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.

The good news is that there is now a better way.

And a proven way.

We at Touchlab have been writing code in Kotlin and deploying it to Android and iOS platforms, with no hiccups. That’s why we’ve gone all-in with Kotlin Multiplatform.

KMP 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.

KMP 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.

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.

Our experience with Kotlin so far? No siloed teams. More streamlined workflows. Real cross-platform functionality.

Useful introduction to Kotlin Multiplatform resources 

7 ways to convince your engineering manager to pilot Kotlin Multiplatform

7 ways to convince your engineering manager to pilot Kotlin Multiplatform

We hear similar stories when we speak to mobile developers interested in a Kotlin Multiplatform pilot for their team. The story goes something like:

You’re a developer. You’ve seen the growing momentum that Kotlin Multiplatform (KMP) is gaining in the developer community – especially since Google announced it was officially supporting Kotlin as a development language in 2017.  And now you want to try it for yourself. (Or maybe you already have.) More important, you’d like to try it on a live project, with your colleagues at your workplace.


The question is, how do you convince your manager that it’s a viable framework to use? They already have enough to deal with, right? Hard deadlines, pressure to produce faster, test more thoroughly, improve architecture, deal with tech debt… the to-do’s for them go on and on and on.


If you’re convinced (like we are) that Kotlin Multiplatform is the best option for unified development of business logic across iOS and Android – but are not sure how to broach the subject with your manager — we’ve put together seven key talking points for you.

1. “One code base. One team.”

Using Kotlin Multiplatform, we can code business logic across both platforms. That means the team doesn’t have to do the same work twice — once for iOS and once for Android. No duplication. Saves time. Saves money. (And saves a lot of nerves, too.)

2. “Kotlin itself is skyrocketing.”

More development teams are using it, and more individual developers want to use it, whether they’re Android or iOS. It doubled in popularity each year since 2015, and after the Google announcement in 2017, it went stratospheric. It’s especially popular among programmers looking to grow their careers. 

3. “KMP plays nicely with both iOS and Android.”

One way to think about it: Lexus has the same engine as a Toyota — the only thing that’s different is the exterior. Same with iOS and Android. They’re essentially the same under the UI hood, so it’s very straightforward to deploy to either platform with few if any hiccups. 

4. “Using KMP is low-risk.”

It’s not an all-or-nothing proposition. We can do the programming incrementally, one feature or architectural layer at a time, so there’s no disruption to hard deadlines. It’s not a major commitment to pilot a project.”

5. Our team can focus on innovation as well as  production.

If we’re only writing the code once for both platforms, it gives us the potential to focus on fine-tuning the architecture, designing more features, or exploring other innovations because we’re not bogged down in production only. Focus on new stuff or focus on testing. Frees up resources to do more stuff…

6. “Keeping UI separate is a good thing. It ultimately will save us time.”

KMP doesn’t do UI at all, but that’s actually a real advantage for us. Sharing UI across platforms can be risky because it involves doing multiple reworks and workarounds to make the UI work natively on its respective platform. With KMP, we can focus on the business logic specifically, and leave the UI to be coded separately.

7.     “With KMP, we’re future-proofing our business logic.”

KMP doesn’t lock into one ecosystem like Flutter or React Native or Xamarin. It’s easy to take an Android library and make it work as a KMP library – even easier if the library is already written in Kotlin. And of course, Google’s endorsement of Kotlin is a big plus. 

Need help piloting KMP? Apply to KMP Hack Week!

What is Touchlab’s KMP Hack Week?

We’ve talked to teams who have done their own hack weeks, but they end up spending most of the time just getting set up. Our goal is to get you set up quickly with your KMP pilots. We’ll get the setup sorted on Day One, be available to talk KMP thinking, and help unblock for the rest of the week. We’ll also throw in some mini-lectures on topics that all KMP engineers should know.

Kotlin Multiplatform in Five Minutes or Less: Expect / Actuals Statements

Kotlin Multiplatform in Five Minutes or Less: Expect / Actuals Statements

If you’re reading this you’ve probably heard a lot about Kotlin Multiplatform, but aren’t sure where to start. The platform is evolving fast, which means a lot of the docs are out of date, and/or can be a little overwhelming. But nobody likes reading the directions, so I’m writing a series of posts that take about 5 minutes each to run through, and introduce the basics on Kotlin Multiplatform.

Part 1 gets you starting from nothing. This is part 2, which focuses on expect/actual statements. Kotlin’s native interop is one of its most distinguishing features. Unlike other “cross platform” ecosystems, Kotlin is designed to embrace the native platform it is integrating with. expect/actual statements are one of the main mechanisms it provides to do that.

One area that requires platform-specific logic is dealing with dates. We’re going to create a simple expect class, KMPDate, which takes a date format string and lets you create a formatted string representing today’s date.

First, open

/app/src/commonMain/kotlin/sample/Sample.kt. Underneath the Greeting class, create a new expect class:

expect class KMPDate(formatString: String) {
    fun asString(): String

The expect keyword declares that the common code can expect different actual implementations for each platform. In this case, expect applies to a class. However, it can also apply to functions, objects, annotations, etc. See here for more.


Go to /app/src/main/java/sample/SampleAndroid.kt to create the actualAndroid implementation. Underneath the MainActivity class, add the following:

actual class KMPDate actual constructor(formatString: String) { // 1

    private val dateFormat = SimpleDateFormat(formatString) // 2

    actual fun asString(): String {
        return dateFormat.format(Date()) // 3

1: The expect declaration of KMPDate stated that it takes a formatString, so an actual constructor implementation accompanies the actual classimplementation.

2: Create a SimpleDateFormat object using the formatString. iOS has an NSDateFormatter class, which is similar to SimpleDateFormat, but we’ll get to later. There is currently no common Kotlin implementation, but for most things, Android and iOS have equivalent features available.

3: The SimpleDateFormat object formats Date() — which produces a Dateobject representing today’s date — into a string.


Next, go to

app/src/iosMain/kotlin/sample/SampleIos.kt, which is currently empty. Paste in the following:


actual class KMPDate actual constructor(formatString: String) { // 1

    private val dateFormatter = NSDateFormatter().apply { // 2
        this.dateFormat = formatString

    actual fun asString(): String {
        return formatter.stringFromDate(NSDate()) // 3 


1: Identical to the actual class declaration on the Android side.

2: Pass formatString into an iOSNSDateFormatter object, which — as mentioned earlier — achieves the same result as SimpleDateFormat on Android.

3: The NSDateFormatter object formats a string based on NSDate() — which produces an NSDate object representing today.



Finally, go back to

/app/src/commonMain/kotlin/sample/Sample.kt. Inside of the Greeting class, create a KMPDate object that takes “MMM dd” as its date format:

private val date = KMPDate("MMM dd")

And last but not least, use string interpolation to insert the formatted date string from each platform into the value of hello():

fun hello(): String =  "Hello, Android and iOS worlds, today is ${date.asString()}!"


All done! Run you Android and iOS apps and see the dates displayed on each platform!

If you come from an iOS background and want a deeper explanation of how to use Kotlin Multiplatform to make a more involved app, then you might want to check out this article I wrote.

As you can see, it’s all about starting small with Kotlin Multiplatform. 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.

We’re hiring!

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

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):

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