Hi, I have a basic question. I’m trying to build a...

# multiplatform

[Jishin Dev [JD]]

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?

[Jishin Dev [JD]]

• Is there a way to include swift files within the iosMain somehow?
• Is there any other approach to achieve the same?
• Is this even supported or expected to be a valid use-case?

[John O'Reilly]

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

[mbonnin]

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

[Jishin Dev [JD]]

@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. 😅

[John O'Reilly]

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

[John O'Reilly]

hmm, might be worth taking look at https://moko.icerock.dev/

[mkrussel]

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

[Jishin Dev [JD]]

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.

[Jishin Dev [JD]]

thanks @mkrussel. this is definitely something I was hoping to do earlier, but the project structure was getting somewhat complicated, with multiple KMM libs and app modules, to be able to handle the gradle issues that came with it. Will keep this one as last resort. 🤞

[kpgalligan]

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.

[kpgalligan]

We are packaging some Swift in Kotlin frameworks, or at least experimenting with that, but I not expect the dev process in that context to be great. Having a separate framework is easier. For the client project I'm thinking of, we use SPM rather than cocoapods for packaging and distribution, which is an added complication, although there are certain things that seem easier with SPM as well, but it's less developed for Kotlin dev.

[Jishin Dev [JD]]

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.

[kpgalligan]

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.

[coolcat]

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