Why Kotlin Multiplatform Won’t Succeed

Kotlin Multiplatform (KMP) is destined for mediocrity.

KMP never gain mass adoption and will it remain in obscurity; only to be used by a small subset of the software world, regardless how much it is promoted and touted as the next best thing.

Why?

Human nature and scarcity.

Ego Investments

The technical achievements of KMP are amazing. No doubt about it. Being able to target multiple platform’s with one codebase and one language is a great technological achievement and should be celebrated. Kudos to the teams of people that have been able to make this happen. It works, I’ve seen it and I’m sure it will work great for some people and companies.

But … KMP will fail to reach mass adoption because of human nature.

People resist change and anything that is unfamiliar to them.

Some people can be convinced, but most will not. There’s a lot of ego investment in your technology stack and getting someone to change their opinion, while possible, is very difficult.

Have you ever tried to convince an iOS developer or a JavaScript developer to try Kotlin for their main language or for major components of their app? Ha! That’s a fun conversation …

“Ok, I’ll need you to install the Java … “

You lost 90% of them right there. They nearly all want to run for the hills. Java and the JVM have a great reputation in JVM circles (Java, Kotlin, Groovy, Scala, etc) but outside of that world people run as far away as they can from Java.

It’s sad, but true. I’ve seen it multiple times in the last 20+ years of software development and I still see it to this day.

The same could be said on the flip side. Convince a JVM developer that they need to install Apple tooling so they can write some Swift for their Android or backend project. Most will be repulsed. Its human nature.

We’ve Been Down the Multiplatform Road Many Times Already

Unfortunately, history repeats itself in software quite frequently.

We’ve been down the multiplatform road a number of times and it’s never become the panacea of development that proponents of each technological revolution claim it will be. All for the same reason I explained above … human nature.

For me, the first time was with Java in the late 90s and early 2000’s. Everything can be Java, remember? Applets, Java Apps? Ugh.

Then we had Flash and ActionScript.

Then we had Silverlight.

Then we had Mono and Xamarin.

Then we had the huge JavaScript revolution (which is still in full swing).

Then Flutter (which is still going too).

… and now we have KMP.

I’m sure there are others I’ve missed, but you get the gist.

Not once has one of these platforms has taken the software world by storm. The one that has gotten the most traction is JavaScript, but it still has not taken over the world.

Each one faces the problem of changing human behavior. Behavior that is rooted in an ego investment in a technology that is not the multiplatform technology of the season.

The Polyglot Programmer and Lack of Unicorns

When you start developing apps with tools like KMP or any of the other multiplatform technologies I’ve listed above you start running into issues where you need to know multiple languages and platforms. You need to know Kotlin, how the JVM works and packages its libs, dependency management, how KMP does this, then you need to know how to get his to work with iOS and the other platforms you’re working with. Oh, by the way you’re using Swift over there on iOS so you need to know some of that too.

The list of things you need to know in order to ship on various platforms just gets longer and longer. The more things you need to know the smaller pool of talent there is to do this kind of work.

Polyglot programmers exist, but good ones are like unicorns. They’re nearly impossible to find and when you do find them they’re insanely high in demand and very expensive. I know, I’ve been down this exact road before.

Furthermore, great polyglot programmers do not stay true multiplatform polyglot programmers for long. Sure there are some exceptions, but for the most part, most of them burn out and then choose a couple of technologies they love and focus on those. Technology moves too fast to keep up with many platforms at once. Its impossible.

Keeping yourself up to date with one or two technologies is difficult as it is, now doing this for more targeted platforms and how they integrate? Pfft. Good luck. Hello burnout.

You never truly get to use one platform when you target other platforms. You have to integrate with them eventually and you will run into issues. Anything past the simple demo’s will expose you to some of the wild integration you’ll need to do. You can’t escape it. In other words, you’ll always need to get your hands dirty with multiple platforms and languages when using a multiplatform solution.

When you get tired of doing it, or need to find additional help, and often you need good help … good luck, because finding people like this is like hunting for a unicorn.

Multiplatform Technologies are Square Pegs Looking for Round Holes

I’ve been saying for a long time now that we need to use the right tool for the right job. I’ve also been saying that the web will win the war of software (mobile vs desktop vs web based), but thats me saying that things will transition to the web as we progress through time. Its a transfer of technology implementation. What I’m trying to say is that as some technology improves we’ll see a transition from A→B. In other words, we’ll use the right tool for the right job at the right time.

What does this have to do with KMP? Well, KMP will work for some companies/people but for most it’s simply the wrong tool for the job.

The same thing can be said for tools like Flutter. Flutter works great for creating both apps at once, but when we start wanting to create HTML sites with it and other implmentations, we start to get that weird nagging feeling that we’re doing something wrong. In the back of your head you wondering “Is this really the right tool for the right job?”? You know its not, but for some reason the developers of said tech think it is.

Just because you can use technology x to solve a problem, doesn’t mean you should.

Sure, I can trim a shrub with a butter knife, but its probably not right tool. It’ll work though. See what I mean?

You might use Ktor and Kotlin for your backend and the next person might use Node and Express, and the next person might use Ruby on Rails or .NET. All good. We might use Kotlin for Android apps and Swift for iOS and HTML for web apps. Right tool. Right job. But anytime we start to say “this one tool is the solution to all of our problems” is when we start running into problems. It always happens with multiplatform tech.

Just because we can, doesn’t mean we should.

You will encounter a lot of problems when you try to start using a multiplatform solution for something its not intended for. You’ll run into edge cases that are difficult to develop, debug and implement.

For example, what if a new feature comes out on one platform and you want to use it? If you’re using something with multiplatform you can only use it if your multiplatform solution is up to date – and that might not happen for awhile, and if it does, sometimes there are bugs in the integration between it (I know … I know … there are exceptions to every rule).

If you have a great multiplatform tool, usually these issues are few and far between, but I’ve run into enough of these issues with various different multiplatform tools that it has become a royal pain in the ass work around at times. Absolutely frustrating when it happens. Its times like that when I wish I had used the right tool for the right job. Maybe Swift for iOS or JavaScript/HTML for web stuff, or some back end server tech and not some other tool thats pretending to do the work of another tool.

Ultimately what this feels like is that you’re shoving a square peg into a round hole because things just don’t feel right, but you’re using tool X so you have to do it that way. Many people feel this way and its part of the human nature of it. Apply enough force, hit it hard enough with a hammer and it will go in, but it doesn’t mean that it will be pretty or fun in the end.

Same for KMP. Most people won’t use it because to them its like shoving a square peg into a round hole. A JVM based library to help build iOS apps or multiplatform desktop apps? Wait, what? It will work, it just takes some finagling. That frustration is not worth it for most people. Its more cognitive load than they want to deal with.

Furthermore, sometimes these multiplatform SDKs and libraries that are built with KMP will have a structure/architecture that other platforms (iOS, etc) do not agree with. This then leads to more discussions, arguing, and burden across the engineering organization. So unless the teams have agreed upon an implementation contract that both will adhere to, you’re bound to run into some walls from the other platform engineering.

However, this is not to say that KMP wont have some success…

Where KMP will be a Success

KMP will be a success for some people and companies. These are going to be companies where they have a large staff of highly qualified KMP developers who have a deep understanding of the platform and who also happen to be polyglot programmers. For companies like this (and there are a few), these teams can write the shared components and help integrate other teams with the KMP work they’re doing. They know how to convince and communicate with other teams and stakeholders to get the buy in. They can and will agree on a common interface contract between KMP and the platform of choice and everything will be harmonious. This is amazing.

For them, given their company and technology culture, this is a shoe-in win.

For most other companies though, this will not happen. People are stretched too thin, don’t have the time to focus on multiplatform technologies and simply don’t have the energy or desire to champion the merits of the multiplatform technology. They have stuff to get done and a life to live and they don’t want to sit in yet another meeting discussing why KMP is or isn’t good for them. They have a deadline to hit and they need to get their work done and then they want to go home.

We may also see some success with startups who have a big JVM heavy team who can ship things faster this way. The same same for solo-devs and independent consultants and founders who build their own products. They will have success with this as well.

For some folks, KMP is a great tool and they should use it. However, I do caution the folks that are building things for others to consume as integration pains are real.

Furthermore, I’m not sure how building a company on KMP would impact its ability to be acquired. In fact, I’d love to have a chat about this with some M&A folks to discuss the risks of said technology. Maybe its a positive, maybe its a negative. Its hard to say without really talking to these folks. I’ll save that for a future post though.

Scarcity is Expensive

There’s one common thing amongst all people I mentioned above who will make KMP a success: They’re all very rare.

When something is rare, by it’s nature it’s scarce in availability. Scarcity drives cost up.

In other words, finding people who can do these things will be expensive for companies. Maybe its worth it for them, and others it wont be. But this is something that engineering leadership needs to pay attention to. There are long term implications of using technology like this – you need to be able to find people who can and want to work on it. Often times, these people are very expensive.

Right Tool Right Job

I don’t think KMP will have mass success in the market simply because its not the right tool for the right job for most people. However, it will have some success in small circles.

Its an amazing piece of technology innovation and I’m impressed to see how it works, I just don’t think it’s the right tool for the job, personally. I’d much rather use Swift on iOS, Kotlin on Android, and HTML/CSS for web apps, and a proven desktop tech for desktop software. Same for embedded.

I am a pragmatist developer and I don’t discriminate on based upon my tech implementations, though it may not seem like it here. I’ve written things in multiplatform technologies, I’ve written large apps in React, Kotlin, I’ve done Python, .NET, Java, Rails, Django, Go, React Native, Flutter, Xamarin and more. I’m not afraid to try something new. But with each multiplatform tech I’ve tried there’s one common result that ends up emerging as things get complicated: I wish I had used the right tool for the right job.

The challenge we face as an industry is our inability to let go of our ego investments in favor of our favorite technology. If we don’t let go of these ego investments we risk them polluting our decision making, and that has long term down stream effects.