Does anyone know: is it possible to write iOS UIs using KMM + Compose/Multiplatform? Or is it necessary to write Swift code for iOS UIs? Thanks.

It's possible with unanounced experimental canvas api being worked on.

+ I've just found this channel, thanks 😉 : #compose-ios

Compose for iOS is still not quite ready for production, but it’s making a lot of progress. I’m hoping it will be ready in the next several months.

There are also a few examples that you could try: https://github.com/JetBrains/compose-jb/tree/master/experimental/examples/chat-mpp https://github.com/JetBrains/compose-jb/tree/master/experimental/examples/falling-balls-mpp and one from me https://github.com/mipastgt/JavaForumStuttgartTalk2022/tree/main/PolySpiralMpp

It's not necessary to write any Swift code for iOS UIs, you can use UIKit in Kotlin.

Would not recommend. UIKit is so different from Android's views that it gets hard to deal with both. Compose/SwiftUI are a much better pair.

UIKit isn't any harder to use than Android Views. It's different but still closer to each other than any of them compared to a web framework. Compose and SwiftUI are obviously much closer to each other as they're basically copies of React. But I prefer having to use 2 different UI frameworks than 2 different languages. My brain can't handle switching language multiple times a day, Kotlin and Swift are too close.

That’s a good way to put it. I generally prefer SwiftUI, because you don’t need to write ‘real Swift’ (no logic) as opposed to switching between Android view and UIKit. I migrated a complex legacy Android/iOS project pair to one KMM project lately, so we used UIKit so we could just translate, and the differences between Android views and UIKit are the biggest slowdown when I work on that.

Yeah I see what you mean. I completely agree that when using Android Views and UIKit you make your UI twice. You don't really gain anything. When using Compose/SwiftUI you reuse mostly the same ideas. It's more about translating. In my case I only have an iOS app. It relies on dozens of KMP libraries (algorithms, utils, API clients, etc.) so I just decided to stop using anything but Kotlin and made the app itself in Kotlin. It completely erased any kind of interop problem. No converting between Kotlin and Swift types, coroutines everywhere, etc. All the good stuff. I made my own microframework that wraps UIKit, at least the painful parts (defining constraints is pretty cool when you make a little DSL). It's fun and that's great

That makes sense. I’d probably do the same in that case since you don’t have to worry about cross-platform compatibility.

The original question was “to write iOS UIs using KMM + Compose/Multiplatform”. The question was not whether to use Swift or UIKit directly. According to the examples, the iOS Compose (Canvas) rendering approach seems to be somehow based on UIKit though. At least the target is called “uikitMain”.

It is built using a SkikoUIView, which is a part of the Jetbrains Skiko library. This library allows rendering to a UIView in a way that is compatible with Skiko. As such, Compose is just an abstraction for rendering onto a single UIView.

I answered to "is it necessary to write Swift code for iOS UIs?", that's it.

There were some previous projects that I would argue better match the title ‘UIKit’ for Compose. These projects would use the Compose tree to layout and render actual UIKit views, meaning each composable roughly correlated with a UIKit view, similar to how Compose for Web currently works to my understanding. Compose UI, however, just uses the platform view system as a single canvas.

Isn't the current plan to do just that everywhere but on Android? I know it's the plan for iOS and WASM, and maybe for Web

I think the current plan is to use the single canvas method, same as Android. I could be wrong, but that’s the direction the experimental new Compose for Web is going and how iOS/macOS currently are going.

Thanks for the detailed answers 🙂