What is the best practice to publish objective c o...

# library-development

[Soren Roth]

What is the best practice to publish objective c or swift code within a KMP library? It is all internal code, but necessary to make the API work. I've got it in a cocoapod that is pulled in from the local filesystem, I am realizing it won't get packaged into my publication!

[mbonnin]

Create a separate publication? That adds a lib-c-sources.zip artifact?

[Soren Roth]

I have one publication, I'd like to package some glue code and a private framework into the artifact that is published.

[mbonnin]

If you want just one publication there's https://youtrack.jetbrains.com/issue/KT-58830

[mbonnin]

But I'd probably go the separate publication route

[Soren Roth]

How can a separate publication contain the swift or objective c? If it can include it, then my original artifact could include it. I am missing something in what you mean, can you please elaborate? thank you.

[mbonnin]

A publication is just files, they can contain anything

[Dmitry Khalanskiy [JB]]

What is the best practice to publish objective c or swift code within a KMP library? It is all internal code, but necessary to make the API work.

Could you share why this Objective-C/Swift code can't be rewritten in Kotlin? Is this an internal requirement of your project or a limitation of KMP?

[Matthew Feinberg]

Jumping on this thread because we have the same (or related?) issue right now! We are building a KMP library that depends on ANGLE for some functionality. On desktop platforms, we're using JNI with some glue code, and so far that's working fine (we figured out how to bundle it). However, on iOS, we can't figure out how to get the ANGLE static library packaged into the library framework so that an app can just use the library as a single dependency. Is there a standard way to do this that I'm just missing? (Basically, most of our code is written in Kotlin, but obviously re-implementing ANGLE entirely in Kotlin would be a massive undertaking... so we have that, and a little Swift/Objective-C/C glue code).

[Dmitry Khalanskiy [JB]]

There is a way to include native binaries with a KMP library, but it's in such an experimental state that it's not even properly documented. There are also plans to deprecate it https://youtrack.jetbrains.com/issue/KT-70211, but a better alternative was not implemented yet. It may be useful to leave comments with your use cases under that issue.

[Matthew Feinberg]

Thank you, that is very helpful! We are already referencing the library in our .def file but were missing the -include-binary argument. We will try it shortly.

Since this is due to be deprecated, is there a recommendation for a different approach? For example, should we build the native library as a separate artifact and reference it as a dependency from the KMP library? Will that work, and avoid apps that use our library from having to add both dependencies?

Ideally we really want users of our library to just add the single dependency in Gradle... But if there's a different way to do that than including a static library in the framework, that would be fine too.

[Matthew Feinberg]

I want to better understand why bundling static libs is discouraged and whether there's an alternative best practice — then I'll comment on the YouTrack issue with the use case if it's still relevant.

[Dmitry Khalanskiy [JB]]

I'm not sure why there are plans to deprecate it. I could ask the people in charge of Kotlin/Native to join this thread and explain their reasoning, but I think it's better to discuss this under in the comment section on YouTrack. The discussion is easier to find that way and less likely to be forgotten about when deprecation is considered.

[Matt Nelson]

https://github.com/touchlab/cklib

[Matt Nelson]

Example Usage: https://github.com/toxicity-io/sqlite-mc/blob/8511c9bebb2a89c456cb532dbf6c82b8ac088786/library/driver/build.gradle.kts#L131

[Matt Nelson]

If you're unable to include the static library and require that it be dynamically loaded, you need to create your own packaging and loading system, as well as figure out codesigning for apple targets. On iOS, this requires a framework to include because codesignatures must match that of the application. It can be delivered via gradle plugin if you wish.

E.g. https://github.com/05nelsonm/kmp-tor-resource/tree/master/library/resource-frameworks-gradle-plugin