Unable to export Mac app Archive under Developer ID - code signing fails

Question

Created Jan ’23

Replies 4

Boosts 0

Participants 2

Our app contains several 3rd-party dylibs, which we've successfully bundled in our app and signed for Developer ID distribution many times. I just added a new 3rd-party dylib (libusd_ms.dylib, built from source) which expects to find a directory of resources (directory name "usd") in the .app/Contents/Frameworks directory. So I added the directory to my Copy Frameworks Build Phase with Code Sign On Copy checked.

Debug and Profile builds work as expected. Archived builds have the directory in /Frameworks. Checking the problem file (schema.usda) with codesign-d confirms it was signed in the Archive. But exporting the Archive to disk for distribution gives "Code Signing Failed" and points me to IDEDistributionPipeline.log, which reports:

2023-01-19 21:20:11 +0000  /var/folders/v3/j6lzlhcx34j_4v5w9_ztmfp80000gp/T/XcodeDistPipeline.~~~UzBjEy/Root/Applications/Reflex.app: code object is not signed at all
In subcomponent: /private/var/folders/v3/j6lzlhcx34j_4v5w9_ztmfp80000gp/T/XcodeDistPipeline.~~~UzBjEy/Root/Applications/Reflex.app/Contents/Frameworks/usd/usdShade/resources/usdShade/schema.usda

I confirmed by running codesign -d that the copy of that file in this "pipeline" folder is not signed, but how do I fix that if I've signed the original of the file in my app bundle?

Xcode 14.2 on macOS 13.1

Answered by DTS Engineer in 742655022

which expects to find a directory of resources … in the Contents/Frameworks directory

Yeah, that’s not good. This runs counter to the rules described in Placing Content in a Bundle and, as it says at the top of that doc, “If you put content in the wrong location, you may encounter hard-to-debug code signing and distribution problems.”

Your best option is to move those resources to Content/Resources and adjust the code to match.

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

Boost

Answer 1

fraapaul OP

Jan ’23

Update: I found a different place to put the resources directory that USD lib supports out of the box (Contents/plugin/). No signing appears to be required. So signing this set of files when placed in Resources is now just an academic question. I'm still curious if it's expected that a signed file becomes unsigned when exporting an Archive.

0

Answer 2

DTS Engineer OP

Apple

Jan ’23

Accepted Answer

which expects to find a directory of resources … in the Contents/Frameworks directory

Yeah, that’s not good. This runs counter to the rules described in Placing Content in a Bundle and, as it says at the top of that doc, “If you put content in the wrong location, you may encounter hard-to-debug code signing and distribution problems.”

Your best option is to move those resources to Content/Resources and adjust the code to match.

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

1

Answer 3

fraapaul OP

Jan ’23

Right! I learned of an alternate location supported by libusd (as we have it configured), Contents/plugin/, and using that avoids signing issue for now. But I realize that is still not compliant with the bundle rules. I'll look into getting this changed to the Resources directory. Thanks for the tip and pointer, Quinn.

0

Answer 4

DTS Engineer OP

Apple

Jan ’23

But I realize that is still not compliant with the bundle rules

Indeed, but it’s a lot better. While that’s the wrong location for that specific type of code, it’s a location where Xcode is expecting to see code, and thus it’ll avoid your current issue.

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

0