Hi. there, in the <KMM docs> I can see that it say...

# multiplatform

[Joseph Roffey]

Hi. there, in the KMM docs I can see that it says:

Kotlin supports interoperability with Objective-C dependencies and Swift dependencies if their APIs are exported to Objective-C with the @objc attribute. Pure Swift dependencies are not yet supported.

I am hitting an issue trying to depend on a pod (SPPermissions) which I think might be because it is a “Pure Swift” dependency, although I’m not sure I can be certain about that, as this is the first pod I’ve tried to depend on…

As it says “Pure Swift dependencies are not yet supported” I was wondering if there is a link to monitor the planned implementation of supporting Pure Swift dependencies, and was wondering if there is a suggested workaround e.g. forking the relevant project and adding in the @objc exports required or else releasing a delegate project that simply imports the Swift dependency and exposes an Objective C api?

I’m by no means an expert on KMM so am worried I might be trying to do something that just can’t work with the current methodology, but I’d be keen to hear any advice anyone might have.

[mkrussel]

I've run into issues where if the swift framework exports anything from other modules, then I was unable to import it. Examples would be a function that takes a CGPoint. An Objective-C framework did not have that problem. Also ran into the same issues with the framework I wanted not using @objc because the majority of the code does not support it.

I went with the route of creating my own delegate project to expose what I needed to Objective-C, but it did involve having to wrap a lot of their structs into classes that could be exposed to Objective-C. Did have the benefit of only needing to expose the features I was using.

Depending on the library, a fork might be easier.

[Joseph Roffey]

Is your delegate project publicly visible so that I might have a look as to how you went about it in case there’s anything I could learn? No worries if not, thank you so much for the advice 🙏

[mkrussel]

It is not

[Joseph Roffey]

No worries thanks

[mkrussel]

I'm still working on it and so far only tested that things compile, but haven't finished enough to run yet.

Mostly tedious work of wrapping the struct and creating properties that forward everything to the struct.

[mkrussel]

I also exposed enum fields as Any then casted back to enum inside wrappers.

[Sam]

That library looks to be mostly ui related. Are you doing your ui in Kotlin as well? If not, and you’re ui code is in Swift, just put it in your app’s pod file rather than your framework’s pod file and use it from Swift. Personally I tend not to pull in any pods that have ui elements because they rarely match the app’s style that I’m already using. Also, in this case, asking for permissions and showing a list of them that need to be granted is a trivial amount of work that I wouldn’t want to introduce a dependency for.

[mkrussel]

I would probably agree about a permission library. If the common code needs to ask for it, I would create an interface for dealing with it, and inject that interface from the app. Then let the app deal with any UI needs for it.

[Joseph Roffey]

Thanks, I guess you’re probably right, I’ve had about 3 discussions already this week on whether it should be the purview of the KMM SDK or of all the apps that choose to use it. It feels sort of separate as the permission requests interrupt the rest of the UI but I think you’re both probably right...

[Sam]

The issue would be clearer if both platforms had the same permission model but they don’t. Sometimes Android requires a permission that iOS does not, sometimes it is iOS requiring a permission Android doesn’t. It would simplify your common code to just assume that the calling app has already arranged the permissions and make sure your error handling is robust.

[Joseph Roffey]

Thanks Sam