So i'm trying build a library that uses ktor. It'...

# multiplatform

[mattinger]

So i'm trying build a library that uses ktor. It's pure kotlin and depends only the ktor-client-common and ktor-client-mock. I have no platform specific code, i'm just building on top of these two libraries. I'm struggling a bit about how to publish (in particular on the iOS side). Obviously i can use the maven-publish plugin to publish to artifactory or nexus. But it's the iOS side i'm concerned with. I'm wondering if i have to publish it as a cocoapod, or is there some better way to publish it given that there's no actual platform specific code?

[Jeff Lockhart]

What is your goal for the library? Is it meant to be consumed by KMP apps using Kotlin? Or is it meant to be consumed by native client apps directly, e.g. in Swift or Objective-C for iOS?

Depending on what your goal is, you can either publish KMP artifacts to Maven Central, or you can additionally build an iOS framework and publish via Cocoapods, or SPM, etc.

[mattinger]

@Jeff Lockhart I'm not sure which of these patterns it will fall into yet (perhaps both). I also have the issue of it being very kotlin-y in terms of the dsl i've built, and i don't know how swift code is going to interact with it yet.

From what i understand there's a way to pull in a .klib file into iOS code, but it's kind of limited in that you have to have a single module that pulls in all of them and produces an xcframework which the iOS code can use.

I just wish the documentation was more expansive on how to deal with iOS. There are areas where it tends to not even mention it.

[mattinger]

And by "kotlin-y" i mean it has varargs and default parameter values and such, which generally do not play well in my experience with swift. At least when that particular code is object-c based (which is what the binary from kmm seems to produce), since objective-c doesn't really support those features.

[mattinger]

Or at the very least the generated binary code doesn't know how to deal with it. I previously tried something with a bunch of function params with default argument values, and when brought into iOS had to specify the value for every parameter.

[Alejandro Moya]

You seem a little confused on a couple of things
1. It doesn't matter the platform specific code you have on the library, you will have an output for each platform, on Android an Android library, and on iOS an objective c compiled library
2. For iOS it's explained in the docs that you would create a pod, you can publish that on your local or a git repo.
3. As I mentioned, the iOS output is an objective c binary, you can consume that from Swift as you would with any other public library available.
4. You could create platform specific functions that call the kotlin code in a more friendly way if you need

[Alejandro Moya]

Just in case, you can use varargs in objective c

[Alejandro Moya]

https://stackoverflow.com/a/4804807/749427

[Alejandro Moya]

https://kotlinlang.org/docs/native-objc-interop.html

[mattinger]

It has var args, but default parameter values seems like a no go. It's just not a language feature of objective C.

[Alejandro Moya]

Check the interop, it's a good document to understand the nuances

[mattinger]

Also, general kotlin rules suggest:
• All required parameters come first (excluding trailing lambda functions)
• Then all optional parameters
• Trailing lambdas come last.

[mattinger]

So i have a function with a vararg, then an optional parameter, then a trailing lambda.

[mattinger]

Think okhttp-mock but in kmm

rule(get, path startsWith "/path", times = 1) { respond(....) }

[Alejandro Moya]

Check the library output for 2 methods with similar signature

[Alejandro Moya]

I didn't check that but the obvious solution for default values would be to create method signatures for the required params and another including the optionals

[Alejandro Moya]

I mean the ones with default values

[Jeff Lockhart]

It sounds like at this point, you shouldn't worry about publishing an iOS framework. The library can be consumed in Kotlin in another KMP app that will handle how it is integrated into an iOS app itself, publishing its own iOS-friendly API.

If you determine at some point that you do in fact want to support using directly in an iOS client app, then you should think about the UX of consuming your API this way and apply some of the tips mentioned above, e.g. avoid default args by using function overloads, possibly wrapping APIs in platform-specific code to iron out unfriendly Kotlin-specific details, etc.

[mattinger]

fair enough