Can’t archive App that uses a swift package with an xcframework

Hello,

We have a situation where:
  • we have a library A distributed as an xcframework.

  • this library A is used in a swift package B that includes it as a binary target.

  • our final iOS App uses our swift package B with swift package manager.

We first had issues with code signing and solved it by adding a build phase that code sign the framework A when building the App. Now everything is fine when running in debug but when trying to archive the App, We have a compilation error saying Xcode doesn’t find the framework A.. we try a lots of different setup but didn’t find any solution to fix this compilation error.

Any idea on how we could solve this issue?

Thanks!

Replies

SwiftGit2 has the same problem.
Thanks @kareman for the reply, I submitted a feedback to Apple with a sample project reproducing the issue. Did you send a bug report on your side too?
For more information here is a link to a sample project demonstrating the issue:
https://github.com/zocario/swiftpm_archive_binary_target
Did you find the solution? I am facing same problem
Hello @Ams1 we still have the problem and no answer from Apple on feedback assistant. I think you should also open a ticket maybe you'll have more luck? You can reference my opened ticket FB8781532 (at the moment opened with no similar reports).
Same problem!

Xcode 12.2
macOS Catalina 10.15.7
Same issue with macOS projects
Same problem!
Xcode 12.2
macOS Big Sur 11.0.1
Same situation here, got around the problem by adding library A as a new product of the package. e.g.
Code Block swift
let package = Package(
name: "PackageB",
products: [
.library(
name: "PackageB",
targets: ["PackageB"]),
.library(
name: "LibraryA",
targets: ["LibraryA"])
],
targets: [
.binaryTarget(
name: "LibraryA",
url: "https://url.to/LibraryA.xcframework.zip",
checksum: "checksum"),
.target(
name: "PackageB",
dependencies: [
"LibraryA"
])
])


Then add both libraries to App's Frameworks, Libraries, and Embedded Content.

Still would like a better solution.
bug ticket:
https://bugs.swift.org/browse/SR-13803

reproduce project:
https://github.com/canius/ArchiveErrorDemo
We found a solution and maybe it was a wrong pattern on our side at the beginning. To solve the solution we just added SPM support to our XCFramework by adding on its repository the Package.swift and expose the library that uses the XCFramework binary target like this:

Code Block
let package = Package(
name: "Module",
platforms: [
.iOS(.v11)
],
products: [
.library(name: "Module", targets: ["Module"])
],
targets: [
.binaryTarget(name: "Module", path: "Module.xcframework")
]
)


Hope this can help :)
  • A library i'm using is facing the same issue. Someone made a fork and did as you suggested here. It was working fine, but now as of Xcode 12.5.1, seems the same issue is affecting it this way too.

    Has the same happened to you?

Add a Comment
@zocario
It's fine. But I got a new error, the XCFramework is embedded in the app as a dynamic library.
Soooo, I can't upload app to App Store or export app to local. (error: exportArchive: Found an unexpected Mach-O header code: 0x72613c21)
@zocario
I am facing the same problem, Xcode 12.4. Did you manage to solve this issue or find a sufficient workaround?

Swift Sodium is affected by this too: https://github.com/jedisct1/swift-sodium . Simply including it in your project makes it impossible to archive.

There was a workaround in someone else's fork, but it seems like this is now being affected by the same issue when using Xcode 12.5.1. This is a huge critical show stopper for us. Really need Apple to push this one along

I'm still collecting info, but locally this seems to work with 12.5.1 but not 12.4 (I have both installed here). We're using Github actions for CI, which (currently) only supports 12.4. There's a private preview of 12.5 and we're attempting to get into it, but I think we're going to run into other CI issues as we're publishing an SDK that other groups use. We were using Carthage previously, which was a nightmare, and the move to SPM seemed really easy, but this is a huge blocker now. Hoping to find a workaround, but reading above, that seems unlikely :)