Flutter is purely a UI toolkit. It takes a rectangle from the OS and draws everything inside, like a game would. It just happens to copy Android/Material design and iOS design. The point is to to provide a reactive UI system. Focus is converting objects to fast 2D drawing.

Kotlin multi platform as described here has no UI system, it’s a way of compiling Kotlin to binaries that are easily linked to both Android and iOS apps, with some bridging back and forth conversions into the native systems in each case. You’ll still need two separate code bases to call the common binary and handle UI.

From another comment below it seems Kotlin Multilpatform is for multi-platform libraries, not UI!

Definitely possible. You can refactor your Android app to be split up into essentially two "modules", one with your business logic and then the UI/native platform specific libraries.

Once you have that setup you can then add a different platform "web/iOS". The base module would have setup certain contracts that new "platforms" would have to implement.

I took a fairly deep dive looking at Flutter last spring and I was impressed. My work involves semantic web and deep learning, I am not a UI developer professionally, but I enjoy small UI projects.

Try spending one or two evenings with Flutter writing a simple app and build it for two or three platforms to see what the few issues are.

Looking at the current state of things though, they would probably end up writing a bunch of native code anyway because they'll be missing out on a lot of native functionality that their app currently uses, but isn't really fully accessible through best-effort flutter plugins.

You already have at least three paths with Java, Gluon Mobile, Codename One and RoboVM.

Naturally it isn't on Google's and JetBrains interest to talk about them.

My understanding is that this isn't really the case. Flutter is focused on the user interface portions of an app and Kotlin MP is focused on non-UX portions. Flutter does have some docs on incrementally moving apps at https://flutter.dev/docs/development/add-to-app. This seems early, but with Tim Sneath (experienced with the issues involving moving Microsoft devs between UI frameworks and interop), I suspect that this area will get fleshed out.

What you need to do is analyze your situation and make a decision on whether you have significant non-UX code which will be a bear to maintain long-term. Most people do not, so maintaining a platform-agnostic layer is unrealistic.

To help with this, let's look at an older example: Microsoft. In https://channel9.msdn.com/Events/CPP/C-PP-Con-2014/024-Micro... they describe how they are using C/C++ as the basis for their Office applications. Why? They have a load of legacy code that needs to be reused and they needed the exact behavior on all platforms. This code runs on the client and can't be moved off to the server-side which would be the preference when feasible.

Since iOS and Android can consume C/C++ code it makes sense to maintain as much of the application in C/C++ as possible for sharing while creating native apps which are as thin as reasonable. They can do iOS and Android specific things where it brings value, but centrally, they can decide if it should be something available across all platforms, or even architect it partly in C/C++, and partly in the native API for the mobile platform. This allows them to bring it quickly from Android to iOS in a future release.

Microsoft can easily afford to do everything described above. If we look at Netflix they are in a similar position, but don't have as much legacy C/C++ code. Kotlin MP feels like a nice alternative given Netflix's situation.

Do you feel like you are in a similar situation? Few developers are in this situation, but it's attractive to architecture astronauts. While somewhat unpleasant, duplicating functionality in native iOS and Android code bases might be the right thing for your apps now. If not, there are in-between options such as moving to Flutter for all your UI code and Dart becomes your main client language. You have to be able to live with any compromises (I'm more familiar with Xamarin which is an aging, but similar trade-off.) That seems like one of the better balances today with good momentum behind the platform and strong implementation.