Catalyst app with framework won't codesign

You should confirm that the symlinks in your framework are intact. I’ve seen weird problems like caused by folks who copy their framework in a way that doesn’t preserve symlinks (for example, using cp rather than cp -R) and thath causes havoc for a macOS framework.

adding "--deep" to the signing flags,

Do not use --deep. See --deep Considered Harmful for an explanation as to why. This is especially true when using Xcode, because Xcode already takes care of signing from the inside out for you.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

I’m definitely in the same boat as well

Think I'm closer to a solution here. I had to convert 8 different libraries we use from .a files into xcframeworks last Summer to support all the many archs. It is my theory that these unsigned xcframeworks are causing the problem, and available literature on xcframework is.... limited.

So one issue is that the codesign tool and the various Xcode logs do not identify any issue there. Instead, they say "MyKit.framework" isn't signed rather than "libmystuff.xcframework" inside "MyKit.framework" isn't signed. Switching the xcframeworks to "Embed and Sign" elicits the hoped for error that identifies the specific xcframework that it wants to sign but for some inexplicable reason does not sign.

Code Block 
../Build/Intermediates.noindex/ArchiveIntermediates/MyApp/InstallationBuildProductsLocation/Applications/MyApp.app/Contents/Frameworks/MyKit.framework/Versions/A: code object is not signed at all
In subcomponent: ../Build/Intermediates.noindex/ArchiveIntermediates/MyApp/InstallationBuildProductsLocation/Applications/MyApp.app/Contents/Frameworks/MyKit.framework/Versions/A/Frameworks/libmystuff.a

However, I would have thought --deep would at least have glossed over that problem and I did try setting that to no avail earlier. As to how I get these frameworks signed in a static way (we don't rebuild these regularly, they are just part of our repository). I guess I need to go find a command line to sign them somehow before adding them to the project? Something doesn't seem right here. Seems like codesign needs a flag to say "yes, I know this object is not signed, so sign it".

Having this issue as well, we are also using our own shared frameworks. Same branch signed on Xcode 11 is okay though?

I was able to resolve my issue by flattening numerous dynamic libraries down to 2.

@eskimo The MyKit framework is intact, is not copied, and is created by the Xcode build. The libmystuff XCFramework is also intact and does not contain any symlinks. It does contain static libraries built using the command line (non Xcode-project based libraries) for the various platforms and architectures and is used internally by the MyKit framework. It has been assembled using the Apple provided tools, starting with lipo to create the fat archives, then xcodebuild -create-xcframework to create the XCFramework itself. This is the contents of the libmystuff.xcframework:

iOS-i386_x86_64-simulator/libmystuff.a
iOS-arm64_armv7_armv7s/libmystuff.a
macos-arm64_x86_64/libmystuff.a
iOS-arm64_x86_64-maccatalyst/libmystuff.a
Info.plist

The XCFramework code appears to be correctly linked inside the MyKit.framework when MyApp is built (the symbols appear there and we can run the resulting app). We are not embedding the static library in either the MyApp project or the MyKit framework. This is the contents of the MyKit.framework as seen in the archive:

MyKit -> Versions/A/MyKit
Resources/ -> Versions/A/Resources/
Versions/
Versions/A/
Versions/A/_CodeSignature/
Versions/A/_CodeSignature/CodeResources
Versions/A/MyKit
Versions/A/Resources/
Versions/A/Resources/<non-code-resources>...
Versions/Current -> A/

This framework is already signed with the developer cert before archiving begins as can be seen in the distribution pipeline logs as well as with the codesign tool. This signature is apparently verified when starting the distribution process showing Analyzing signature during the process. The failure comes later when attempting to re-sign MyKit.framework presumably for distribution.

Normally when codesign fails it shows an In subcomponent: pointing to the cause of the failure. In our case no such line appears giving us no way to track down the offending subcomponent. Indeed, even examining the framework in the archive shows only code and non-code resources correctly placed.

Given this we have several questions:

1) How can we determine where the offending piece of the framework is located if code sign won't tell us? Is there some debug logging that can be enabled somehow?

2) Is this a supported build configuration (command line built static libraries -> XCFramework -> framework -> app)? This works correctly for all other Apple platforms and architectures, Mac Catalyst (archive) being the exception.

3) If not, what is the recommended way to incorporate 3rd party pre-built static libraries into a shared framework for a shipping app for Mac Catalyst?

This turned out to be some kind of Xcode bug after all. The following contains the symptoms we observed and the solution which worked for us in the hopes that it will help someone else.


To view the problem perform the following steps:

Select the project in the file browser, then the MyKit target, and observe the Enable Bitcode setting for MyKit.framework. It shows Yes with both items in bold text as:

Enabled Bitcode - Yes

indicating that some customization had been applied to the setting.

Now change the view settings to levels from combined and observe Yes in bold under the Resolved, MyKit and iOS Default columns as:

Build Options
Settings - Resolved - MyKit - MyApp - iOS Default
Enable Bitcode - Yes - Yes - <empty> - Yes

with the MyKit column highlighted in green.


To fix the problem perform the following steps:

Highlight the Enable Bitcode row then press delete. The settings should now be changed to (Xcode 12.2 GM):

Build Options
Settings - Resolved - MyKit - MyApp - iOS Default
Enable Bitcode - Yes - <empty> - <empty> - Yes

with the iOS Default column now highlighted in green.


The diff for the project file only shows two items changed. Xcode removed ENABLE_BITCODE = YES for both the Debug and Release configurations of the MyKit framework target though it still shows as enabled in Xcode when viewing the settings as combined. After applying this change the Any Mac (Apple Silicon, Intel) build can be archived and exported properly with no signing errors.


Takeaway / Lessons Learned:

Try randomly removing customized Xcode project settings values when things go wrong (by highlighting and pressing the delete key on them).