Open Radar

 
Summary:
Thank you for fixing Radar #21891588, which requested that Xcode should respect the OTHER_CODE_SIGNING_FLAGS build variable when conducting its code signing phase on standard Swift libraries.

Unfortunately, this change revealed another problem which I'm not sure how to work around. Because my application is built with a slightly customized designated requirement (to share keychain identitiy between MAS and direct apps), I define a build variable value for the code signing flags:

OTHER_CODE_SIGN_FLAGS="-r ./Source/CodeSigning/DesignatedRequirement.txt"

Where DesignatedRequirement.txt contains the custom requirement information for my app.

With the fix in place for Swift code signing to apply these flags as well, it addresses my complaint about it not picking up e.g. the --timeout value, but introduces a new problem which is my Swift libraries are now being signed with designated requirements suitable only to the app itself.

In general, there seems to be a challenge in trying to specify in one set of code signing flags how all the code signing in an app's build process should take place. I'm not sure how this should be solved but I thought I'd raise the problem. If you have any ideas for workarounds, I'd love to hear them.

Steps to Reproduce:
1. Create a Swift application project in Xcode
2. Create a custom designated requirement string and specify it via other code signing flags.
3. Build or archive the app.


Expected Results:
The custom designated requirement should apply to the app but not to the bundled Swift libraries.

Actual Results:
The custom designated requirement applies to all the bundled Swift libraries, because they now apply the custom code signing flags.


Version:
Version 7.3 (7D175)

Notes:


Configuration:


Attachments: