@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&#92;&#95;x86&#92;&#95;64-simulator/libmystuff.aiOS-arm64&#92;&#95;armv7&#92;&#95;armv7s/libmystuff.amacos-arm64&#92;&#95;x86&#92;&#95;64/libmystuff.aiOS-arm64&#92;&#95;x86&#92;&#95;64-maccatalyst/libmystuff.aInfo.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/MyKitResources/ -> Versions/A/Resources/Versions/Versions/A/Versions/A/&#92;&#95;CodeSignature/Versions/A/&#92;&#95;CodeSignature/CodeResourcesVersions/A/MyKitVersions/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).