Long story short, I decided to jump into Kotlin Multiplatform development after actively ignoring it for years, because I believe KMP is the best long-term investment in the mobile tech stack today.

My Long-Standing Skepticism Towards Multiplatform Frameworks

For more than a decade, I watched the multiplatform wars, revolutions, and failures in mobile development from a distance. I built toy projects with some of these technologies, but never used them professionally. This strategy worked well, as it saved me and my clients a lot of time and frustration.

Kotlin Multiplatform used to be just another framework I chose to ignore. In fact, in some ways, it seemed like the riskiest bet, because it was the youngest option, used a unique and complex architecture, and Google was heavily invested in promoting Flutter.

In September 2020, I invited Aleksey Mikhailov, the CTO of IceRock Development, for a long conversation about KMP. Aleksey is one of the top KMP experts in the world and had been using this technology to build apps for clients since the early days. However, even though Aleksey was confident in KMP and shared real success stories, I left that discussion feeling that KMP was still too immature for me. [Summary of that conversation here].

Fast-forward a few years, and it feels like we’ve reached a tipping point with multiplatform frameworks and they are finally ready to go mainstream. In my 2025 annual review of the Android development ecosystem, I said that it’s time for me to pick and master one of these tools. But which one? The options were React Native, Flutter, and KMP. So I spent time researching and comparing them.

Then, a few months ago, I had the pleasure of hosting Aleksey Mikhailov again. We talked in detail about the state of Kotlin Multiplatform in 2025, covering both the core tech and the ecosystem around it. That conversation sealed my decision to adopt KMP.

Kotlin Multiplatform is Strategic to JetBrains

Mastering a new framework is a big investment. That’s why I want to see real strategic interest and long-term support from respected and reliable companies. For me, this is more important than any technical detail, like the programming language or architecture of the framework.

KMP is built by JetBrains, one of the best tech companies in the world. JetBrains has technical excellence in its DNA and is known for dogfooding its own tools.

For JetBrains, the rise of other multiplatform solutions, most of which promote the free VSCode as their “main” IDE, puts pressure on their position in the IDE market. On top of that, the market for AI tools (like Cursor) might become even bigger than the IDE market, so JetBrains obviously wants to get its fair share. In this situation, attracting developers into their own technology stack, which is free to use, is a great way for JetBrains to promote their premium products.

So, the success of Kotlin Multiplatform is strategic for JetBrains. In fact, if KMP fails, it could even threaten the company’s long-term future.

Kotlin Multiplatform is Strategic to Google

For Google, KMP is a bitter-sweet pill. As I explained several years ago, after Google won the lawsuit against Oracle, both Fuchsia and Flutter lost their importance as strategic hedges in case Oracle had won. For Fuchsia, this was probably the end of the road. Flutter, however, could still be useful as a hedge against React Native gaining significant developer mindshare.

But Flutter didn’t succeed in that role. It mostly attracted individual Android developers and agencies, while React Native remained more popular among product companies and institutions, especially in the US. When Shopify adopted React Native, it gave the framework even more credibility and support. On top of that, React Native benefited the most from the AI revolution, since AI tools tend to work better with web technologies.

So, Google found itself at real risk of losing control over the developer ecosystem to Meta. What seems to have happened next is that Google chose Kotlin Multiplatform to serve the same goal: give developers a solid multiplatform solution, which is at least partially under their control, and prevent them from switching to React Native. This explains the much stronger focus and investment in KMP by Google over the past year or so.

Therefore, Kotlin Multiplatform is strategic to Google, because they now face a serious threat of Meta taking over the mobile development ecosystem. That would make it easier for Meta to launch a competing operating system or hardware, if they ever choose to.

Kotlin Multiplatform Offers the Best Migration Path for Existing Projects

The authors of KMP chose to play on hard mode when they started the project. While Flutter and React Native try to abstract the details of the underlying platforms (using different methods), KMP allows for relatively smooth integration with both Android and iOS native frameworks. This architectural choice makes building the framework more difficult and raises the entry barrier for new developers, but I believe it will prove to be better in the long run, for several reasons.

First of all, while most multiplatform discussions focus on building new apps, the existing native apps, developed over the past 15 years, make up a much larger part of the market and employ more developers. So, offering older projects a low-risk and convenient migration path to multiplatform is a big advantage. KMP is great at this because its native-friendly design supports truly incremental adoption. Whether you want to share just some complex algorithms, or networking layer, or business logic, or user interface code, Kotlin Multiplatform supports all of these, as well as their combinations. On top of that, KMP produces standard library formats for each platform (.aar for Android, .xcframework for iOS), so you won’t need another toolchain and sharing non-UI logic won’t add tens of megabytes to your app’s binary size.

Kotlin Multiplatform Supports Both Multiplatform And Native User Interfaces

The user interface story in Kotlin Multiplatform deserves a mention on its own. Basically, KMP lets you choose whether to share the UI logic or not. In fact, until recently, it didn’t even provide a multiplatform UI option, so almost all KMP apps were built with separate native UIs, such as Jetpack Compose for Android and SwiftUI for iOS.

Going forward, with Compose Multiplatform maturing, I expect more and more new apps will share almost 100% of their code. For example, IceRock Development reached this level in one of their recent projects:

While it might seem like Compose Multiplatform makes the native UI option obsolete, that’s not the case at all. For example, when migrating native apps to KMP, being able to keep the existing UIs while refactoring the rest of the codebase is crucial for reducing risk. Another reason to use native UIs is when projects need to meet specific accessibility targets. Despite all their benefits, multiplatform UI frameworks often fall short in accessibility specifically.

So, by supporting both shared multiplatform and native UI frameworks, KMP can meet a much wider range of business needs and constraints.

Kotlin Multiplatform is Almost Native on Android

When it comes to tooling and developer experience, KMP feels very similar to native Android development. There are some small differences in how projects are organized, and some libraries need to be swapped for multiplatform analogs, but, overall, Android developers can switch to KMP with little effort. [Unfortunately, the iOS experience in KMP is still far from ideal due to less mature tooling, longer build times, etc., so a lot of infrastructure work is still required in this regard.]

The fact that KMP is almost native on Android is a big deal. First, it means that about half of the mobile developers in the world today can start using KMP and become productive very quickly. Second, for businesses, it means that even if KMP adoption doesn’t work out, the effort isn’t wasted. Instead, it becomes the foundation for their native Android app. That’s not the case with any other multiplatform framework I know of, where a failed attempt usually means throwing all the work away.

Gradual and Steady Evolution of Kotlin Multiplatform

Unlike many other new technologies, KMP’s growth and adoption weren’t driven by hype or big PR budgets. Instead, it matured slowly over the years, steadily improving its foundations and developer experience. For example, JetBrains launched KMP without a multiplatform UI framework for Android and iOS, at a time when Flutter and React Native were already well established. That was an almost absurdly bold move. It took years to close this gap, and Compose Multiplatform only reached a stable milestone on iOS in 2025.

Some developers may see this slow pace as a downside, especially if they tried KMP too early and got burned by it. But to me, it shows serious and thoughtful leadership, which again highlights the strategic importance of KMP for JetBrains. If you’re building the foundation for long-term success, then taking time to do it right and allowing space for mistakes and rework makes sense.

This steady progress also makes it easier to look ahead and predict where KMP will be in the next year or two, both in terms of its technical capabilities and community adoption.

AI Poses The Biggest Risk to Kotlin Multiplatform

I don’t want to give the impression that KMP is perfect, because it’s not. From immature iOS support, to the lack of third-party libraries in the ecosystem, to limited documentation and tutorials, there are plenty of challenges. Still, I feel confident that most of these issues will be solved in the next two to three years.

In my view, the biggest risk KMP faces today is limited support and coverage by LLMs.

Software development has changed in recent years. Today, using LLMs to generate working code is becoming the norm, and this trend will continue into the future. React Native has benefited the most from this AI revolution, as these tools are much better at working with web technologies, probably because there’s more training data available for them.

On the other hand, there’s been a sharp drop in community-generated content like StackOverflow posts, blogs, and video tutorials. This means that training data for newer technologies has already shrunk and will likely keep shrinking in the future.

While Kotlin Multiplatform isn’t brand new framework, its adoption still lags behind React Native or Flutter. You can see this clearly using tools like Google Trends.

This situation could lead to a positive feedback loop, where existing solutions, like React Native, keep attracting more and more developers, gaining better LLM support in turn, with the whole industry gradually converging on those options. As a result, new technologies might face a very high, possibly unsurmountable barrier to entry.

Since developers are less motivated to create content in the age of LLMs (I feel like a dinosaur writing this post myself), JetBrains and Google may need to step up their efforts. They should invest more in documentation, tutorials, and community-generated content. This would help ensure that future LLMs have plenty of high-quality, up-to-date training data to work with.

Conclusion

Long-time readers of this blog will remember that for years, I’ve been pouring cold water on the hype around Kotlin and Jetpack Compose. In 2021, in my post titled Kotlin vs Java in Android, Four Years Later, I wrote:

Finally, said all the above, it’s clear that Kotlin, Coroutines, Compose and, maybe, even Kotlin Multiplatform are the future of Android development. Therefore, whether I like them or not, I’ll be forced to learn them one day (or have already been forced). However, this doesn’t mean that I need to jump on every hype train the moment it arrives. Just like with Kotlin, there is no rush to adopt any of these technologies. And if you do decide to become an early adopter, then it’s totally fine. After all, we, developers, like playing with new ideas and learning new ways to work. That’s what makes our industry innovative. However, be honest with yourself and your employer about the motivations behind becoming early adopters and the most probably outcomes.

Today, I’m happy to say that JetBrains delivered on their vision and built the best multiplatform solution for mobile development. That’s why I no longer see KMP as a risky choice, but rather as a smart investment in the long-term success of your mobile projects. It still comes with some challenges and risks, but they’re much smaller than they were a few years ago. In addition, JetBrains has shown that they are committed to KMP for the long term and won’t be discouraged by tough challenges or short-term distractions.

All in all, in my opinion, Kotlin Multiplatform really is the future of Android development. And, probably, iOS too.

P.S. It looks like Apple has also started to worry about multiplatform taking over their developer ecosystem. They recently launched the Swift Android Workgroup. It feels like we’re about to witness the grand finale of the multiplatform wars in the next couple of years.