Hi everyone! The Swift packages finally got some l...

# multiplatform

[Aleksey Zamulla]

Hi everyone! The Swift packages finally got some love in our docs: we published an article on SPM export. It should be useful when trying to make a Swift package out of a module (or modules) of your Kotlin Multiplatform project.

If the topic is at all relevant for you, check the doc out and leave your impressions in the comments. Is something missing, or unclear? Is the page too specific, or too broad? What do you think should be covered next? Let us know.

In other Apple news, we integrated links to Kotlin-Swift interopedia in our Interoperability with Swift/Objective-C page.

[Pablichjenkov]

Great to see that in the docs, it is an existing capability that is not so popular.
Now a quick question, on other threads I have read this Xcframework cannot contain assets or resources.
Is that correct? - or perhaps, it can have resources but is just not compatible with the compose resource plugin, yet?

[russhwolf]

It's really cool to see more official docs on this! I have a couple thoughts:

1. I think it's hard to understand the tradeoffs between the different options in the Swift Package Distribution section without having actual example projects to look at. But I also know first-hand how difficult it can be to create and maintain such examples.
2. One complication the article doesn't get into is authentication. When publishing a private package, correctly authenticating through package.swift or xcode can be confusing if you haven't done it before.

[Aleksey Zamulla]

this Xcframework cannot contain assets or resources

Yes, that is still true, the framework itself does not contain resources. Right now only local integration works with resources, and we don't have it documented well, unfortunately, especially concerning resource usage. It's on the radar.

You can reproduce the way the Compose Multiplatform plugin does bundling, but that's tinkering with build phases in Xcode.

[Aleksey Zamulla]

@russhwolf thanks for the comment! Yeah, I understand that imagining this is hard. Maybe we'll find a compromise and come up with a visual aid of some kind.

One complication the article doesn't get into is authentication

That's a good one, I'll bring it up with the team.

[Thomas Flad]

Thanks for the documentation update! It would be nice to see how a setup in a monorepo setup could look like (without distribution of the SPM package)

[Pablichjenkov]

Based on Thomas suggestion, if there is a way to consume the local KMP project using SPM and with continuos compilation.
What I mean. Right now is possible to consume the library from Xcode indicating the directory of the KMP xcframework with binaryTarget option in Package.swift.
However, I noticed changes you do in Android Studio don't reflect automatically like it does with the current direct Xcode integration.
Would be nice to have the changes reflected without having to manually recompile.

[Aleksey Zamulla]

monorepo setup

If I understand you correctly, that's what we want to touch on next: the projects that our wizard generates are essentially that.

By the way, if those who are interested in SPM support are welcome to add their use cases here: https://youtrack.jetbrains.com/issue/KT-53877

[Thomas Flad]

@Aleksey Zamulla Thanks for your response. It goes into the direction of what @Pablichjenkov mentioned. Imagine you have a very modularized iOS project which is using exclusively SPM. What you want in this scenario would be to have an independent SPM module which includes the generated shared XCFramework. Other SPM modules can then depend on it.

The generated project from the wizard is embedding the XCFramework in the root iOS project. This approach will not work with a modularized architecture based on SPM, since you cannot depend the modules on this XCFramework.

So, you could use the binaryTarget option and let the SPM module use the generated XCFramework in the corresponding build path of the shared library. But Xcode will not notice changes and you have to recompile the whole project. It would be nice when an official SPM Gradle Plugin would be able to generate the SPM module for the current configuration (debug vs. release) and target type (iOS, watchOS, etc.) and handles the build efficiently.

Currently, we have a custom Gradle Plugin which is using the Xcode environment variables to determine build and target and builds the corresponding XCFramework (based on the
XCFrameworkTask). Then it copies it to the corresponding SPM path and removes the relevant cache in the DerivedData folder. This task is executed as a Pre-action of the Scheme. We cannot use a Build Phase since Xcode will run Build Phases after resolving the SPM dependencies.

[Pablichjenkov]

That's right, the generated project would have to change a little bit of the iOSApp structure. The pattern I have seen is one project iOSApp module that depends on a iOSAppPackage module. The last one contains all Package.swift stuff.