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.

Hi everyone, I'm following up on this post I made earlier about an issue I'm having with FamilyControls and the DeviceActivityMonitor extension not working for external TestFlight testers. To briefly recap: I have official Apple approval for the com.apple.developer.family-controls entitlement (distribution) The entitlement is added to both my main app and the DeviceActivityMonitor extension The App Group is correctly configured for both targets On internal TestFlight builds, everything works as expected: app blocking works, the extension runs, and selected apps are shielded. On external TestFlight builds, users get the Screen Time permission prompt, can select apps to block, but nothing is blocked. Since that post, I submitted a Code Level Support request, and Apple asked me to file a bug report via Feedback Assistant. I did that almost a month ago. The only reply I’ve received since is that they can’t give a timeframe or guarantee it will be resolved. I'm stuck in limbo with no updates and no fix. This feature is critical to my app and I cannot launch without it. I’ve reached out to other developers who use app blocking, and none of them have run into this issue. My setup seems correct, and Apple has not said otherwise. If anyone has experienced something similar, found a workaround, or knows how to get real movement on a bug report like this, I would really appreciate any help. It’s been weeks, and I just want to launch my app. Thanks so much.

Hi Apple team, I have a recently created dev account and submitted two different 20-30 mb .apps for notary through the notary tool. I have read that this should only take minutes at this size of an app but both have been stuck in progress for almost 24+ hours. Below are the UUIDs of the notary submissions. Also I tried re-submitting but these are also stuck in progress. Successfully received submission history. history -------------------------------------------------- createdDate: 2025-09-26T11:46:32.643Z id: 9714758e-e216-496d-80f8-422f77011ebe name: <>.zip status: In Progress -------------------------------------------------- createdDate: 2025-09-25T21:48:46.161Z id: c2a81300-c903-4277-8ef3-70205a690c76 name: <>.zip status: In Progress -------------------------------------------------- createdDate: 2025-09-25T18:24:36.205Z id: 42742be1-c7e5-4483-a2c5-95e89086d070 name: <>.zip status: In Progress -------------------------------------------------- createdDate: 2025-09-25T16:35:09.059Z id: a404256e-40c2-4dca-97fc-983e70ea4b7b name: <>.zip status: In Progress

Its just stuck in progress. $ xcrun notarytool history --keychain-profile X Successfully received submission history. history -------------------------------------------------- createdDate: 2025-07-21T16:46:13.233Z id: X name: X.dmg status: In Progress -------------------------------------------------- createdDate: 2025-07-20T18:44:35.683Z id: X name: X.dmg status: In Progress -------------------------------------------------- createdDate: 2025-07-20T11:24:20.319Z id: X name: X.dmg status: In Progress Its a go app; not simple but not very complicated. It is my first time notarising but even then should it take this long?? 3 days is ridiculous!

mac .cer证书不能导出.p12证书 不知道那个步骤出错

Hello everyone. I have a simple doubt, I receive an email informing that the Apple Distribution certificate will expire. I create one new in the Developer portal with one year duration. My doubt is, I need to do something more like open again the app in Xcode, insert new certificate and build it again, send to apple and everything? Or just creating this certification is enough? Is possible to increase this certification time or auto renew? Thank you!!!

Hi everyone, I'm working with a third party to integrate their USB driver into our app and I'm wondering if iPadOS supports bundling a prebuilt .systemextension file with the entitlement com.apple.developer.system-extension.redistributable into our app that has the com.apple.developer.driverkit.communicates-with-drivers entitlement? If not, is there a way to bundle a third party USB driver into our iPad app?

Yesterday there were reported outages on the Developer ID Notary Service, but it was reported pretty late and we were able to notice the outages in real time. It says resolved now, however an error still persists: Error: HTTP status code: 403. A required agreement is missing or has expired. This request requires an in-effect agreement that has not been signed or has expired. Ensure your team has signed the necessary legal agreements and that they are not expired. Is there an ongoing outage at this moment that is not being reported again? Our pipelines have been working flawlessly for months without intervention nor changes until the most recent outages

Tried notarizing my app yesterday afternoon via Mac terminal, and when I came back to work this morning it was still "In Process...". I closed terminal, and checked appleid.apple.com, and it was asking me to reset my password- maybe because the notarization timed out? Either way, I reset my password, generated a new app-specific password and tried notarizing the app again, but it's now been 3 hours and it's still "In Process..." again. When I check the status via terminal, nothing seems off- and the status is In Progress. How can I determine if there's a bigger issue I need to fix before notarizing? UUID: e7ae29c8-2478-41a3-93b4-3f274de643d0

I have a macOS application that was previously distributed under my personal Apple Developer account using a Developer ID certificate. We’ve recently transitioned distribution to our company’s Apple Developer account. The app’s bundle identifier has been successfully transferred, and I’ve signed a new build of the app using the company’s Developer ID certificate. The app installs and runs correctly under the new signature. However, I’ve encountered a problem: the app is no longer able to access previously granted permissions (e.g., Screen Recording, System Audio Recording, and Input Monitoring). Furthermore, it cannot re-prompt for these permissions because they appear as already granted in System Settings. From what I understand, this issue is due to the change in the code signing identity. Specifically, the designated requirements used by macOS to identify an app have changed, so the system no longer associates the new version of the app with the previously granted permissions (as outlined in Apple's Technical Note TN3127). The only workaround I’ve found so far is to manually reset the app's permissions using Terminal commands (e.g., tccutil reset), but this is not something we can reasonably ask end users to do. Question: Is there a recommended or supported approach to either preserve permissions when changing Developer ID identities, or programmatically trigger a permissions reset for existing users? We're looking for a seamless solution that doesn't degrade user experience.

This math-educational 3D-graphics courseware utilizes Java3D, which sits on top of hardware-dependent JOGAMP binaries (which instruct at the GPU-level). This code signing command applied to the installer .dmg: codesign -s "myName" --force --options runtime ~/DFG2D_MacOS_Manufacturing/MacOSInstallers/DFG2D_Mac_J1602_x86/DataflowGeometry2D-1.0.300.dmg is supposed to force signing of all the embedded binaries, BUT the notary tool finds about 25 jogamp-fat dynamic libraries (/ *.dylib) UNSIGNED. Processing complete id: 23d81a99-4087-48d2-a567-8072dd2820fe status: Invalid pierrebierre@Pierres-iMac ~ % xcrun notarytool log 17d2fe94-f38a-47d4-9568-cf4dc65f24c9 --apple-id "xxxxxxxxxxx" --team-id "XXXXXXXXX" --password pwpwpwpwpw { "logFormatVersion": 1, "jobId": "17d2fe94-f38a-47d4-9568-cf4dc65f24c9", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "DataflowGeometry2D-1.0.300.dmg", "uploadDate": "2025-07-13T21:28:21.147Z", "sha256": "57320c4ad4a07f144336084152bf7e3328f8c5694dd568d2cfd23a596b5b3b13", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "DataflowGeometry2D-1.0.300.dmg/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_300.jar/lib/jogamp-fat/jogamp-fat.jar/natives/macosx-universal/libnativewindow_awt.dylib", "message": "The binary is not signed.", "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087721", "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "DataflowGeometry2D-1.0.300.dmg/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_300.jar/lib/jogamp-fat/jogamp-fat.jar/natives/macosx-universal/libnativewindow_awt.dylib", "message": "The signature does not include a secure timestamp.", "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087733", "architecture": "x86_64" }, What is your advice on how to get these binaries signed?

我没有勾选entitlements 中的” com.apple.security.network.server“和” com.apple.security.device.usb“，但是确实在打包时又自动出现在包里，我现在无法解决这个问题，我需要帮助，谢谢 我的.entitlements 文件如下： 排查命令： codesign -d --entitlements :- ./Device\ Guard.app Executable=/Users/zhanghai/Library/Developer/Xcode/DerivedData/MacGuardApp-fvfnspyxcojxojdfclyohrnupgsh/Build/Products/Debug/Device Guard.app/Contents/MacOS/Device Guard warning: Specifying ':' in the path is deprecated and will not work in a future release

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 distributing a macOS application outside the App Store using Developer ID and need to provide provisioning profiles to customers for installation during the package installation process. I have two questions: How can I package and provide the provisioning profile(s) so that the customer can install them easily during the application installation process? Are there any best practices or tools that could simplify this step? In my case, there are multiple provisioning profiles. Should I instruct the customer to install each profile one by one, or is there a way to combine them and have them installed all at once? Any insights, resources, or recommendations would be greatly appreciated.

Hello, I'm currently trying to upload a new version of an existing application. But each time I try to validate the archive of the application, I got the following error in Xcode (v16.2) : Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “37CG5MY799.com.example.app” value for the com.apple.application-identifier key in “com.example.app.pkg/Payload/app.app/Contents/MacOS/app” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID. I suspect that there is a problem with the App ID Prefix (that is 37CG5MY799 for the app) when our team ID is E4R7RJ7LA3 but I cannot find a solution. I asked the Apple Developer Support for help and I have read the documentation they sent but it couldn't solve this problem so they redirected me to the forums. https://developer.apple.com/library/archive/qa/qa1879/_index.html https://developer.apple.com/library/archive/technotes/tn2318/_index.html#//apple_ref/doc/uid/DTS40013777-CH1-OVERVIEW https://developer.apple.com/library/archive/technotes/tn2318/_index.html#//apple_ref/doc/uid/DTS40013777-CH1-TNTAG33 There isn't any obvious App ID Prefix mismatch in the entitlement between the Application's signature entitlement and the Embedded provisioning profile entitlement . Application's signature entitlement : <dict> <key>com.apple.application-identifier</key> <string>37CG5MY799.com.example.app</string> <key>com.apple.developer.team-identifier</key> <string>E4R7RJ7LA3</string> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.app</string> </array> <key>com.apple.security.files.user-selected.read-only</key> <true/> </dict> Embedded provisioning profile entitlement : <dict> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.app</string> <string>E4R7RJ7LA3.*</string> </array> <key>com.apple.application-identifier</key> <string>37CG5MY799.com.example.app</string> <key>keychain-access-groups</key> <array> <string>37CG5MY799.*</string> </array> <key>com.apple.developer.team-identifier</key> <string>E4R7RJ7LA3</string> </dict> The app also have a browser extension that correctly use the Team ID. How to solve this problem ? Thanks for your time, Qeg

Hi Apple Developer Community, I'm trying to resolve the following Xcode build error: *"Provisioning profile 'iOS Team Provisioning Profile: ' doesn't include the com.apple.developer.live-activities entitlement." To fix this, I understand I need to add the Live Activity capability to my App ID and ensure it’s included in the provisioning profile. However, when I go to Certificates, Identifiers & Profiles, select my App ID, and click Edit under "App ID Configuration," the Live Activity capability is not available in the list of capabilities. As a result, I can’t proceed with enabling the entitlement or regenerating a correct provisioning profile. I’ve confirmed: My App ID is explicit (not a wildcard). The app’s deployment target is set to iOS 16.1 or later. I’m signed in with the correct Apple Developer Team account. etc. Has anyone experienced this? Is there a prerequisite that I might be missing? Thanks in advance for your help! Best regards, David Winograd Rokfin, Inc.

I made a macOS application using Swift Package and distributed it in dmg format through Apple Notary service. However, we received a report from a user that it can be launched from a disk image mounted from dmg, but when copied to /Applications, the app is broken and does not start. I looked into why this happened, I noticed that the codesign command returned different results when copying the application bundle and /Applications on the volume mounted dmg with Finder. Mounted dmg: OK ❯ codesign --verify --deep --verbose /Volumes/azoo-key-skkserv/azoo-key-skkserv.app /Volumes/azoo-key-skkserv/azoo-key-skkserv.app: valid on disk /Volumes/azoo-key-skkserv/azoo-key-skkserv.app: satisfies its Designated Requirement Copied by Finder: Bad codesign reports that there are 148 added/missing files. ❯ codesign --verify --deep --verbose /Applications/azoo-key-skkserv.app /Applications/azoo-key-skkserv.app: a sealed resource is missing or invalid file added: /Applications/azoo-key-skkserv.app/Contents/Resources/AzooKeyKanakanjiConverter_KanaKanjiConverterModuleWithDefaultDictionary.bundle/Contents/Resources/Dictionary/louds/グ1.loudstxt3 (skip...) file missing: /Applications/azoo-key-skkserv.app/Contents/Resources/AzooKeyKanakanjiConverter_KanaKanjiConverterModuleWithDefaultDictionary.bundle/Contents/Resources/Dictionary/louds/グ1.loudstxt3 (skip...) Copied by ditto: OK ❯ ditto /Volumes/azoo-key-skkserv/azoo-key-skkserv.app /Applications/azoo-key-skkserv.app ❯ codesign --verify --deep --verbose /Applications/azoo-key-skkserv.app /Applications/azoo-key-skkserv.app: valid on disk /Applications/azoo-key-skkserv.app: satisfies its Designated Requirement I made a simple macOS application to explain this problem in an easy-to-understand way. You can download dmg in github releases, mount dmg, copy it in the Finder, and check if there is a problem by running the codesign command. https://github.com/mtgto/example-utf8-mac-notarization As a result, I learned the following two things. Occurs only with resources with file names whose values change due to NFC/NFD normalization No problems occur with the resources of the application itself. Generated by the Swift Package resources that the application depends on I think this is a problem with Finder or Gatekeeper.

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?

Greetings! I've notarized my app but it spends always over 1 hour. I think it's because the app size is about 30GB, but is there any way to reduce it?

Hello, I have a macOS app built with Flutter’s macOS target (native Xcode project). The app is unsigned (no Developer ID code signing / notarization). The .app bundle looks valid: CFBundlePackageType = APPL Unique CFBundleIdentifier No LSUIElement or LSBackgroundOnly Executable exists and is runnable Placed at /Applications/MyApp.app (top-level), runs fine from Finder However, it does not show up in Launchpad. What I tried: Remove quarantine: xattr -dr com.apple.quarantine "/Applications/MyApp.app" Force Launch Services registration: /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f "/Applications/MyApp.app" Rebuild LS caches: /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user Reset Launchpad DB and restart Dock: defaults write com.apple.dock ResetLaunchPad -bool true && killall Dock Verified bundle structure/type: mdls -name kMDItemContentType -name kMDItemKind "/Applications/MyApp.app" → shows com.apple.application-bundle / Application Questions Is code signing/notarization required for an app to appear in Launchpad (even if it runs from Finder)? What additional conditions cause Launchpad to skip an otherwise valid, unsigned .app in /Applications? Are there deeper Launch Services or Dock database checks I can run to diagnose why this specific app is excluded?