In the developer documentation Customizing the notarization workflow it states that the notarytool supports a --webhook flag. When the notarization is complete the Apple notarization server will send the following webhook payload to the webserver that I configured. { "payload": "{\"completed_time\":\"2024-02-13T17:24:37.911Z\",\"event\":\"processing-complete\",\"start_time\":\"2024-02-13T17:24:02.743Z\",\"submission_id\":\"<submission-id>\",\"team_id\":\"<team-id>\"}", "signature": "<signature>", "cert_chain": "<base64-certchain>" } My question is how can I validate that this Webhook is coming from Apple? In that same developer documentation it states the various IP addresses that the stapler requires access too but those are not the same addresses that the notarytool webhook results are coming from. Presumably I should be able to use the signature to validate that the request is coming from Apple, however I have been unable to find any documentation about this webhook flag at all beyond the documentation stating that it exists.

I have an application that is being deployed outside of the AppStore using a PKG installer. Since our application has to be deployed outside the AppStore (for enterprise configuration requirements) we also need to handle updates outside the AppStore. I understand that SMJobBless function is now deprecated which seems to be how much open source software is implementing their privileged helpers namely Firefox. However, since I am already deploying my software using a PKG installer why should I use SMJobBless or the new version SMAppService rather than adding additional functionality to my postinstall script that will set up a LaunchDaemon to handle my automatic updates? The main issues that come to mind for me is that if a user were to delete our application rather than running the uninstall script the LaunchDaemon would still persist. Therefore we will likely need to handle that scenario and either have the LaunchDaemon recognize that and remove itself, or exit and do nothing. Additionally, I would be missing out on the security benefits that a service like SMJobBless provides by only allowing my AuthorizedClient to execute the privileged helper. On the other hand at least my LaunchDaemon would consistently work with older versions of macOS and I wouldn't be locked in to either supporting both SMJobBless and SMAppService or supporting only systems running macOS 13+. What have other people done to handle automatic updates when they can't deploy through the AppStore? Is just creating a LaunchDaemon a common path? How do people typically handle removing the LaunchDaemon if their application is uninstalled?

I believe that this is related to the post https://developer.apple.com/forums/thread/790880. I essentially have the same problem that they did. I submit my Distribution PKG for notarization but the notarization fails and when I attempt to install the PKG user the UI I get a "External component packages (3) trustLevel=0 (trust evaluation failed; treating as invalid due to higher trust level for parent product archive)" However if I install using "sudo installer -verboseR -pkg ConcealDistribution.pkg -target /" everything works as expected. The difference between me and the other post is that when I expand my PKG using pkgutil --expand I do not have a Resources folder within my top level distribution. Instead my structure looks like ConcealDistribution ├── Distribution ├── ConcealConnect.pkg ├── ConcealBrowse.pkg └── ConcealUpdate.pkg The specific notary service errors I receive are as follows { "logFormatVersion": 1, "jobId": "7e30e3fd-1739-497c-a02e-64fbe357221d", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "ConcealDistribution.pkg", "uploadDate": "2025-10-08T19:41:33.491Z", "sha256": "40aacfacf25c6da0be8fe31ae9c145a25ddf9ed1f38be714687c74d95b26619d", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "ConcealDistribution.pkg", "message": "Package ConcealDistribution.pkg has no signed executables or bundles. No tickets can be generated.", "docUrl": null, "architecture": null }, { "severity": "warning", "code": null, "path": "ConcealDistribution.pkg", "message": "The contents of the package at ConcealDistribution.pkg could not be extracted.", "docUrl": null, "architecture": null } ] } For what its worth all the inner PKGs have their executables signed, the PKGs are signed themselves and they are all notarized and stapled without issue. Then I am attempting to sign and notarize the outer PKG and that is where the problems pop up. Additionally I'm not sure when this stopped working as I expected but just a few months ago I was able to do this exact same process and install with the UI and have it work.

Is the Notary service unavailable again? The system-status page shows it as being green but I am back to receiving the same error as previously which fixed itself once the notary service went green again and I am unable to notarize and staple my Distribution PKG.