Hi, I have a basic question. I’m trying to build a KMM library module/sdk of sorts which needs to include a few basic UI screens for both android and iOS. I was able to get it working for android (as we can write Jetpack compose UI in the

androidMain

but how do I achieve this with SwiftUI for the iOS targets?

For the most part I believe people generally use KMM module for shared non-UI code....and then say SwiftUI code is managed within a separate XCode project etc that consumes it

Ahah I was going to paste https://github.com/joreilly/PeopleInSpace 🙂

@John O'Reilly Yes that makes perfect sense for a KMM app but can this same concept be used to build an sdk that contains UI? Just a little confused. 😅

ah, sorry....I missed that this was an sdk. I'm not sure tbh what the best approach would be in that case....don't think I've seen a KMM library that somehow includes both iOS and Android UI elements ....typically they just include some non-UI functionality

I would break the library up into the shared business parts and the UI library. Implement the UI library in Swift using XCode and have it consume the Kotlin native library. Then distribute both libraries to app developers

Thanks @John O'Reilly. Also, moko-widgets already seems like a possible solution - write UI in common code. I wasn’t able to get Jetpack Compose to work for my project setup, issue for which is still open here, because of which I was forced to use

xml

for android UI. Can replace with

moko-widgets

if it works.

We do SDK work with clients, and for SDK's that need a UI, we just have an Xcode framework project that depends on the KMP framework, and do the UI code in the "standard" Xcode Framework. App > SDKUIFramework > SDKKotlinFramework.

thanks @kpgalligan. I didn’t foresee this issue happening when we started the project. Thanks for the extra insights. Unlikely but, is there any public repos/samples where you’ve seen this being done that I can use as a reference? It does appear that packaging as a separate framework is the only viable option left, unless we get a mature enough multiplatform compose ui framework sooner than expected. I was thinking of trying out

moko-widgets

but just learnt from #moko that they’ve frozen any further dev on that repo.

I don't know of any public examples, which was part of the issue when we had to figure it out. If I think of anything I'll let you know. On moko, I give them a lot of credit for trying that out, but it's a huge thing to build and support. We started using compose to drive UIKit components on iOS as an experiment, but also stopped because it's pretty clear there is work ongoing for native compose, so it's only a matter of time.

This approach is also what you want, if you need your shared Kotlin code to call a non-UI framework, which for whatever reason can’t be imported via cinterop, e.g. a Swift-based framework