Thread
#multiplatform
    Jishin Dev [JD]

    Jishin Dev [JD]

    10 months ago
    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?
    John O'Reilly

    John O'Reilly

    10 months ago
    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

    mbonnin

    10 months ago
    Jishin Dev [JD]

    Jishin Dev [JD]

    10 months ago
    @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

    John O'Reilly

    10 months ago
    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/
    m

    mkrussel

    10 months ago
    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]

    Jishin Dev [JD]

    10 months ago
    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. 🤞
    kpgalligan

    kpgalligan

    10 months ago
    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.
    Jishin Dev [JD]

    Jishin Dev [JD]

    10 months ago
    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

    kpgalligan

    10 months ago
    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

    coolcat

    10 months ago
    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