Nice to See VMWare Adopting Kotlin Multiplatform

I saw Hadi’s tweet and I couldn’t agree more.

Nice to see VMWare adopting Kotlin/Multiplatform. https://t.co/poaJY0hKHI— Hadi Hariri (@hhariri) November 18, 2019

There are more and more (respected and influential) companies experimenting with and talking about Kotlin Multiplatform. Some have put it into production already. 

Personal Thoughts

Here are a few quotes from VMWare’s post and my thoughts:

Experimental Technology

Kotlin Multiplatform is still an experimental technology. It’s very early on in its days, and is subject to breaking changes going forward.

There are a lot of people who are afraid of this, but we should remember that Swift was also in that state until version 4, and version 5 was the first to introduce binary stability so binary frameworks would work with future releases of Swift. That didn’t stop people from learning it, experimenting with it, and putting it into production. Because they trusted Apple.

JetBrains has a long history of building developer trust. The Kotlin Multiplatform early adopters trust JetBrains. And, it is again, well deserved. Android Studio is built on IntelliJ and Google made Kotlin the official language of Android starting in 2017. You and VMWare aren’t risking much to experiment with Kotlin Multiplatform now.

Library Support

One issue you will most likely encounter with Kotlin Multiplatform, is that the set of libraries that support it are very small at this point

This is true. And that’s why Touchlab is working with Square and developing the xcode-kotlin plugin and making SQLDelight the recommended multiplatform persistence solution (see @joreilly ‘s writeup) and we want to support and elevate community projects when we can, like Multiplatform Settings and more.

And, of course, JetBrains isn’t letting us down on this front. The most recent example is ongoing work to support multithreaded coroutines in Kotlin Native. It’s one of the biggest missing pieces and it’s getting very close to ready.

Leverage Native Android and iOS Libraries

It wasn’t the most elegant solution, but it was better than writing our own version of libphonenumber by a mile (or several).

The interop story is really where Kotlin Multiplatform shines. Other solutions require bridges, channels, JNI on Android, and/or excessive boilerplate. When you run into the “set of libraries” issue above, you can still use existing, battle-tested libraries from the native ecosystems.

This interop story also allows for incremental refactoring that significantly lowers the risk of adopting an “experimental” technology. I wrote about this in some detail in Kotlin Multiplatform Can’t Do It All. Which is Exactly Why You Should Try It!

More to Come

Stay on the lookout for follow up posts where I will talk more about additional features, issues, and how to get the most out of Kotlin Multiplatform

I am very much looking forward to more. And I hope you all are too!