"Application damaged and can't be opened' error prompt on 15.6.1 Sequoia

I have checked the following possible root causes:

Did you try pointing syspolicy_check at your app? What does it report?

For instructions, see the Run a System Policy Check section of Resolving Trusted Execution Problems.

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

Yes, the application only shows the stapling error which I understand is not a "fatal" error from the documentation.

"Severity: Fatal Full Error: A Notarization ticket is not stapled to this application. Type: Distribution Error"

I have also run "/usr/bin/log show --predicate '(process == "syspolicyd") && (eventMessage CONTAINS "MyApp")'"

and

"/usr/bin/log show --predicate '(process == "trustd") && (eventMessage CONTAINS "MyApp")'"

I don't see any logs messages for the above two commands

the stapling error which I understand is not a "fatal" error

Correct. I actually filed a bug about the misrepresentation of that error as being fatal (r. 151446728) and I expect we’ll see that change sooner rather than later.

I don't see any logs messages for the above two commands

It’s unlikely you will because the app name is private data and, by default, that’s not recorded. Your Friend the System Log has a link to another post that explains how to record private data.

I’d like to take a look at your app. Can you post a download link? If so, please do. See tip 14 in Quinn’s Top Ten DevForums Tips if you have problems posting the link.

If you’re not able to share the link publicly, let me know by replying here and I can make other arrangements.

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

Thank you. I will not be able to share the link publicly for my application. This is also not occurring on all of the MacOS machines my application is installed in, just a few machines.

Please let me know if we can raise a ticket for this. I can share more background and details on this issue in the ticket.

Even I am seeing the same in my product. syspolicy_check shows "Severity: Fatal Full Error: A Notarization ticket is not stapled to this application. Type: Distribution Error" .

Even I am seeing the same in my product.

As we discussed above, the ticket is not stapled to this application diagnostic is not fatal. Stapling a ticket to your app is optional, as I explain in The Pros and Cons of Stapling. Moreover, there are common situations where you staple the ticket to the outermost container — like a disk image or installer package — rather than the app.

We already have a bug on file requesting that this be downgraded to a warning (r. 151446728).

If you’re having Gatekeeper problems, I recommend that you run through the steps in Resolving Trusted Execution Problems. If that doesn’t help, feel free to start a new thread and we can pick things up there. Use the same subtopic and tags as this thread, so that I see your thread go by.

I will not be able to share the link publicly for my application.

Fair enough.

This is also not occurring on all of the MacOS machines my application is installed in, just a few machines.

Oh, I didn’t realise that was the case, and it definitely changes things.

In situations like that my advice is that you test your product on a ‘clean’ machine. I generally use a VM for this, as explained in Testing a Notarised Product.

IMPORTANT Check the user reports you see whether this is specific to Intel or Apple silicon machines, and then set up your VM accordingly. And if users are seeing this on both architectures, test on whichever architecture is easiest for you to virtualise.

Please try this out and let me know how you get along.

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

We have tried multiple in-house replications for this issue and we were unable to replicate this on demand. This is an issue that is occurring across platforms (Intel/ARM).

We have also tried the install on a fresh VM, however, we are unable to replicate this.

We have also noticed a pattern of all of the affected machines receiving 15.6.1 OS update few days (as close as few hours before) before our product patch is applied and this prompt is triggered.

The install.log indicates a clean install of our product without any issues.

I have created a feedback ticket for the same sharing more details on this issues, FB20104614

I took a look at FB20104614 and it doesn't appear like you have logging from a machine that presented the "Application damaged and can't be opened" prompt. Without that I can't determine why gatekeeper is rejecting the application. Nothing in the logs provided shows any reason for GK would reject the application. Can you get a sysdiagnose immediately after the GK rejection prompt?

It's possible that the Application was damaged before, or somehow got GK-checked when it's transiently incomplete. The OS keeps a cached version of the no-trust result and just keeps rejecting it. On fresh systems everything appears fine.

An easy demo: duplicate a valid app (Firefox maybe?), change the copy's Info.plist to break the code signature, let GK look at it, and then revert the change. The resulting copy will be identical to the original, but is mercilessly rejected by the OS.

We have also noticed the following errors in the console for our application, can you please let us know the root cause of the error

Unexpected Xprotect assessment result (9)

2025-09-09 17:14:38.418914+0200 0x471c02   Default     0x0                  504    0    syspolicyd: [com.apple.syspolicy.exec:default] Adding Gatekeeper denial breadcrumb (open): PST: (path: e2901a0950b8f627), (team: xxxxxxxxxx), (id: com.abc.my-agent), (bundle_id: (null))

2025-09-09 17:14:38.940475+0200 0x727399   Error       0x0                  504    0    syspolicyd: [com.apple.syspolicy.exec:default] Unexpected Xprotect assessment result (9), failing: PST: (path: e2901a0950b8f627), (team: xxxxxxxxxx), (id: com.abc.my-agent), (bundle_id: (null))

2025-09-09 17:14:39.462175+0200 0x72792e   Default     0x0                  504    0    syspolicyd: [com.apple.syspolicy.exec:default] GK evaluateScanResult: 3, PST: (path: e2901a0950b8f627), (team: xxxxxxxxxx), (id: com.abc.my-agent), (bundle_id: (null)), 0, 0, 1, 0, 8, 4, 9

2025-09-09 17:14:39.462850+0200 0x72792e   Default     0x0                  504    0    syspolicyd: [com.apple.syspolicy.exec:default] Prompt shown (1, 0), waiting for response: PST: (path: e2901a0950b8f627), (team: xxxxxxxxxx), (id: com.abc.my-agent), (bundle_id: (null))

Hello, We have attached multiple sysdiagnose logs to the feedback ticket raised. Can you please help us in understanding the root cause of the issue?

Unexpected Xprotect assessment result (9)

An assessment result of 9 represents some sort of internal error. It’s hard to understand what that means without more context.

Honestly, it’s hard to interpret Gatekeeper results when its private data isn’t recorded in the system log. It’s possible to configure macOS to record private data, but that present its own challenges.

Do you have direct access to a machine exhibiting this problem? If so, I’d like to see the following:

1. Enable private data recording.
2. Using the Finder, create a test directory.
3. Copy the problematic app into that directory.
4. Launch it.
5. Assuming that you get the Gatekeeper error, record a rough timestamp of that.
6. And then trigger a sysdiagnose log.
7. Disable private data recording.
8. Upload that load to your bug FB20104614.
9. And add a comment with the timestamp from step 5.
10. Reply back here when you’re done.

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

Hello Quinn, we unfortunately do not have direct access to machines reporting this problem.

We have tried to replicate this issue several times in our testing environment using fresh macOS VMs and we were unable to replicate this problem.

Based on the data we collected so far, this is not a universal problem and occurring only on very few macOS machines across Intel/M-Series.

Were the sysdiagnose files we collected from multiple machines which reported this problem helpful?

We have also added some additional information in the FB20104614 which we are considering as a potential root cause, can you please let us know your views on the same?