Touchlab KotlinConf 2019 Recap

Touchlab KotlinConf 2019 Recap

Touchlab attended KotlinConf 2019 in Copenhagen, Denmark. As anticipated, the conference was a milestone event for the development of Kotlin Multiplatform and its community of practitioners and contributors.

VIDEOS! There will most likely be ‘official’ videos published soon, but the content is already up in the live stream so we organized links to each talk for you.

This post also contains reactions to Kotlin Multiplatform sessions attended by Touchlab’s Ben Whitley (multiplatform mobile engineer with iOS background) and Kevin Galligan (Partner).

Before we jump in, we’d like to call out two important moments from the conference:

1. During his keynote, Kotlin Lead Language Designer Andrey Breslav highlighted Touchlab as a critical community member to JetBrains’ mission to usher in a new era of mobile development with Kotlin Multiplatform (view clip).

2. During the closing Q&A panel an audience member asked about approaches for getting iOS developers onboard for a KMP pilot. JetBrains’ VP of Developer Advocacy Hadi Hariri recommended organizations speak to Touchlab as we’re actively working with clients on this exact topic (view clip).

Thursday Recap

Opening Keynote by Andrey Breslav (view keynote)


Pre conference take

The KotlinConf keynote is must watch for anybody that’s interested in Kotlin. Any major new stuff will be announced.

Ben’s reaction

  •  Think of Kotlin as an entire ecosystem, not just a language. 
  • The goal is to make Kotlin the default language for starting any project and make it a universal solution for every platform. For any and all levels of experience, platforms, scales, and application.
  • Dropped the term “full-stack Kotlin” which I personally hadn’t heard before.
  • No major new features in Kotlin 1.4. Focus is on quality and performance, which is smart, given the current build times. 


Kevin’s reaction

  • They are very focused on making Multiplatform a reality. 
  • You’ll be able to run/debug native iOS apps from Android Studio. That will be a huge adoption driver.  
  • 1.4 will bring a lot of stability and performance/compiler improvements, which will be a big deal.

Sharing Is Caring – Kotlin Multiplatform for Android Developers by Britt Barak (view talk + slides

Pre conference take

This will be a good intro talk. It includes not only native, but JS and backend code.

Ben’s reaction

  • Getting started (aka project configuration and setup) is currently the biggest pain point. Something we can probably all agree on. 
  • Big plurality of different needs, and therefore different architectures. This is still an open ended issue for KMP, and one we’re very familiar with at Touchlab. Because there’s many different use cases and it’s still open ended, this wasn’t intended as a talk on KMP architecture.
  • is a very cool resource to find packages
  • Overall a really good getting started talk, even though a lot of it was very familiar for us at Touchlab.
  • I’d strongly recommend checking out the video of it for Android developers interested in KMP. 


MPP in 1.3.X and beyond by Dmitry Savvinov and Liliia Abdulina (view talk)

Pre conference take 

Another KMP intro, from JetBrains engineers

Ben’s reaction

  • Future goal is a complete KMP ecosystem
  • A lot of the talk was a history of KMP through Kotlin versions up until this point
  • Included a shoutout to Touchlab


Kevin’s reaction

  • For the future they’re going to focus on docs and onboarding much more, as well as for specific use cases like native mobile. The team had been much more focused on “general” multiplatform.
  • The original discussion of “multiplatform” started in 2016, which is around when Kotlin JVM was 1.0. JS has been around and in use significantly longer than native.

Coroutines! Gotta catch ‘em all! by Florina Muntenescu and Manuel Vivo (view talk)


Pre conference take

Concurrency for native will be mostly centered around coroutines, so an intro to coroutines is valuable.

Kotlin Multiplatform in Action: more than 10 projects for iOS and Android with Shared code by Alexandr Pogrebnyak (view talk)


Pre conference take

IceRock has been shipping KMP for a while, and has published templates and libraries to help. This will probably be a useful talk for practical KMP advice.

Kevin’s reaction

  • Have released a set of libraries targeted at native mobile development that we should review for use on projects
  • They have a shared UI library for native mobile. Uses native widgets to render. That’s a lot of work to build but assuming we can mix with fully native screens, this is something we’ll be taking a look at.

Bridge the physical world: Kotlin/Native on Raspberry PI by Qian Jin (view talk)


Pre conference take

More Kotlin Native. It’s being deployed to an IOT device, which may be interesting to see.

Your multiplatform Kaptain has arrived by Ahmed El-Helw (view talk)

Pre conference take

Careem is shipping KMP in a major platform. This is critical info for orgs getting serious about KMP. We’ll be there for sure.

Ben’s reaction

  • Very early users of KMP
  • KMP exciting and nerve-wracking for management
  • Communication processes were a solution to problems between iOS and Android teams
  • This is a very good “lessons learned” type of talk
  • Shoutout to Touchlab generics patch and Kevin’s blog post about generics 
  • Mentioned basically everything Kevin has put out there at this point, including CrashKiOS and Xcode Plugin. 
  • Ended with a cool/funny poem (last pic)

Shipping a Mobile Multiplatform Project on iOS & Android by Ben Asher and Alec Strong (view talk)


Pre conference take

More KMP-in-production experts. We work directly with the Square team doing this, and chat often with Ben, so we’re very much looking forward to see what they have to say.

Ben’s reaction

  • High initial setup cost for KMP, will be worth the effort
  • Features develop parity even if they start out the same (or similar). Good point, not discussed enough
  • Shout-out to Kevin’s concurrency talk. They recommend doing the suspend and lambda methodology (which is what we do pretty regularly).
  • Pros and cons of monorepo, which is under discussed good con for iOS devs: they often don’t even have JVM.
  • Didn’t mention Touchlab CrashKiOS, which is exactly what they need for the improved crash reporting they want. 


Kevin’s reaction

  • Square and PlanGrid are some of the earliest shipping apps, and have really had to figure out a bunch of the stuff.
  • I’ve been involved directly with Square, and have worked a fair bit with Ben because they ship on Windows, so we’ve been publishing our libraries to Windows.
  • Great thoughts for introducing your team to and educating your team on KMP.
  • Pick something that the teams don’t like and/or that’s fairly critical and needs to run the same. Sync for PlanGrid and transaction search for Cash.
  • Stopped taking notes because my talk was happening after theirs


Kotlin Native Concurrency Explained by Kevin Galligan 
(view talk + slides)


Links included in Kevin’s talk

Pre conference take

If you want to do KMP on native, you need to understand concurrency. This is our talk, and a must see, obviously

Friday Recap

I Walk The Line: What Parts Of An App Should be in Kotlin Native – and What Parts Shouldn’t? by Ellen Shapiro (view talk)


Pre conference take

Ellen knows mobile tech, and brings a lot of iOS experience to the KMP equation. We’re definitely checking this talk out.

Ben’s reaction

  • Developer enthusiasm is key to adoption of cross platform products
  • Gave away copies of Ray Wenderlich Kotlin book to people who ask interesting questions – good idea for engagement
  • Ellen came up with MVSP (Model ViewState Presenter) architecture to replace MVP. It’s a form of unidirectional data flow partially inspired by SwiftUI
  • Shoutout to Kevin’s talk yesterday, she said “it goes into a ton of detail” 
  • Know why you’re using Kotlin Multiplatform, that will dictate how much and what KMP you should do

Going Native: How I Used Kotlin Native to Port 6 Years of Android Games to iOS in 6 Months by Ana Redmond (view talk)


Pre conference take

Ana got into native early on and has done very interesting work. This will be a really good talk.


Ben’s reaction

  • Ana is a perfect example of what Kevin (and Ellen in her talk) says: if you’re going to do cross platform or common code, know why you’re doing it. 
  • She’s using KMP for shared UIs; very difficult and impressive. As she says, this is possible because of few external dependencies (basically none), which is why this is a good use case for shared UI.
  • She wrote her own KMP WeakRef wrapper to avoid retain cycles in iOS, pretty smart and cool. Has its limitations, won’t catch retain cycles across KMP and native code. 
  • Lessons learned
    • Classes > Objects: to avoid the threading and mutability issues that Kevin’s always talking about
    • Lists > Arrays: this is vindicating as I’ve found this myself and I’ve been saying it for a while now
    • Initialization order: she found very weird behavior in overriding initializers in KMP. See corresponding pic. Something we’ll be looking into at Touchlab. 

Effective Kotlin-Swift Interoperability by John Rodriguez (view talk)


Pre conference take

Kotlin/Swift communication is a huge topic for KMP. Improving the situation for iOS developers will be critical for adoption, so this is a critical topic to understand.

Kevin’s reaction

  • Went very deep on interop details. I learned some new things, especially WRT enums.

Kotlin/Native: Answers Your Won’t Find on the Internet 
Eugenio Marletti (view talk)

Pre conference take

Eugenio is a member of the JetBrains developer relations team, focused on KMP and native. He’s going to be critical to improving the documentation and onboarding experience, so you should definitely check this talk out.

Kotlin Multiplatform Sessions Touchlab is Attending at KotlinConf 2019

Kotlin Multiplatform Sessions Touchlab is Attending at KotlinConf 2019

Touchlab will be attending KotlinConf 2019 in Copenhagen, Denmark. We anticipate the conference to be a milestone event for the development of Kotlin Multiplatform and its community of practitioners and contributors.

If you’re in town, please let us know because we’d love to meet with you.

If you’re unable to attend the conference, no worries. We’re hosting a Kotlin Multiplatform Fireside Chat in New York City for engineering managers. We’ll discuss and review all the KMP updates from the 2019 conference. Register here.

The following is a list of KMP talks we’ll be attending. If you’d like to be notified when the live stream for these sessions is available, register on the KotlinConf website.

Day 2 (Thursday, December 5th)

Opening Keynote by Andrey Breslav  

Time: 9:00 – 10:00

Our take: The KotlinConf keynote is must watch for anybody that’s interested in Kotlin. Any major new stuff will be announced.

Day 3 (Friday, December 6th)

Nice to See VMWare Adopting Kotlin Multiplatform

Nice to See VMWare Adopting Kotlin Multiplatform

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

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!

    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 

    Mobile Code Sharing with Kotlin Multiplatform

    Mobile Code Sharing with Kotlin Multiplatform

    Native mobile development for iOS and Android generally involves writing two (2) separate code bases, picking an “all in” cross platform tool, or using some form of code sharing to bridge the gap.

    For long-term mobile developers, there is a sense of dread around any form of “cross-platform” due to generally negative experiences and outcomes. Then tooling and ecosystems are generally bad, the performance is often bad, etc.

    There is nothing about the native tools that make them inherently better options, other than Apple and Google have huge incentives to make great apps for their platforms, and the teams that make the tools control the platforms. Other technology that intends to “keep up” needs to find its own incentives (and, by extension, funding), and needs to be very careful not to try to beat the native platforms at what they do best.

    Native developers tend to talk about “cross-platform” as one concept, with all tech being rolled into “native” and “cross -platform”. In reality, all these options vary considerably and it’s important to define them appropriately so we can discuss which options are better for which circumstances.


    The most concise definition of Kotlin Multiplatform I can give is as follows:


    • optional
    • natively integrated
    • open source
    • mobile code sharing platform
    • based on the popular, modern language Kotlin
    • facilitates non-UI logic availability on many platforms



    Optional means the tech is designed to be used along with the native tech. Most cross-platform frameworks allow you to integrate them into existing apps, but are generally not designed to make that easy. “Possible” is not the same as “actively designed for”.

    The optional sharing nature means it is easy to evaluate KMP in your existing apps. You can add code incrementally, and critically, if some shared code isn’t performing as expected, you can “just code it natively” without any major issues. The optional sharing nature makes KMP low-risk.


    Natively Integrated

    Other code sharing solutions, such as C++, JS and Rust, generally involve a bridging layer. C++ is “native”, but from the JVM you need to talk to it through JNI. That will have extra code and performance implications. The same goes for other code-sharing frameworks. They run in their own expected runtimes, with their own expected rules. Kotlin was designed to interop with the JVM directly, and Kotlin Native has been designed to use LLVM to produce actual “native” code.

    For iOS, the Kotlin compiler outputs an Xcode Framework that Objective-C and Swift can communicate with directly. It looks like any other Objective-C framework, and with Swift ABI stability in 5.1, we can expect direct Swift interop next year.

    Native integration dovetails with optional code sharing to reduce barriers to integration (easy to call, low-performance impact, etc) and reduce risk.

    Open Source

    Most new languages and platforms are developed as open source. It would be very difficult to create a closed source ecosystem in 2019. Not only does open source significantly reduce the risk of debugging issues, but it also allows the community to participate in the platform development.

    To help ensure good public direction and guidance, Jetbrains and Google, along with other industry representatives, created the Kotlin Foundation to help steer future Kotlin direction.


    This is important.

    For libraries, support, training, hiring, etc. The ecosystem you pick needs to be popular. Having a very small ecosystem introduces it’s own form of risk. Kotlin Multiplatform is currently small, but growing very rapidly. It is very unlikely to lose momentum now. There will be an early adopter impact, but there’s also an early adopter opportunity.

    For teams that want to be involved in open source, and to be able to recruit developers interested in new tech, it’s a great time to get involved.


    Kotlin is a changing platform, attempting to incorporate lessons from other languages and ecosystems. This will mean better productivity and safety, and a longer “shelf life” for the ecosystem as a whole. It is a future-proofed ecosystem.

    Mobile Code Sharing

    It is important to distinguish “code sharing” from “mono-UI” and other cross-platform technologies.

    One of my own favorite quotes is:

    “The history of shared UI has a lot of pain and failure. The history of shared logic is the history of computers.”

    Speaking of native mobile specifically, Android and iOS are very similar under the hood. They’re both Unix-y, have files, threads, networking, sqlite, etc. If the tooling was great, and the integration was seamless, it would be crazy not to create a shared codebase for at least some of the logic and architecture of applications. You can write it once, test it once, and only pay one cost for maintenance.

    Code sharing is in contrast to shared UI, and “3rd platform” architectures. Picking Flutter, or React Native, or Xamarin (Ionic or any web thing, etc) means you will make a heavy investment in that platform. They don’t integrate well with the native ecosystems. They are what we call “Big Decisions”, and stress “Capital B, Big Decisions”. Big decisions are risky. They take effort to make. You need to train/hire for another 3rd platform. You need to recode a bunch, and/or write bridge code to the native code already in your app. You will likely need to fill in gaps that don’t exist. You need to accept the risk that the primary developer of the platform may decide to stop supporting it.

    For that reason, it’s very important to understand the financial incentives involved. Most of these tools are free. If you aren’t the customer, you’re maybe the product. In any case, these frameworks and tools aren’t free to make or support, so why they’re made is an important consideration. As the risk increases, the investment and reliance on that tech should decrease, which is the opposite of how most cross platform options are architected (i.e. they want you to do everything in their tool, and take on more of that risk). 

    As a side note, Kotlin is the preferred language for Android. In the case of native mobile, this makes Kotlin unique for code sharing. C++, JS, Rust, Go, etc can all be used, but none of them is the “preferred” language for either platform. In the case of KMP, there’s no “3rd” ecosystem. Again, going back to risk, not adding a 3rd language is important. Also, because of how Android the Operating System is created and deployed to actual devices, there tends to be a much wider range of versions and issues. Being able to avoid adding any risk to the Android side is a huge benefit.


    The final important note is that Kotlin is made by JetBrains. They make some of the most popular tools for developers in a wide range of language ecosystems, but have absolutely dominated the JVM tooling world. Developer experience is critical for adoption, and if anybody else was trying to build a shared code solution at this scale, I’d say their chances aren’t great. The tooling is still in development, but if anybody can pull it off, it’s JetBrains.

    JetBrains is a profitable company that sells developer tools to developers. They do not share the risk of venture-backed open source (Parse, Realm, etc). It is *possible* that they’ll sell to somebody, but there is no existential threat forcing them to do so. I started using their Java IDE back in 2000. That is ancient in the tech world. They have thrived using the old model of making and selling a product, and it’s likely they will continue doing just that.

    Useful introduction to Kotlin Multiplatform resources