The iOS / tvOS project I am working on could always be successfully archived on our continuous integration / delivery servers running Xcode 12.x, both for internal nightly / beta distribution as well as for TestFlight and App Store Connect. These servers have run all versions of Xcode 12.x and now run 12.5. After our servers were updated to Xcode 13 RC, though, archiving of our application started to fail almost all the time.
By looking at the compilation logs we discovered that this archiving problem occurs when compiling one of our SPM source packages A, which itself uses a binary SPM package B as transitive dependency. The line on which compilation fails is a line in the source code of A where the B.framework
is imported, with the error message "Module 'B' not found", indicating that Xcode failed to locate B.framework
. I first suspected B.XCFramework
might not be available from the local SPM cache for some reason but after verification everything looked normal.
Investigations
To investigate this issue I started from a simple project (Xcode iOS app template), just adding A as SPM dependency (and thus transitively B). To my surprise this simple project could successfully be archived, and reliably. I then started adding other random SPM dependencies from GitHub to this simple project until I found that, when a sufficiently large number of dependencies have been added (~6 additional packages in my case), archiving starts to fail.
The difference can be seen in the compilation logs. When everything works fine (Xcode 12.5 or small number of SPM dependencies), the ProcessXCFramework
operation is performed early in the compilation cycle for each involved SPM binary package, making the binaries available to compile packages depending on them. This is what ensures that B.framework
is available when the A package is compiled. When too many SPM dependencies are added to the project, though, the ProcessXCFramework
step does not appear in the log anymore for some obscure reason, which is why compilation of the A package fails.
Remarks
- When using Build & run the problem does not seem to happen (this is why we discovered it on our CI servers first, though archiving on a development Mac suffers from the same issues).
- Similar issues have been reported on the Swift forums (e.g. Use xcodebuild swift package with binaryTarget logic flaw) and might be related.
Workarounds
Enabling Manual order instead of Dependency order in the application scheme build settings fixes the issue. This setting is not recommended, though (a warning sign is displayed) and might not be an option for some projects.
Feedback
This issue was reported to Apple as FB9639952.
Summary
This text will be hidden