Martin Rajniak
09/13/2022, 7:22 AMIf the XCFramework is available locally and included in the package’s Git repository, you don’t need to create a compressed archive and can reference the XCFramework directly.As Philip suggested, it can be as easy as creating a repo with an XCFramework Bundle and providing a Package.swift file that your XCode project can use. You might already know this, but XCode then checks required version and fetches “Package” from appropriate commit in the repo based on the tag. Creating your own Package.swift file is really easy.
When you host the binaries on a server, create a ZIP archive with the XCFramework in its root directory and make it available publicly.I would say that plugin is more useful when you need to support this second case - providing your binaries from external server (in my case it was internal Artifactory). You need to do 2 additional steps for this case: zip XCFramework Bundle and provide a checksum in Package.swift file. So again, still pretty simple. But if you want to do it in your CI, this kind of automation comes handy 🙂 There are 2 issues I have with the plugin, though: • it does not support M1 (Arm64) targets, • it does not use official tasks for creating XCFrameworks, First one was a blocker for me, and as John mentions plugin is no longer maintained by the owner. Luckily, there are working forks that are even published in maven central. I tested this one that worked for me: https://github.com/luca992/multiplatform-swiftpackage. And you can learn more about the distribution in original PR: https://github.com/ge-org/multiplatform-swiftpackage/pull/41#issuecomment-1170081817.