Build kable xcframework for iOS?

[marcprux]

Is there some way to create an xcframework for adding to an iOS project?

[twyatt]

Your best bet is to have your own library that pulls in Kable and you build an XCFramework from your library.
Being that you can only have 1 KMP library in an iOS project, it doesn't make a lot of sense to create an XCFramework from Kable.
It makes more sense to have your own library that you pull in your needed dependencies and you create an XCFramework from.

[marcprux]

Thanks for the response. My understanding is that the inability to include multiple KMP xcframeworks had been resolved, as mentioned in KT-42254:

Kotlin/Native compiler can produce Swift/Obj-C frameworks from Kotlin code. Multiple frameworks can be used in the single application, they are usually properly isolated from each other.

I did a quick experiment, and I am able to build an iOS app with multiple KMP xcframeworks. There are warts with the process (e.g., all the frameworks will have their own KotlinBase, KotlinNumber, KotlinMutableSet, etc., which makes it impossible to cast base types between one framework and the other), but it does seem to be possible.

Our use case is that we (the Skip project) would like to have a bluetooth framework that can be included independently from the iOS and Kotlin sides of the app without needing to make the user manually build and include the framework. For the time being, we will follow your advice and make our own cover library and publish the xcframework as a GitHub release, but it may be something you want to consider adding in the future for your own users.

A more general benefit is that iOS users who don't use KMP at all would still be able to use the framework by adding it as a SwiftPM binary dependency.

[twyatt]

My understanding is that the inability to include multiple KMP xcframeworks had been resolved

Very nice, I was not aware of that, and thanks for providing details of what caveats still exist with the process (despite being possible).

I suspect that it is very rare that consumers have the need for this (but I could be wrong). I'd prefer not to have to maintain another build process unless the need is warranted. So, I created #710 from this discussion, it will help us track demand for the feature (i.e. if it gets enough 👍 reactions, then we'll know enough consumers want this feature that it justifies the maintenance burden).