This post is a ‘child’ of Resolving errSecInternalComponent errors during code signing. If you found your way here directly, I recommend that you start at the top. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Fixing an untrusted code-signing certificate If your code-signing identity is set up correctly, selecting its certificate in Keychain Access should display a green checkmark with the text “This certificate is valid”. If it does not, you need to fix that before trying to sign code. There are three common causes of an untrusted certificate: Expired Missing issuer Trust settings overrides Check for an expired certificate If your code-signing identity’s certificate has expired, Keychain Access shows a red cross with the text “… certificate is expired”. If you try to sign with it, codesign will fail like so: % codesign -s "Apple Development" -f "MyTrue" error: The specified item could not be found in the keychain. If you use security to list your code-signing identities, it will show the CSSMERR_TP_CERT_EXPIRED status: % security find-identity -p codesigning Policy: Code Signing Matching identities 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" (CSSMERR_TP_CERT_EXPIRED) 1 identities found Valid identities only 0 valid identities found The most likely cause of this problem is that… yep… your certificate has expired. To confirm that, select the certificate in Keychain Access and look at the Expires field. Or double click the certificate, expand the Details section, and look at the Not Valid Before and Not Valid After fields. If your code-signing identity’s certificate has expired, you’ll need to renew it. For information on how to do that, see Developer Account Help. If your certificate hasn’t expired, check that your Mac’s clock is set correctly. Check for a missing issuer In the X.509 public key infrastructure (PKI), every certificate has an issuer, who signed the certificate with their private key. These issuers form a chain of trust from the certificate to a trusted anchor. In most cases the trusted anchor is a root certificate, a certificate that’s self signed. Certificates between the leaf and the root are known as intermediate certificates, or intermediates for short. Your code-signing identity’s certificate is issued by Apple. The exact chain of trust depends on the type of certificate and the date that it was issued. For example, in 2022 Apple Development certificates are issued by the Apple Worldwide Developer Relations Certification Authority — G3 intermediate, which in turn was issued by the Apple Root CA certificate authority. If there’s a missing issuer in the chain of trust between your code-signing identity’s certificate and a trusted anchor, Keychain Access shows a red cross with the text “… certificate is not trusted”. If you try to sign with it, codesign will fail like so: % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature Warning: unable to build chain to self-signed root for signer "Apple Development: …" MyTrue: errSecInternalComponent The message unable to build chain to self-signed root for signer is key. If you use security to list your identities, it will not show up in the Valid identities only list but there’s no explanation as to why: % security find-identity -p codesigning Policy: Code Signing Matching identities 1) 4E587951B705280CBB8086325CD134D4CDA04977 "Apple Development: …" 1 identities found Valid identities only 0 valid identities found IMPORTANT These symptoms can have multiple potential causes. The most common cause is a missing issuer, as discussed in this section. Another potential cause is a trust settings override, as discussed in the next section. There are steps you can take to investigate this further but, because this problem is most commonly caused by a missing intermediate, try taking a shortcut by assuming that’s the problem. If that fixes things, you’re all set. If not, you have at least ruled out this problem. Apple publishes its intermediates on the Apple PKI page. The simplest way to resolve this problem is to download all of the certificates in the Apple Intermediate Certificates list and use Keychain Access to add them to your keychain. Having extra intermediates installed is generally not a problem. If you want to apply a more targeted fix: In Keychain Access, find your code-signing identity’s certificate and double click it. If the Details section is collapsed, expand it. Look at the Issuer Name section. Note the value in the Common Name field and, if present, the Organizational Unit field. For example, for an Apple Development certificate that’s likely to be Apple Worldwide Developer Relations Certification Authority and G3, respectively. Go to the Apple PKI and download the corresponding intermediate. To continue the above example, the right intermediate is labelled Worldwide Developer Relations - G3. Use Keychain Access to add the intermediate to your keychain. Sometimes it’s not obvious which intermediate to choose in step 4. If you’re uncertain, download all the intermediates and preview each one using Quick Look in the Finder. Look in the Subject Name section for a certificate whose Common Name and Organizational Unit field matches the values from step 3. Finally, double check the chain of trust: In Keychain Access, select your code-signing identity’s certificate and choose Keychain Access > Certificate Assistant > Evaluate. In the resulting Certificate Assistant window, make sure that Generic (certificate chain validation only) is selected and click Continue. It might seem like selecting Code Signing here would make more sense. If you do that, however, things don’t work as you might expect. Specifically, in this case Certificate Assistant is smart enough to temporarily download a missing intermediate certificate in order to resolve the chain of trust, and that’ll prevent you from seeing any problems with your chain of trust. The resulting UI shows a list of certificates that form the chain of trust. The first item is your code-signing identity’s certificate and the last is an Apple root certificate. Double click the first item. Keychain Access presents the standard the certificate trust sheet, showing the chain of trust from the root to the leaf. You should expect to see three items in that list: An Apple root certificate An Apple intermediate Your code-signing identity’s certificate If so, that’s your chain of trust built correctly. Select each certificate in that list. The UI should show a green checkmark with the text “This certificate is valid”. If you see anything else, check your trust settings as described in the next section. Check for a trust settings override macOS allows you to customise trust settings. For example, you might tell the system to trust a particular certificate when verifying a signed email but not when connecting to a TLS server. The code-signing certificates issued by Apple are trusted by default. They don’t require you to customise any trust settings. Moreover, customising trust settings might cause problems. If code signing fails with the message unable to build chain to self-signed root for signer, first determine the chain of trust per the previous section then make sure that none of these certificates have customised trust settings. Specifically, for each certificate in the chain: Find the certificate in Keychain Access. 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, move on to the next certificate. If not, set the popups to the default values and close the window. Closing the window may require authentication to save the trust settings. Another way to explore trust settings is with the dump-trust-settings subcommand of the security tool. On a stock macOS system you should see this: % security dump-trust-settings SecTrustSettingsCopyCertificates: No Trust Settings were found. % security dump-trust-settings -d SecTrustSettingsCopyCertificates: No Trust Settings were found. That is, there are no user or admin trust settings overrides. If you run these commands and see custom trust settings, investigate their origins. IMPORTANT If you’re working in a managed environment, you might see custom trust settings associated with that environment. For example, on my personal Mac I see this: % security dump-trust-settings -d Number of trusted certs = 1 Cert 2: QuinnNetCA Number of trust settings : 10 … because my home network infrastructure uses a custom certificate authority and I’ve configured my Mac to trust its root certificate (QuinnNetCA). Critically, this custom trust settings are nothing to do with code signing. If you dump trust settings and see an override you can’t explain, and specifically one related to code-signing certificate, use Keychain Access to remove it. Revision History 2025-09-29 Added information about the dump-trust-settings command to Check for a trust settings override. Made other minor editorial changes. 2022-08-10 First posted.

Problem My ARM64 macOS application is being immediately killed with SIGKILL when launched. No crash report is generated, and the process terminates instantly. Environment macOS Version: 15.x (Sequoia) Architecture: ARM64 (Apple Silicon) Certificate: Mac Developer certificate (development signing) App Type: Native ARM64 application with embedded Java runtime Symptoms ./MacOS/myapp Immediately returns: zsh: killed ./MacOS/myapp Investigation Results System Logs Show Security Policy Rejection kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 92850, /path/to/myapp syspolicyd: (Security) MacOS error: -67062 Error Code Analysis Error -67062 = errSecCSReqFailed (Code signature requirement failed) This is a Gatekeeper enforcement issue, not a code signing problem 3. Code Signature is Valid codesign -dvvv myapp Shows valid signature with Mac Developer certificate Authority=Mac Developer: Name (TEAMID) Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA What We Tried (That Didn't Help) ✅ Removed hardened runtime flag from Java components ✅ Added JIT entitlements (com.apple.security.cs.allow-jit) ✅ Verified Mach-O structure is correct ✅ Confirmed all libraries are ARM64 ✅ Re-signed with proper entitlements None of these fixed the issue because the problem is Gatekeeper policy enforcement. Question How can I allow this development-signed ARM64 app to run on macOS 15 without full notarization? I've tried: Removing quarantine attributes Various code signing approaches Different entitlements But Gatekeeper still blocks it with error -67062. Is there a way to add a security exception for development builds, or do I need to use a Developer ID certificate even for internal testing? Additional Context This is for internal development/testing. The app works fine when properly notarized, but we need a way to test development builds without going through the full notarization process each time. Any suggestions would be greatly appreciated!

We've noticed, that size of our ipa started to vary from time to time. We've found that all the difference was in the LC_CODE_SIGNATURE command under the _LINKEDIT segment of binary. The main reason of that change was the different number of hash slots due to different value of page size: 4096 on macOS SEQUOIA and 16384 on macOS TAHOE. So the size of the final binary was dependent on the machine, it was produced on. I didn't find out any information on why the default page size changed on TAHOE. Apple’s codesign supports a --pagesize argument. For regular builds that setting can be passed via OTHER_CODE_SIGN_FLAGS=--pagesize 16384. But it seems that xcodebuild export ...` completely ignores it: i've tried to pass invalid size (not the power of two), and the export still succeded. I've also managed to get xcodebuild logs via log stream --style compact --predicate 'process == "xcodebuild" OR process == "codesign"' --level trace They have no occurrences of --pagesize: 2026-03-24 13:43:27.236 Df xcodebuild[93993:a08c53] [IDEDistributionPipeline:verbose] invoking codesign: <NSConcreteTask: 0x8a1b21bd0; launchPath='/usr/bin/codesign', arguments='( "-f", "-s", 8C38C4A2CB0388A3DB6BAEFE438F20E044EE6CB2, "--entitlements", "/var/folders/w_/5t00sclx2vlcm4_fvly7wvh00000gn/T/XcodeDistPipeline.~~~T3Dcdf/entitlements~~~c2srXx", "--preserve-metadata=identifier,flags,runtime,launch-constraints,library-constraints", "--generate-entitlement-der", "--strip-disallowed-xattrs", "-vvv", "/var/folders/w_/5t00sclx2vlcm4_fvly7wvh00000gn/T/XcodeDistPipeline.~~~T3Dcdf/Root/Payload/App.app/Frameworks/FLEXWrapper.framework" )'> So here I have some questions: How is the default page size selected? Why the default page size may change between SEQUOIA and TAHOE? How to provide page size to xcodebuild's export or it's a bug that it doesn't look at the value of OTHER_CODE_SIGN_FLAGS?

Sharing a solution for a problem that took me a while to figure out. Problem: During development of a macOS 26 app that uses ScreenCaptureKit, the screen capture permissions were being reset after every build. Each time I compiled and ran the app from Xcode, I had to re-authorize screen capture in System Settings. CGPreflightScreenCaptureAccess() would return false even though I'd just granted permission minutes ago. Root cause: I was using ad-hoc code signing during development. macOS ties screen capture permissions to the app's code signing identity. With ad-hoc signing, the identity changes on every build, so the system treats each build as a "new" app. Solution: Switch to an Apple Development certificate for debug builds. In Xcode: Build Settings → Code Signing Identity → Debug → set to "Apple Development" Make sure your development team is selected After this change, the signing identity remains stable across builds, and screen capture permissions persist. This might be related to the broader issue discussed in this forum about ScreenCapture permissions disappearing — if other developers are seeing permissions vanish, it's worth checking whether the code signing identity is changing between sessions.

急需一个企业开发者证书，有意者可联系tg:@moonkf2025

All of my notarization submissions have been stuck at "In Progress" for up to 10 days. I have 6 submissions spanning from March 4 to March 11, 2026, and none of them have completed or returned any errors. Affected submissions: dbf20b57-0073-444a-b09a-ac6747b7398e (submitted Mar 4) — In Progress d5886683-be64-455c-805d-cd8b12bbcd35 (submitted Mar 4) — In Progress 10bfa709-da17-49cf-9c89-63f93b5fb756 (submitted Mar 4) — In Progress e8d0866e-43f8-4a18-8129-64e6c5d3895a (submitted Mar 9) — In Progress f9526f25-5650-4c45-98ae-d778c58a2ffa (submitted Mar 9) — In Progress 82ec211f-9179-41fd-afe0-937c9b2c2750 (submitted Mar 11) — In Progress Running `notarytool log` returns "Submission log is not yet available." Team ID: CB4U5M6U9H It is an Electron-based app built with electron-builder. Steps taken to ensure compliance: Signed with a valid Developer ID Application certificate Hardened runtime enabled (hardenedRuntime: true) Proper entitlements configured (com.apple.security.cs.allow-jit, com.apple.security.cs.allow-unsigned-executable-memory, com.apple.security.cs.disable-library-validation) Entitlements inherited for child processes via entitlements.mac.inherit.plist Electron Fuses configured to disable Node.js CLI flags in production (resetAdHocDarwinSignature enabled) App submitted as a zip archive via notarytool submit I've tried resubmitting multiple times across different builds, but all submissions remain stuck. I also have an open support case (102836201208) that was escalated to Senior Advisors on March 11, but have not received any update. Could someone from the notarization team please investigate?

This is my submission, my earliest submission has be stuck for a couple of days can someone please help. This is blocking our launch. -------------------------------------------------- createdDate: 2026-03-01T15:57:46.893Z id: 4cd9bb60-67eb-4f59-be9b-952248da33cf name: Snip-1.0.0-arm64.dmg status: In Progress -------------------------------------------------- createdDate: 2026-03-01T15:07:04.101Z id: fc88fa42-6ffe-4fee-86b2-0cec44c4391b name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-28T06:48:58.307Z id: e6cabf68-2963-4971-a057-fb4c5a1bdb4c name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T17:02:33.195Z id: 4e038aab-e429-4dfa-abcd-afcd49241a31 name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T17:02:21.907Z id: 4a908c50-812b-48c1-949d-8d6d4c9dec40 name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T14:28:38.585Z id: bccbc5bc-1cc7-4417-ab57-545b0cc6cc7b name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T08:35:47.185Z id: 4219d594-ee41-4905-8ea5-af89dc924b4f name: Snip.zip status: In Progress -------------------------------------------------- createdDate: 2026-02-27T08:07:51.982Z id: 08fce978-8dc1-45bb-aac1-ea932bd08b02 name: Snip.zip status: In Progress

Hi! I am encountering an issue with the notarization process. I'll leave here the outputs of a few command that I think might be useful. user@AndreisMac % pkgutil --check-signature mypkg.pkg Package "mypkg.pkg": Status: signed by a developer certificate issued by Apple for distribution Notarization: trusted by the Apple notary service Signed with a trusted timestamp on: 2026-02-18 18:46:16 +0000 Certificate Chain: ... user@AndreisMac % spctl -a -vv --type install mypkg.pkg mypkg.pkg: rejected origin=Developer ID Installer: MyComp LLC (ABCD) user@AndreisMac % xcrun notarytool submit mypkg.pkg --keychain-profile "notary-profile" --wait Conducting pre-submission checks for mypkg.pkg and initiating connection to the Apple notary service... Submission ID received id: e76f34b3-7c91-451c-a539-8fb39809a5bd Upload progress: 100,00% (13,3 MB of 13,3 MB) Successfully uploaded file id: e76f34b3-7c91-451c-a539-8fb39809a5bd path: /path/to/mypkg.pkg Waiting for processing to complete. Current status: Accepted............... Processing complete id: e76f34b3-7c91-451c-a539-8fb39809a5bd status: Accepted user@AndreisMac % spctl -a -vv --type install mypkg.pkg mypkg.pkg: rejected origin=Developer ID Installer: MyComp LLC (ABCD) As you can see: the installer is signed with a Developer ID Installer (the contents are signed and notarized as well) the first spctl check is failing(even if the installer was already notarized on our build server) trying to notarize again seems to work checking again still shows the installer as rejected I can run the installer locally by removing the quarantine flag, but this is not what I am expecting from a signed&notarized installer. Interestingly enough, trying this installer on a different MacOS machine works as expected(no quarantine) and spctl shows it as notarized(Accepted). Any idea what's wrong with my machine?

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!

Hi, I have two notarization submissions that have been stuck in "In Progress" status for several hours with no resolution. Submission IDs: 2158329b-8beb-400b-aa80-f8c2a5f30106 (submitted ~9 hours ago) 73174908-3ed9-4a85-afe0-a3c3b0722a61 (submitted ~3 hours ago) Both submissions show "In Progress" indefinitely and no log is available for either. The notarytool --wait --timeout 30m timed out on the second submission with exit code 124. The app is signed with a valid Developer ID Application certificate, all binaries including frameworks and dylibs are individually signed with --options runtime and --timestamp. A previous submission returned valid on disk / satisfies its Designated Requirement via spctl --assess. Could you please investigate whether these submissions are stuck on your end, and advise on next steps? Thank you.

Successfully received submission history. history ...... -------------------------------------------------- createdDate: 2025-10-19T18:34:47.472Z id: d3248896-7841-421e-9470-101df9d0da21 name: ... status: In Progress -------------------------------------------------- createdDate: 2025-10-19T18:12:45.325Z id: e5822fa0-5bcf-4610-81fc-9f541e8ad189 name: ... status: In Progress

I'm trying to notarize an application for the first time & it's stuck for more than 24 hours now. I ended up submitting the same app more than 5 times, but all are stuck in waiting state. There is no visibility into what's happening & whenever i check the status it just shows as "In Progress". How can i expedite this process ?

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.

base" : 6481543168, "size" : 5134811136, "uuid" : "7bc5af5f-1e86-3b36-9036-16025c72cb70" }, "vmSummary" : "ReadOnly portion of Libraries: Total=1.0G resident=0K(0%) swapped_out_or_unallocated=1.0G(100%)\nWritable regions: Total=28.8M written=369K(1%) resident=369K(1%) swapped_out=0K(0%) unallocated=28.5M(99%)\n\n VIRTUAL REGION \nREGION TYPE SIZE COUNT (non-coalesced) \n=========== ======= ======= \nActivity Tracing 256K 1 \nAttributeGraph Data 1024K 1 \nCoreAnimation 48K 3 \nDispatch continuations 6144K 1 \nFoundation 16K 1 \nKernel Alloc Once 32K 1 \nMALLOC 16.8M 10 \nMALLOC guard page 3760K 4 \nSTACK GUARD 64K 4 \nStack 2640K 4 \n__AUTH 3975K 362 \n__AUTH_CONST 60.1M 643 \n__CTF 824 1 \n__DATA 28.6M 604 \n__DATA_CONST 24.9M 650 \n__DATA_DIRTY 4800K 581 \n__FONT_DATA 2352 1 \n__INFO_FILTER 8 1 \n__LINKEDIT 188.3M 7 \n__OBJC_RO 84.3M 1 \n__OBJC_RW 3177K 1 \n__TEXT 839.6M 666 \n__TPRO_CONST 128K 2 \nmapped file 32.7M 3 \npage table in kernel 369K 1 \nshared memory 80K 4 \n=========== ======= ======= \nTOTAL 1.3G 3558 \n", "legacyInfo" : { "threadTriggered" : { "queue" : "com.apple.main-thread" } }, "logWritingSignature" : "96bc482de9d7d2e828b9b488a2feab6193d3c188", "bug_type" : "309", "roots_installed" : 0, "trmStatus" : 1, "trialInfo" : { "rollouts" : [ ], "experiments" : [

Hello, I'm currently developing an iOS app that uses SensorKit. Everything works fine in development and testing — the app correctly requests and receives SensorKit permissions on test devices. In my App ID configuration, the SensorKit Reader Access entitlement (com.apple.developer.sensorkit.reader.allow) is included and visible in Xcode under the project’s entitlements list. However, when I try to archive and distribute the app, I get the following errors in Xcode: Provisioning profile failed qualification Profile doesn't support SensorKit Reader Access. Provisioning profile failed qualification Profile doesn't include the com.apple.developer.sensorkit.reader.allow entitlement. Even though my provisioning profile includes this entitlement, Xcode still refuses to distribute the app. Here’s what I’ve confirmed so far: The provisioning profile lists com.apple.developer.sensorkit.reader.allow in its entitlements. SensorKit works perfectly in debug and development builds. The issue only occurs when attempting to distribute (Archive → Distribute App). Could this be because my account has only development entitlement for SensorKit and not the distribution entitlement? If so, how can I verify or request the proper distribution entitlement for SensorKit Reader Access? Thank you for any guidance or confirmation from Apple regarding this entitlement behavior.

When submitting my new build to app store connect directly from dreamflow, I get this error: Failed Step: Flutter build ipa and automatic versioning Building com.pinpictu for device (ios-release)... ════════════════════════════════════════════════════════════════════════════════ No valid code signing certificates were found You can connect to your Apple Developer account by signing in with your Apple ID in Xcode and create an iOS Development Certificate as well as a Provisioning Profile for your project by: 1- Open the Flutter project's Xcode target with open ios/Runner.xcworkspace 2- Select the 'Runner' project in the navigator then the 'Runner' target in the project settings 3- Make sure a 'Development Team' is selected under Signing & Capabilities > Team. You may need to: - Log in with your Apple ID in Xcode first - Ensure you have a valid unique Bundle ID - Register your device with your Apple Developer Account - Let Xcode automatically provision a profile for your app 4- Build or run your project again 5- Trust your newly created Development Certificate on your iOS device via Settings > General > Device Management > [your new certificate] > Trust For more information, please visit: https://developer.apple.com/library/content/documentation/IDEs/Conceptual/ AppDistributionGuide/MaintainingCertificates/MaintainingCertificates.html Or run on an iOS simulator without code signing ════════════════════════════════════════════════════════════════════════════════ No development certificates available to code sign app for device deployment Build failed :| Step 10 script Flutter build ipa and automatic versioning exited with status code 1 Please not I am on a windows pc, not a mac. I'm not sure how to clear this error and I am not an experinced coder, so any advice would be greatly appreciated, especially if it is simple and easy to follow.

Hello, Between April 20 and April 25 of this year, I submitted a request for the Family Controls Distribution entitlement through the following page: https://developer.apple.com/contact/request/family-controls-distribution After submitting the request, I clearly saw the message: “Thank you for your submission. We’ll review your request and contact you soon with a status update.” However, I have not received any further update or feedback since then. Afterward, I contacted Apple multiple times regarding this issue through Case ID: 102881595688. Unfortunately, the responses I received consistently indicated that the relevant teams were unable to check the status or progress of the entitlement request, and no clear timeline or follow-up commitment was provided. Eventually, I was informed via email that the issue had already been escalated to the operations team for handling. However, many more days have now passed without any progress or update. At this point, it has been nearly one month since I submitted the entitlement request, yet I still have not received any result, status update, or meaningful feedback. I genuinely do not understand why the tracking and communication process for this entitlement request is so unclear and slow. I would sincerely appreciate it if the relevant team could provide a clear update regarding the current status of my request and the expected next steps. Thank you.

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?

I am making an iOS step counting app and I have included a widget in the design. I would like to get the widget to pull data from the main app to display step count etc so I created a bundle id for the widget and have been trying to use a group id to link them together. The group capabilities for both seem to be set up/enabled properly with the same App Groups id, but I've been getting an error in xcode which says, " 'Provisioning Profile: "BUNDLE_ID" doesn't include the com.apple.developer.security.application-groups entitlement.' Try Again But the identifiers do have the App Group id enabled. I have tried automatic signing, manual signing with generated profiles, unchecking and rechecking auto-signing, removing and re-adding the group capability. Creating a new bundle id from scratch, creating a new group id from scratch. Always I get the error. I've really pulled my hair out troubleshooting this and would appreciate support. I'm happy to answer and questions or share details. Thank you.

Hi, I’m requesting investigation of two CtxVault notarization submissions that have remained "In Progress" well past 24 hours. Team ID: DCY4ZS6CS6 App / archive: CtxVault.zip Platform: macOS direct distribution Pending submissions: e2f25e8c-8bf6-44e6-8e60-24b22467b7e6 — created 2026-04-22T12:50:04.988Z — still In Progress 1f41ff2d-cf61-4509-beba-3389f4496ba7 — created 2026-04-22T12:40:23.167Z — still In Progress Context: This is a new Developer ID release path for a personal team. Earlier submissions were Invalid due to unsigned nested Mach-O files inside a bundled Python runtime. That issue was corrected before the two pending submissions above. The current app is signed with Developer ID Application, hardened runtime, and secure timestamps. Local validation passes: codesign --verify --deep --strict spctl assessment on the signed app notarytool accepts the upload and returns submission IDs, but the submissions do not complete and no log is yet available. Earlier invalid submission for context: b4e665a0-98eb-4b92-b44c-58a0a2c6122e Could someone from Apple please confirm whether this team is stuck in queue or under extended review, and whether any team-side provisioning or backend action is needed? I am intentionally not creating more duplicate submissions while these corrected jobs remain pending. Thanks.