Flutter and Kotlin Multiplatform

These two platforms are often known as competitors but the reality is opposite. The ambitions of these platforms don’t overlap and they can actually help each other. For something like that to happen, Kotlin and Dart need to be interoperable. As long as this is not happening, Flutter and Kotlin can also be called competitors.

Let’s discuss this relationship in detail which is more likely to shape the future of Android development!


It is a front end library for iOS and Android development. Flutter library offers a single API to define views for both platforms at once. Not only that, it also provides a common API for services like database or network. Its API is created for Dart language compiled to C/C++ code with NDK on Android Studio and LLVM on iOS.

Kotlin Multiplatform

Kotlin can be compiled with JVM bytecode, JavaScript or native LLVM code. In this manner, we can use it to develop Android and iOS apps as well as web and desktop apps. What’s more? Backend development with Java frameworks like Spring is also possible.

You can also have some shared parts between these platforms. These shared parts are known as common modules and are used in platform specific implementations.

So, Are They Competitors?

As mentioned earlier, aim of Kotlin and Flutter does not overlap each other. Both the platforms are making attempts to extract common parts above the platform but Kotlin Multiplatform is interested in logic extraction whereas Flutter is more into view definitions extraction.

They concentrate on opposite factors and might highly benefit cross platform development community from working together.

How are they beneficial to each other?

A major problem with Flutter is that it is hard to migrate from Android to Flutter. Making changes in both the language and frontend framework is almost impossible for well developed applications and rewriting everything will become too expensive.

However, the situation with Kotlin Multiplatform is different - most of the Android projects are built in Java Kotlin anyway. Whenever a good architecture such as MVP or MVVM is there, migrating to Kotlin Multiplatform becomes really cheap as everything else is already implemented and only needs to be moved and used again in iOS development.

Another problem with Flutter is history. It portrays that average lifetime of frontend libraries is short and businesses don’t like implementing the applications again because they chose a language and framework that couldn’t stand the test of time. To sum up, the biggest problems of Flutter apps are:

Difficult to migrate to

Difficult to predict the long term future of this solution

Flutter and Kotlin Multiplatform

In such a situation Kotlin Multiplatform can come to your help! If Kotlin becomes interoperable with Dart then migration to Flutter will look like this:

Introduction of a good architecture such as Clean, MVP or MVVM if it is yet not implemented

Extract logic and services which are supported in Kotlin common modules

Reimplement views in Flutter and use Kotlin common module for logic

If all this is carried out correctly, then the integral parts of your application will be in the common module and migration will not be tedious. To some extent it will be able to solve both the problems of Flutter:

Migration to Flutter will become much easier as only views need to be reimplemented and not logic

If Flutter loses its popularity to some other front-end framework, migration will be relatively cheaper as we can assume that the other language being used will be interoperable with Kotlin

The list of languages that are interoperable with Kotlin is pretty impressive and it is still growing:

Java, Scala, Clojure, Groovy

TypeScript, JavaScript

Swift, C++, C

As a result we can achieve the best of both worlds:

We can write our logic in Kotlin. Kotlin is great for that, also supports coroutines and can be reused almost everywhere including the backend

We can write the views in Flutter, once for all platforms, using great features of Flutter like Hot Reload

Now, that we have explained in detail how both the platforms can work together, you might be wondering where is the problem? Let’s discuss the problematic area as well!

The problem lies in the fact that Flutter app development requires Dart language. A discussion has been going around to use Kotlin instead of Dart. Kotlin is now the primary language for native Android development, so reusing the native platform code and moving from Android to Flutter will become much easier. Kotlin language is also more developed and featured.

This discussion is being taken into consideration as Kotlin allows DSL creation which will give Flutter a shorter and nicer syntax for view definition.

Most of the Android community will be happy to use Kotlin instead of Dart on Flutter, but it won’t be a great news for Flutter developers who have already invested much of their time in learning Dart. Moreover, Google prefers Dart as its their language and they have complete control over it.

No wonder why Kotlin and Flutter developers’ communities are always at loggerheads!

The only solution to this conflict between Dart and Kotlin is a proper interoperability between them. The interoperability will allow you to write whatever Flutter part we want in Kotlin and whatever part we want in Dart. You can also have a better code reuse from Android SDK projects.

What is the Ultimate Outcome of this Discussion?

It is not yet confirmed that interoperability is possible. But what is sure is that to achieve complete interoperability, cooperation between the Flutter and Kotlin team is absolutely necessary.

If this interoperability is practically made possible then Flutter will benefit from it as Kotlin Multiplatform will make it easier and safer to migrate to Flutter. Developers love the Kotlin framework and lack of it has blocked many of them. On the other hand, Kotlin will also be benefitted as Flutter might turn out to be huge and in that case Kotlin will also grow with it.

blog CMO - kodytechnolab

Sagar Bagsariya

Principal Mobile App Developer