I’d would like to share another interesting finding for KMP. I started to dig into

Kotlin/React

, and I realized it’s really simple to make components, using

Kotlin-DSL

HTML elements. I have started to create Web component functions that have exactly the same API of JetpackCompose composables (e.g. NavigationBar, NavigationItem). So, I can now build a webApp with Jetpack composables, still using Kotlin! It’s really awesome. I believe someone (maybe JetBrains itself) will eventually extend JetpackCompose to web, because it makes a lot of sense. I can see in the near future we will just have 2 UI frameworks:

JetpackCompose

(for Android, Desktop and Web) and

SwiftUI

(for iPhone, iPad, Mac, etc.). I don’t even think React will last, because JetBrains already gained so much expertise that they can easily write their own efficient web reactive framework in Kotlin/JS, based on

StateFlow

using JetpackCompose components for the UI, bypassing React completely. So, my suggestion for everyone is to really start learning JetpackCompose and SwiftUI, because this is going to be the base for any app of the future. All the rest will become legacy.

I hope Jetpack Compose works on iOS some day like Flutter works now.

I think JetpackCompose could be easily do what Flutter does, but having a native UI on iOS will still be preferable, as the Apple users really appreciate that.

Nobody stop you to create the same SwiftUI components with Compose

The structure of the two frameworks are really similar. But SwiftUI is really great as it’s rendering the same components in different ways depending if you are on iPhone, iPad, Mac, Watch. I don’t think JetpackCompose will ever be able to match that kind of “nativity”-

It looks like they are separate widgets. So, if you build an Android and an iOS app, you would need to use two different UI widgets. At that point, I think it would be much preferable to use Kotlin MultiPlatform with JetpackCompose on Android and SwiftUI on iOS. It would definitely be the best future-proof choice.

To be fair Flutter approach is to have an app that looks mostly the same on both platforms, with some adaptations. In this case it make sense to write the UI just once

True, but our iOS clients hate when the app dose not follow the HIG for that release of the OS. They want iOS 11, 12, 13 ,14 ect .. to follow the evolution ... They want the iOS app to look like iOS and Android to look like Android. We understand and so we need to stay with Compose and SwiftUI. Just trying to keep the clients happy ...