I seem to have failed in my bid to convince management to adopt Kotlin Multiplatform, despite (I think) making a strong case for the technology and even doing considerable PoC work. Their reason? JB consider it 'Experimental' and so the business consider it unsupported. It's a hard one to talk around. I tried telling them about the considerable focus it's receiving from JB, and that the 'Experimental' tag was conservative, it's in production etc, but they don't see it. Any clues when JB are likely to stop considering the core K/MP feature as 'Experimental'?

It was also a show stopper when we wanted to introduce KMP for a big customer app. This little word convinced them to not use KMP, yet. I expressed this problem with the product team from Jetbrains as well.

Thanks & commiserations @Jonas Bark , you put it well- so much personal investment and in the end it came down to that single word - not even mine!

Our management is more open to change and I have experimented with multiplatform. After these experiments I have decided to not use multiplatform myself as it is still pretty raw and there is a lot pain along the way.

I’m gonna be honest here. In my company we’re more free to do whatever we want, so I’m using KMP in production, and I’m currently working on an iOS app with 100% Kotlin (no ObjC/Swift/XML interface). I just have to say that KMP IS experimental. For now I feel like all the time we gain from developing some things only once was lost fighting KMP bugs (More specifically K/N bugs) and development is also slowed down by very bad IDE performances and compilation times in general. I’m really not sure we gained time yet using KMP. But damn, it’s fun to use TL;DR if I was responsible for choosing to use KMP or not in a top 500 company I would chose not to right now. Anyone convinced it will not be something huge in the near future is an idiot though.

I feel the experimental part is more about "the API will likely change with each update". After tackling some obstacles (mostly Kotlin Native related) we felt it to be really stable if you follow a few guidelines. We're also running it in production already. I would definitely choose it to achieve code sharing across platforms but most of our new customer get Flutter apps instead as they don't care about weather it's fully 'native' or not.

Well my opinion is based on my previous work at one of the biggest tech companies (300k+ employees). The 50+ yo engineers I met there are definitely not ready to follow the very quickly changing environment and would likely let projects die instead of updating them. In a very young company like my current job there’s no issue. I don’t know where the line is

I'm a big KMP advocate, but it absolutely is in the early adopter phase right now, and it's extremely reasonable that a lot of organizations don't want to jump into that yet. Super excited to build things with the organizations that do, though. But it is important to be realistic about the fact that things are still moving quickly, and there's a number of pain points like backward-compatibility that can be show-stoppers for larger and more conservative teams.

experimental means that it is 1. incomplete - take for instance the concurrency story for native, and 2. will have breaking changes. however, what they release is stable.

It's early adopter, but "experimental" is the wrong word. Tech people can plan around something like "alpha" and "beta", but "experimental" implies something else. I'd disagree on the "gains are offset" point, but ymmv.

i did say the efficiencies we've gained

Yep. I did say ymmv

🙂

the things i have done with kotlin/JVM I could not do with KMP. at this time the insights I've gained from using Kotlin/jvm and having more exposure to the Haskell side of things than in other languages has given me insights where Kotlin/* is a fit for a job and some ideas how to build cleaner c++ ports of the critical features. I can't get behind gradle as a cross platform option, something doesn't add up there.