Mac app can't be opened after re-signing with distribution provisioning profile

unfortunately it can't be opened on any Mac

Right. As a general rule you can’t run distribution-signed code [1]. Such code is only intended to be uploaded to the App Store.

Historically this was a royal pain for Mac developers because there was no good way to test your final distribution-signed code. The good news is that we now have TestFlight on the Mac, so you can upload the code and then test it that way.

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

[1] That’s 100% true on iOS and its children. The story on the Mac is more nuanced (-: In some circumstances it is possible to run distribution-signed code on macOS. However, I recommend that you not try going down that path because it’s full of pitfalls.

So considering my app is only for macOS, I guess I should continue to upload my app via App Store Connect for review now, right?

Right. In theory, changing the code signing shouldn’t affect the app’s behaviour. However, my experience is that the difference between theory and practice is bigger in practice than it is in theory. And that’s exactly why TestFlight is so important: Once you have a build submitted, you can test it with TestFlight and have a high level of confidence that it’ll behave the same as your final product.

Our internal signing system (it is a black box to me) also support hardening and notarization sign for app planed to be released outside App Store. I'm assuming the notarized app returned by the system should be able to run on any Mac, correct?

Correct.

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

Any suggestion about what I can do to debug this issue?

Yeah, that’s not easy. You can usually uncover the cause of such problems by looking in the system log embedded in a sysdiagnose log, but AFAIK App Review doesn’t include such logs with their rejections.

Probably the easiest option here is to wait for your TestFlight build to come through. Alternatively, if you run out of patience, open a DTS tech support incident so that I can dig into this further.

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

Here’s your output reformatted [1]:

Before: CodeDirectory v=20500 size=3294 flags=0x10000(runtime) hashes=91+7 location=embedded
After:  CodeDirectory v=20200 size=3186 flags=0x0(none) hashes=91+5 location=embedded

The hashes change is only tangentially relevant.

The runtime change is relevant. The Mac App Store doesn’t require the hardened runtime but my general advice is that you enable it on all code. Moreover, if your app works when signed with Developer ID, which requires the hardened runtime in order to notarise, then you know the code is already compatible with the hardened runtime and thus there’s no drawback to enabling it.

The version change (v=) is definitely a worry. It looks like your internal signing system is generated old school code signatures, which isn’t great. I’m not aware of a specific issue with this on the Mac (unlike on iOS, where this is a big deal) but it’s posible that I missed a memo somewhere.

Lastly, after I open a TSI, how can I direct it to you

Your TSI is gonna come to me because everyone else is too scared to take Mac code signing questions (-: [2] Seriously though, just reference this thread and it’ll come my way.

share my build with you?

The best way to do that is to put in on a file sharing service and then include the URL in your question.

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

[1] FYI, your follow ups will render better if you post them via a fully-fledge reply rather than in the comments.

[2] Everyone except Matt, that is. He is the Man Without Fear™! (-:

Thanks for reminding the format. I was worrying that a direct reply won't trigger a notification to you.

I have replied the TSI mail to you confirming you are looking at the right app. Let's use the mail for further communication.

"The version change (v=) is definitely a worry. "

I'm checking with our signing system administrator for how it sign my app and what cause the change, but most likely I won't get clear answer due to security policy. So I may need to figure out the reason first if it is a problem of our signing system.

What does the v= mean? Is it the version of signing tool? Or is it related to some value defined in .xcproj file?

IMPORTANT I’m posting this here for the benefit of Future Quinn™. As mentioned upthread, alex_ms has opened a DTS TSI and my full response will be going there.

What does the v= mean?

It’s the version of the code signature. This is determined by the version of macOS doing the signing and the specific signing options you apply. Here’s a quick summary:

| macOS   | standard | + Team ID | + hardened runtime |
| ------- | -------- | --------- | ------------------ |
| 10.13   | 20100    | ! [1]     | ! [2]              |
| 10.13.6 | 20100    | 20200     | 20500              |
| 10.14   | 20100    | ? [3]     | 20500              |
| 10.14.6 | 20100    | ?         | 20500              |
| 10.15   | 20100    | ?         | 20500              |
| 10.15.7 | 20100    | 20200     | 20500              |
| 11.0    | 20400    | 20400     | 20500              |
| 12.1    | 20400    | 20400     | 20500              |

Note I posted the Markdown for the table as preformatted text because DevForums has problems with rendering tables correctly (r. 81109741)-:

Notes:

1. I wasn’t able to run this test because I couldn’t get 10.13 to build a chain of trust for the certificate in my Mac Developer signing identity. I’m not sure why, and it wasn’t that important, so I decided to skip it.

2. 10.13 doesn’t support the -o runtime option.

3. Results marked with ? are ones I skipped because you can infer the answer based on the surrounding results. For example, in this case we know the answer will 20200 because it was that in the previous release (10.13.6) and it was that again in a latter release (10.15.7). Unless the value changed and then changed back, which is unlikely, we can assume it didn’t change between 10.13.6 and 10.15.7.

In the standard column I signed the code like so:

% codesign -s - -f /path/to/code

In the + Team ID column I signed the code like so:

% codesign -s "Mac Developer" -f /path/to/code

In the + hardened runtime column I signed the code like so:

% codesign -s "Mac Developer" -o runtime -f /path/to/code

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

alex_ms and I figured out what’s going wrong here. The issue is that the create-zip-archive step of their “DevOps pipeline” was not running on a Mac, and thus didn’t encode the Unix-y permissions (rwxr-r-x) of their main executable in the zip archive. When you unpack this on the Mac, the main executable ends up with default permissions (rw-rw-r--) and thus fails to launch.

The solution was to tweak the pipeline to run the create-zip-archive step on the Mac side of things.

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