https://kotlinlang.org logo
j

Jishin Dev [JD]

11/08/2021, 4:17 PM
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?
• 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?
j

John O'Reilly

11/08/2021, 4:20 PM
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
1
m

mbonnin

11/08/2021, 4:20 PM
Ahah I was going to paste https://github.com/joreilly/PeopleInSpace 🙂
😁 1
💪 1
j

Jishin Dev [JD]

11/08/2021, 4:25 PM
@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. 😅
j

John O'Reilly

11/08/2021, 4:27 PM
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
hmm, might be worth taking look at https://moko.icerock.dev/
👍 1
m

mkrussel

11/08/2021, 4:29 PM
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
👍 2
j

Jishin Dev [JD]

11/08/2021, 4:42 PM
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.
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. 🤞
k

kpgalligan

11/08/2021, 6:06 PM
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.
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.
j

Jishin Dev [JD]

11/09/2021, 4:22 PM
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.
k

kpgalligan

11/09/2021, 6:34 PM
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.
💯 1
c

coolcat

11/10/2021, 8:30 AM
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
✔️ 1
4 Views