Hi All, I am building my own MDM server. It seems that in order for the MDM commands to function an MDM Push Certificate for the APNS framework. And in order to get the MDM Push Certificate from the Apple Push Certificates Portal (https://identity.apple.com/pushcert/) you need to upload your CSR usually provided and sign by the MDM Vendor of your choosing. I am familiar with this process. But now that I am the MDM Vendor, I am not sure where to get this MDM Vendor CSR Signing Certificate. I've already submitted a formal request via the "contact us" form. Apple's response pointed me to the documentation on Setting Up Push Notifications and the MDM Vendor CSR Signing Certificate help page (which I had already reviewed): https://developer.apple.com/documentation/devicemanagement/setting-up-push-notifications-for-your-mdm-customers https://developer.apple.com/help/account/certificates/mdm-vendor-csr-signing-certificate/ The issue is that these documents describe using the signing certificate, but not the process for obtaining it as a new, independent vendor. So does anyone know of a portal or method of generating this “MDM Vendor Certificate”? or maybe I'm going about this all wrong and there is a simpler way… the again, its apple, so I’m probably on the right path just beed a little direction please. (I am not sure where to get this MDM Vendor CSR Signing Certificate.)

Hi, I have some doubts about certificates expiration given this "new" requirement around signing for some common third party SDKs: https://developer.apple.com/support/third-party-SDK-requirements/ Use case: I build an SDK that will be distributed as an XCFramework and will be used in AppStore apps from different people. My SDK internally uses some other third party libraries that are integrated as binaries Let's assume some of those third party libraries are from the list above and therefore seem to be required to be signed. I distribute my SDK with all in order (third party SDKs from that list with valid signatures) People using my SDK over the time provide an update to their apps on the AppStore but by then some of the third party libraries of my SDK has an expired certificate. What would happen? People using my SDK won't have any issues as far as my SDK has a valid signature (despite third party libraries from the list have expired signatures) People using my SDK will get a warning about it but still will be able to submit to the AppStore. In that case, would AppStore Review process decline the update? People using my SDK will get an error, not being able to submit to the AppStore and will require me an update version of the SDK with those third party libraries re-signed. My understanding is that all would work as far as my SDK has a valid signature (after all is the one taking responsibility of the code inside), independently of what happens with the signature of those libraries themselves, am I correct?.

I've submitted my app, signed with a new Developer Id Certificate for a distribution outside of the App Store, 88 hours ago. xcrun notarytool history ... Shows the submission as "In Progress". xcrun notarytool log ... Tells me "Submission log is not yet available or submissionId does not exist". I don't know if that's expected for an "In Progress" submission. As far as I can tell the signing worked without problems. I'm using the Tauri toolchain, which under its hood is using notarytool. How long can I expect this to take? If there is a problem with my submission does the status just stay on "In Progress" or do I get an error? Thanks

I tried to create a new IOS provisioning profile and re-apply it to the app using Xcode to build it, but I got into trouble. The build is good, but it bounces when running the app. I would appreciate it if you could let me know what to do.

Can you please help us with the scenario below, including details and Apple’s recommendations? I've already read through the Notarization and Gatekeeper documentation. The installed version of our application is 1.2.3, located in /Applications/XYZSecurity.app. We created an upgrade package for version 1.2.4. As part of the pre-install script in the 1.2.4 installer, we explicitly deleted some obsolete .dylib files from /Applications/XYZSecurity.app/Contents/Frameworks and some executable files from /Applications/XYZSecurity.app/Contents/MacOS that were no longer needed in version 1.2.4. The installation of version 1.2.4 completed successfully, but we see the below error logs in installer.log: PackageKit: Failed to unlinkat file reference /Applications/XYZSecurity.app/Contents/Frameworks/libhelper.dylib PackageKit: Failed to unlinkat file reference /Applications/XYZSecurity.app/Contents/MacOS/helper-tool Our Key Questions: Is it the right practice to remove obsolete files in the pre-install script during an upgrade? Is this approach recommended by Apple? Can this cause any issues with Apple Gatekeeper? Is there a possibility of my application getting blocked by Gatekeeper as a result?

My notary service has been stuck for more than 5 hours. Is it because i am a new user or there is an notary service outage.

I help a lot of developers with macOS trusted execution problems. For example, they might have an app being blocked by Gatekeeper, or an app that crashes on launch with a code signing error. If you encounter a problem that’s not explained here, start a new thread with the details. Put it in the Code Signing > General subtopic and tag it with relevant tags like Gatekeeper, Code Signing, and Notarization — so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Trusted Execution Problems macOS supports three software distribution channels: The user downloads an app from the App Store. The user gets a Developer ID-signed program directly from its developer. The user builds programs locally using Apple or third-party developer tools. The trusted execution system aims to protect users from malicious code. It’s comprised of a number of different subsystems. For example, Gatekeeper strives to ensure that only trusted software runs on a user’s Mac, while XProtect is the platform’s built-in anti-malware technology. Note To learn more about these technologies, see Apple Platform Security. If you’re developing software for macOS your goal is to avoid trusted execution entanglements. You want users to install and use your product without taking any special steps. If, for example, you ship an app that’s blocked by Gatekeeper, you’re likely to lose a lot of customers, and your users’ hard-won trust. Trusted execution problems are rare with Mac App Store apps because the Mac App Store validation process tends to catch things early. This post is primarily focused on Developer ID-signed programs. Developers who use Xcode encounter fewer trusted execution problems because Xcode takes care of many code signing and packaging chores. If you’re not using Xcode, consider making the switch. If you can’t, consult the following for information on how to structure, sign, and package your code: Placing content in a bundle Embedding nonstandard code structures in a bundle Embedding a command-line tool in a sandboxed app Creating distribution-signed code for macOS Packaging Mac software for distribution Gatekeeper Basics User-level apps on macOS implement a quarantine system for new downloads. For example, if Safari downloads a zip archive, it quarantines that archive. This involves setting the com.apple.quarantine extended attribute on the file. Note The com.apple.quarantine extended attribute is not documented as API. If you need to add, check, or remove quarantine from a file programmatically, use the quarantinePropertiesKey property. User-level unarchiving tools preserve quarantine. To continue the above example, if you double click the quarantined zip archive in the Finder, Archive Utility will unpack the archive and quarantine the resulting files. If you launch a quarantined app, the system invokes Gatekeeper. Gatekeeper checks the app for problems. If it finds no problems, it asks the user to confirm the launch, just to be sure. If it finds a problem, it displays an alert to the user and prevents them from launching it. The exact wording of this alert varies depending on the specific problem, and from release to release of macOS, but it generally looks like the ones shown in Apple > Support > Safely open apps on your Mac. The system may run Gatekeeper at other times as well. The exact circumstances under which it runs Gatekeeper is not documented and changes over time. However, running a quarantined app always invokes Gatekeeper. Unix-y networking tools, like curl and scp, don’t quarantine the files they download. Unix-y unarchiving tools, like tar and unzip, don’t propagate quarantine to the unarchived files. Confirm the Problem Trusted execution problems can be tricky to reproduce: You may encounter false negatives, that is, you have a trusted execution problem but you don’t see it during development. You may also encounter false positives, that is, things fail on one specific Mac but otherwise work. To avoid chasing your own tail, test your product on a fresh Mac, one that’s never seen your product before. The best way to do this is using a VM, restoring to a snapshot between runs. For a concrete example of this, see Testing a Notarised Product. The most common cause of problems is a Gatekeeper alert saying that it’s blocked your product from running. However, that’s not the only possibility. Before going further, confirm that Gatekeeper is the problem by running your product without quarantine. That is, repeat the steps in Testing a Notarised Product except, in step 2, download your product in a way that doesn’t set quarantine. Then try launching your app. If that launch fails then Gatekeeper is not the problem, or it’s not the only problem! Note The easiest way to download your app to your test environment without setting quarantine is curl or scp. Alternatively, use xattr to remove the com.apple.quarantine extended attribute from the download before you unpack it. For more information about the xattr tool, see the xattr man page. Trusted execution problems come in all shapes and sizes. Later sections of this post address the most common ones. But first, let’s see if there’s an easy answer. Run a System Policy Check macOS has a syspolicy_check tool that can diagnose many common trusted execution issues. To check an app, run the distribution subcommand against it: % syspolicy_check distribution MyApp.app App passed all pre-distribution checks and is ready for distribution. If there’s a problem, the tool prints information about that problem. For example, here’s what you’ll see if you run it against an app that’s notarised but not stapled: % syspolicy_check distribution MyApp.app App has failed one or more pre-distribution checks. --------------------------------------------------------------- Notary Ticket Missing File: MyApp.app Severity: Fatal Full Error: A Notarization ticket is not stapled to this application. Type: Distribution Error … Note In reality, stapling isn’t always required, so this error isn’t really Fatal (r. 151446728 ). For more about that, see The Pros and Cons of Stapling forums. And here’s what you’ll see if there’s a problem with the app’s code signature: % syspolicy_check distribution MyApp.app App has failed one or more pre-distribution checks. --------------------------------------------------------------- Codesign Error File: MyApp.app/Contents/Resources/added.txt Severity: Fatal Full Error: File added after outer app bundle was codesigned. Type: Notary Error … The syspolicy_check isn’t perfect. There are a few issues it can’t diagnose (r. 136954554, 151446550). However, it should always be your first step because, if it does work, it’ll save you a lot of time. Note syspolicy_check was introduced in macOS 14. If you’re seeing a problem on an older system, first check your app with syspolicy_check on macOS 14 or later. If you can’t run the syspolicy_check tool, or it doesn’t report anything actionable, continue your investigation using the instructions in the following sections. App Blocked by Gatekeeper If your product is an app and it works correctly when not quarantined but is blocked by Gatekeeper when it is, you have a Gatekeeper problem. For advice on how to investigate such issues, see Resolving Gatekeeper Problems. App Can’t Be Opened Not all failures to launch are Gatekeeper errors. In some cases the app is just broken. For example: The app’s executable might be missing the x bit set in its file permissions. The app’s executable might be subtly incompatible with the current system. A classic example of this is trying to run a third-party app that contains arm64e code on systems prior to macOS 26 beta. macOS 26 beta supports arm64e apps directly. Prior to that, third-party products (except kernel extensions) were limited to arm64, except for the purposes of testing. The app’s executable might claim restricted entitlements that aren’t authorised by a provisioning profile. Or the app might have some other code signing problem. Note For more information about provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. In such cases the system displays an alert saying: The application “NoExec” can’t be opened. [[OK]] Note In macOS 11 this alert was: You do not have permission to open the application “NoExec”. Contact your computer or network administrator for assistance. [[OK]] which was much more confusing. A good diagnostic here is to run the app’s executable from Terminal. For example, an app with a missing x bit will fail to run like so: % NoExec.app/Contents/MacOS/NoExec zsh: permission denied: NoExec.app/Contents/MacOS/NoExec And an app with unauthorised entitlements will be killed by the trusted execution system: % OverClaim.app/Contents/MacOS/OverClaim zsh: killed OverClaim.app/Contents/MacOS/OverClaim In some cases running the executable from Terminal will reveal useful diagnostics. For example, if the app references a library that’s not available, the dynamic linker will print a helpful diagnostic: % MissingLibrary.app/Contents/MacOS/MissingLibrary dyld[88394]: Library not loaded: @rpath/CoreWaffleVarnishing.framework/Versions/A/CoreWaffleVarnishing … zsh: abort MissingLibrary.app/Contents/MacOS/MissingLibrary Code Signing Crashes on Launch A code signing crash has the following exception information: Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) The most common such crash is a crash on launch. To confirm that, look at the thread backtraces: Backtrace not available For steps to debug this, see Resolving Code Signing Crashes on Launch. One common cause of this problem is running App Store distribution-signed code. Don’t do that! For details on why that’s a bad idea, see Don’t Run App Store Distribution-Signed Code. Code Signing Crashes After Launch If your program crashes due to a code signing problem after launch, you might have encountered the issue discussed in Updating Mac Software. Non-Code Signing Failures After Launch The hardened runtime enables a number of security checks within a process. Some coding techniques are incompatible with the hardened runtime. If you suspect that your code is incompatible with the hardened runtime, see Resolving Hardened Runtime Incompatibilities. App Sandbox Inheritance If you’re creating a product with the App Sandbox enabled and it crashes with a trap within _libsecinit_appsandbox, it’s likely that you’re having App Sandbox inheritance problems. For the details, see Resolving App Sandbox Inheritance Problems. Library Loading Problem Most library loading problems have an obvious cause. For example, the library might not be where you expect it, or it might be built with the wrong platform or architecture. However, some library loading problems are caused by the trusted execution system. For the details, see Resolving Library Loading Problems. Explore the System Log If none of the above resolves your issue, look in the system log for clues as to what’s gone wrong. Some good keywords to search for include: gk, for Gatekeeper xprotect syspolicy, per the syspolicyd man page cmd, for Mach-O load command oddities amfi, for Apple mobile file integrity, per the amfid man page taskgated, see its taskgated man page yara, discussed in Apple Platform Security ProvisioningProfiles You may be able to get more useful logging with this command: % sudo sysctl -w security.mac.amfi.verbose_logging=1 Here’s a log command that I often use when I’m investigating a trusted execution problem and I don’t know here to start: % log stream --predicate "sender == 'AppleMobileFileIntegrity' or sender == 'AppleSystemPolicy' or process == 'amfid' or process == 'taskgated-helper' or process == 'syspolicyd'" For general information the system log, see Your Friend the System Log. Revision History 2025-08-06 Added the Run a System Policy Check section, which talks about the syspolicy_check tool (finally!). Clarified the discussion of arm64e. Made other editorial changes. 2024-10-11 Added info about the security.mac.amfi.verbose_logging option. Updated some links to point to official documentation that replaces some older DevForums posts. 2024-01-12 Added a specific command to the Explore the System Log section. Change the syspolicy_check callout to reflect that macOS 14 is no longer in beta. Made minor editorial changes. 2023-06-14 Added a quick call-out to the new syspolicy_check tool. 2022-06-09 Added the Non-Code Signing Failures After Launch section. 2022-06-03 Added a link to Don’t Run App Store Distribution-Signed Code. Fixed the link to TN3125. 2022-05-20 First posted.

I am building an electron app bundled with python. My code signing was fast, but when it came to notarization, it has already taken over 6+ hours. How can I speed things up?

My notarization submission been "In Progress" status for over 30 minutes now. I thought this process should be much faster.

I'm working on an app that needs access to device activity. When I add device activity entitlement, I'm getting Provisioning profile "..." doesn't include the com.apple.developer.deviceactivity entitlement. This is failing for both, the main app and the extension, and both have entitlements added. It is not clear how to add it to the profile, the provisioning profile is created/managed by XCode. When I remove the entitlement, I can build my app but it won't be able to use device activity data I reached out to Developer Support, and they sent me here. What is the right way to add device activity entitlement? I'm also seeing another issue with XCode Cloud builds. When I remove device activity entitlement. I can build my app w/o any issue, and I can also install it directly on my iPhone. However, XCode Cloud builds fail wit Run command: 'xcodebuild -exportArchive -archivePath /Volumes/workspace/tmp/d41fc2f1-4f39-4906-8941-112488e75f6c.xcarchive -exportPath /Volumes/workspace/adhocexport -exportOptionsPlist /Volumes/workspace/ci/ad-hoc-exportoptions.plist '-DVTPortalRequest.Endpoint=http://172.16.68.193:8089' -DVTProvisioningIsManaged=YES -IDEDistributionLogDirectory=/Volumes/workspace/tmp/ad-hoc-export-archive-logs -DVTSkipCertificateValidityCheck=YES -DVTServicesLogLevel=3' I suspect that it could be related to my app having DeviceActivityExtension but no device activity entitlement is present. Thanks, Peter.

Hi everyone. Sorry if this is not an appropriate forum section for this question. I'm making a game engine and it doesn't launch on my colleague's MacBook, although it does launch on mine. There's an application file, let's say, Sample.app. And along with it in the same folder there's Engine.dylib. If we look at the app-file structure, the executable file's path is Contents/MacOS/Sample. So for the executable file the library is located at the path ../../../Engine.dylib. But when my colleague runs the Sample.app file, he gets an error "Library not loaded: @executable_path/../../../Engine.dylib". Although the path is correct and on my MacBook it works. Are there any ideas how to fix it?

I am trying to notarize a simple app I made, but keep getting stuck on "In Progress". The app is a MacOS app, and I'm using XCode. I've tried all the steps listed in the links below: https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution https://developer.apple.com/documentation/security/resolving-common-notarization-issues I've had the same issue with another app, which got rejected after multiple hours. Never got to resolve this.

Hello, I had a successful attempt at notarization earlier today in my build pipeline. I've been using the same system for building my macOS application for over a year now. However, subsequent builds seemed to fail. I found a couple similar topics which makes this seem not not an isolated incident: https://developer.apple.com/forums/thread/782950 https://developer.apple.com/forums/thread/783347 https://developer.apple.com/forums/thread/783283 In my case I use the following command to submit the notarization: xcrun notarytool submit FilePath.dmg --apple-id "myappleid@gmail.com" --password "redacted_obviously" --team-id "my-team-id" --wait I left a previous run go for over an hour and the "Current status: In Progress.................. etc" filled the whole terminal. I manually checked the progress of the submissions using the command below: xcrun notarytool log --apple-id "myappleid@gmail.com" --password "redacted_obviously_again" --team-id "my-team-id" [run id] And they all result in the following output: Submission log is not yet available or submissionId does not exist Is anyone else experiencing this? Are there any possible solutions?

Xcode is prompting I enter a codesign login password when I am archiving my project. My password seems incorrect since there is no action after I enter my password and tap allow. what could be the problem?

I have a pass type id that expired. I created a CSR in keychain access on my Mac. I uploaded the CSR and generated a new cert. I downloaded the new cert and imported into keychain access. I don't see the associated private key and I cannot export a .p12 certificate. It's possible I started with the wrong key to generate the CSR or maybe I inadvertently deleted key while trying to locate the cert after importing. I'm not sure how to determine which. I do still have the private key from the cert that expired. But, I cannot figure out how to sign a cert again, my only option now is download. I've been searching the forum and while there may be an answer, I may just be looking for the wrong thing. I could use some help if anybody would be so kind.

Hello everyone, I’m trying to notarize my macOS app (DockIt.zip) using the new notarytool CLI, but every submission remains in In Progress status forever, it never moves to Accepted or Rejected. I’ve tried multiple rebuilds, credential resets, and even the Xcode GUI method, but the result is the same. Environment • macOS 14.x • Xcode 15.x / Command-Line Tools 15.x • Apple ID: afonsocruz.dev@icloud.com (Team ID: 264Z9XKCT6) • Keychain profile: DockItCreds Steps taken 1. zip -r DockIt.zip DockIt.app 2. xcrun notarytool store-credentials DockItCreds --apple-id ... --team-id 264Z9XKCT6 3. xcrun notarytool submit DockIt.zip --keychain-profile DockItCreds --wait 4. xcrun notarytool history --keychain-profile DockItCreds History snapshot 167a9600-5c7c-4bc4-b984-dd967d30e161 (2025-05-19T11:37:59Z) – In Progress 7167f7c8-d448-4b35-9817-055009f2730a (2025-05-19T04:59:34Z) – In Progress 6ef0610a-595f-4c57-b0f2-f5fe783e8679 (2025-05-18T22:04:10Z) – In Progress bddde388-a34a-42c4-afb8-f06f2b0fe8fa (2025-05-17T10:24:07Z) – In Progress Questions Is it normal to stay “In Progress” for so long? Any recent service changes or outages? How can I get more detailed logs? Also, I'm still learning about macOS development and these steps! If there's something obvious and I was not able to see, please, take into consideration! Thanks!

I have app developed in electron.js and python and it works in ios 15 after codesigning but not in ios 14 or below I need to understand if theres a specific instruction that we need to while building the app or do I need to codesign in lower version? what can I do solve this issue??

iPad(第10世代、iOS v18.1)でMDMを使用してWi-Fiを設定すると、「ネットワーク「SSID名」に接続できない」という問題が発生しています。 この件についてアドバイスをいただければ幸いです。 私が取った手順は次のとおりです。 1.iPadをWi-Fiに接続し、Wi-Fi情報(SSID、ユーザー名、パスワード)をカスタム属性値としてMDMに登録します。 2. MDMから、Wi-Fiプロファイルをデバイスに配布します。 3.Wi-Fiプロファイルがデバイスにインストールされ、その後、ネットワークは自動的に切断されます。 ネットワークに再接続 4.To、OS設定の「Wi-Fi > My Network」に表示されているSSIDをタップしてください。 5.次の証明書画面で、「信頼」ボタンをタップします。 ここで、「ネットワーク「SSID名」に接続できません」というエラーが発生しました。 Appleサポートの提案に基づいて、以下を確認しました。しかし、問題はありません。 1.ルーターの電源がオンになっており、デバイスが通信範囲内にあります。 他のデバイスはWi-Fiに接続できるので問題ありません。 2.Wi-Fiがオンになり、ネットワークが認識されていることを確認します。 Wi-Fiが「オン」で、ネットワークが認識されます。 3.入力画面が表示された場合は、Wi-Fiパスワードを入力します。 入力画面が表示されません。 4.Wi-Fiネットワークに問題がないことを確認します。 接続されているWi-Fiネットワークの名前の下にWi-Fi警告/エラーは表示されません。 5.ケーブルと接続状態を確認します。 他のデバイスはWi-Fiに接続できるので問題ありません。 6.iPadを再起動します。 iPadを再起動しました。しかし、問題は解決しませんでした。 OS:iPadOS18.1 デバイス:iPad第10世代

From time to time I see folks run into error 65 when stapling a ticket to their notarised Mac software. This post explains the two common causes of that error. If you have questions or comments, start a new thread here on the forums. Put it in the Code Signing > Notarization topic area so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Error 65 When Stapling If you directly distribute Mac software, you must sign and notarise your product so that it passes Gatekeeper. For information on how to do this, see: Notarizing macOS software before distribution, if you use Xcode Creating distribution-signed code for macOS, Packaging Mac software for distribution, and Customizing the notarization workflow otherwise The last step of that process is to staple a ticket to your notarised product. This can fail with error 65. There are two common causes of that failure: No appropriate ticket Trust issues The following sections explain how to recognise and resolve these issues. Note You are not absolutely required to staple your product. See The Pros and Cons of Stapling for more on that topic. No Appropriate Ticket Consider the following stapling error: % stapler staple "TestError65.dmg" Processing: /Users/quinn/Desktop/TestError65 2025-03-03 22-12-47/TestError65.dmg CloudKit query for TestError65.dmg (2/d812985247c75e94fd603f026991f96144a031af) failed due to "Record not found". Could not find base64 encoded ticket in response for 2/d812985247c75e94fd603f026991f96144a031af The staple and validate action failed! Error 65. Note the Record not found message. This indicates that the stapling operation failed because there’s no appropriate ticket. To investigate this, look at the notary log: % notarytool-log b53042b6-4cbb-4cef-ade4-dae034a69947 { … "status": "Accepted", … "sha256": "f012735a6d53b17082c088627da4249c9988111d17e7a90c49aa64ebc6bae22e", "ticketContents": [ { "path": "TestError65.dmg/TestError65.app", "digestAlgorithm": "SHA-256", "cdhash": "abc27b0f2daee77b9316de3c6844fbd9e234621c", "arch": "x86_64" }, { "path": "TestError65.dmg/TestError65.app", "digestAlgorithm": "SHA-256", "cdhash": "9627c72e53d44ae77513613e2ce33314bd5ef41e", "arch": "arm64" }, { "path": "TestError65.dmg/TestError65.app/Contents/MacOS/TestError65", "digestAlgorithm": "SHA-256", "cdhash": "abc27b0f2daee77b9316de3c6844fbd9e234621c", "arch": "x86_64" }, { "path": "TestError65.dmg/TestError65.app/Contents/MacOS/TestError65", "digestAlgorithm": "SHA-256", "cdhash": "9627c72e53d44ae77513613e2ce33314bd5ef41e", "arch": "arm64" }, { "path": "TestError65.dmg", "digestAlgorithm": "SHA-256", "cdhash": "01a553c91ee389764971767f5082ab8c7dcece02" } ], "issues": null } First, make sure that the status field is Accepted. If there’s some other value, the notary service didn’t generate a ticket at all! To understand why, look at the rest of the notary log for errors and warnings. Assuming that your notarisation request was successful, look through the log for cdhash values. These represent the contents of the ticket generated by the notary service. Compare that list to the cdhash values of the code being signed: % hdiutil attach "TestError65.dmg" … … /Volumes/Install TestError65 % codesign -d -vvv --arch arm64 "/Volumes/Install TestError65/TestError65.app" … CDHash=9627c72e53d44ae77513613e2ce33314bd5ef41e … % codesign -d -vvv --arch x86_64 "/Volumes/Install TestError65/TestError65.app" … CDHash=abc27b0f2daee77b9316de3c6844fbd9e234621c … Those are all present in the ticket. However, consider the cdhash of the disk image itself: % codesign -d -vvv "TestError65.dmg" … CDHash=d812985247c75e94fd603f026991f96144a031af … That’s the cdhash that stapler is looking for: CloudKit query for TestError65.dmg (2/d812985247c75e94fd603f026991f96144a031af) failed due to "Record not found". But it’s not present in the notarised ticket. Note The term cdhash stands for code directory hash. If you’re curious what that’s about, see TN3126 Inside Code Signing: Hashes and the Notarisation Fundamentals DevForums post. What happened here is: I built the app. I signed it with my Developer ID code-signing identity. I created a disk image from that app. I signed that with my Developer ID code-signing identity. I notarised that. I then re-signed the disk image. This changes the cdhash in the code signature. Now the disk image’s cdhash doesn’t match the cdhash in the ticket, so stapling fails. To resolve this problem, make sure you’re stapling exactly the file that you submitted to the notary service. One good option is to compare the SHA-256 hash of the file you’re working on with the sha256 field in the notary log. Trust Issues Now consider this stapling error: % stapler staple "TestError65.dmg" Processing: /Users/quinn/TestError65.dmg Could not validate ticket for /Users/quinn/TestError65.dmg The staple and validate action failed! Error 65. Note how it’s different from the previous one. Rather than saying that the ticket was not found, it says Could not validate ticket. So, stapler found the ticket for the file and then tried to validate it before doing the staple operation. That validation failed, and thus this error. The most common cause of this problem is folks messing around with trust settings. Consider this: % security dump-trust-settings SecTrustSettingsCopyCertificates: No Trust Settings were found. % security dump-trust-settings -d SecTrustSettingsCopyCertificates: No Trust Settings were found. Contrast it with this: % security dump-trust-settings SecTrustSettingsCopyCertificates: No Trust Settings were found. % security dump-trust-settings -d Number of trusted certs = 1 Cert 0: Apple Root CA - G3 Number of trust settings : 10 … Someone has tweaked the trust settings for the Apple Root CA - G3 anchor. In fact, I used Keychain Access to mark the certificate as Always Trust. You’d think that’d avoid problems, but you’d be wrong. Our code signing machinery expects Apple’s anchor and intermediate certificates to have the default trust settings. IMPORTANT Some trust settings overrides are fine. For example, on my main work Mac there are trust settings overrides for Apple internal anchors. This problem occurs when there are trust settings overrides for Apple’s standard anchor and intermediate certificates. To fix this: In Terminal, run the dump-trust-settings commands shown above and build a list of Apple certificates with trust settings overrides. In Keychain Access, find the first problematic certificate in your list. Note that there may be multiple instances of the certificate in different keychains. If that’s the case, follow these steps for each copy of the certificate. Double click the certificate to open it in a window. If the Trust section is collapsed, expand it. Ensure that all the popups are set to their default values (Use System Defaults for the first, “no value specified” for the rest). If they are, close the window and move on to step 8. If not, set the popups to the default values and close the window. Closing the window may require authentication to save the trust settings. Repeat steps until 2 through 7 for each of the problematic certificates you found in step 1. When you’re done, run the dump-trust-settings commands again to confirm that your changes took effect.

I have recently enrolled in the Apple Developer to get my app notarized, and submitted an Archive for notarization, but it is taking forever. It has almost been a whole day, but the status is still in progress, whereas I have seen other developers say that the same takes 10-15 mins to an hour for them. Am I doing anything wrong? Please guide me through this.