General: Forums topic: Code Signing Forums subtopics: Code Signing > General, Code Signing > Certificates, Identifiers & Profiles, Code Signing > Notarization, Code Signing > Entitlements Forums tags: Code Signing, Signing Certificates, Provisioning Profiles, Entitlements Developer Account Help — This document is good in general but, in particular, the Reference section is chock-full of useful information, including the names and purposes of all certificate types issued by Apple Developer web site, tables of which capabilities are supported by which distribution models on iOS and macOS, and information on how to use managed capabilities. Developer > Support > Certificates covers some important policy issues Bundle Resources > Entitlements documentation TN3125 Inside Code Signing: Provisioning Profiles — This includes links to the other technotes in the Inside Code Signing series. WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing Certificate Signing Requests Explained forums post --deep Considered Harmful forums post Don’t Run App Store Distribution-Signed Code forums post Resolving errSecInternalComponent errors during code signing forums post Finding a Capability’s Distribution Restrictions forums post Signing code with a hardware-based code-signing identity forums post New Capabilities Request Tab in Certificates, Identifiers & Profiles forums post Isolating Code Signing Problems from Build Problems forums post Investigating Third-Party IDE Code-Signing Problems forums post Determining if an entitlement is real forums post Code Signing Identifiers Explained forums post Mac code signing: Forums tag: Developer ID Creating distribution-signed code for macOS documentation Packaging Mac software for distribution documentation Placing Content in a Bundle documentation Embedding nonstandard code structures in a bundle documentation Embedding a command-line tool in a sandboxed app documentation Signing a daemon with a restricted entitlement documentation Defining launch environment and library constraints documentation WWDC 2023 Session 10266 Protect your Mac app with environment constraints TN2206 macOS Code Signing In Depth archived technote — This doc has mostly been replaced by the other resources linked to here but it still contains a few unique tidbits and it’s a great historical reference. Manual Code Signing Example forums post The Care and Feeding of Developer ID forums post TestFlight, Provisioning Profiles, and the Mac App Store forums post For problems with notarisation, see Notarisation Resources. For problems with the trusted execution system, including Gatekeeper, see Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

M4 Mac Mini: Xcode generates private keys with wrong label - codesigning impossible Background This is a follow up to my November 2024 thread "Keychain issues after installing backup on new Mac" which was closed because I had a temporary workaround. That workaround using my wife's MacBook Air for signing is not sustainable. I used AI assistance to determine the root cause. My DTS case 102877839447 is open but has not yet been forwarded to a DTS engineer. Environment Mac Mini M4, macOS 15.4.1 (Build 25E253) Xcode 26.4.1 (17E202) Team ID: Q23726668V (Computerade Products) Working comparison machine: MacBook Air, macOS 15.3 Precise Bug — Reproducible Every Time Every time Xcode generates a new certificate and key pair on my Mac Mini: Certificate: Apple Development: Michael Birch (9KD5TCGGHG) ✅ Private key: Apple Development: Michael Birch (Computerade Products) ❌ The key uses the organization name instead of the certificate identifier. They never pair as a valid codesigning identity. security find-identity -v -p codesigning always returns 0 valid identities. Cryptographic Evidence The internal application labels confirm the keys are cryptographically unrelated to their certificates: Key internal application label: 53C26EB056997276B5E938258D00665ACABD1F0F Certificate public key hash: 57cd1af4a9162f26b1a6d750e05a63a2166b75ff These do not match ❌ Confirmed Eliminated As Causes Keychain search list corruption — found and fixed Partition list — set correctly Access control — set to allow all applications Full Disk Access — granted to Xcode Xcode caches and preferences — completely cleared Login keychain — completely reset Orphaned certificates and keys — all removed SIP enabled, system fully up to date Valid P12 Import Also Fails A p12 exported from the working MacBook Air and cryptographically verified as a matched pair also fails on the Mac Mini: security import returns MAC verification failed Keychain Access import returns OSStatus -2 Importing certificate and key separately as PEM files succeeds but they are not recognized as a valid identity pair despite matching application labels A3F3F193B7896DA9055353F59AB450778CB09AE7 Question Is there a known issue with M4 Mac Mini keychain infrastructure where private keys are generated with incorrect internal application labels? Is there a lower level diagnostic or fix beyond what the security command provides? The problem is specific to my Mac Mini M4 and persisted thru more than a year of Mac OS and xCode updates.

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 IMPORTANT When investigating code signing problems, don’t use sudo to run commands as root. This is a common source of confusion. I explain why in Resolving errSecInternalComponent errors during code signing. 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 2026-07-02 Added a warning not to run tests using sudo. 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.

Two months ago we got approval for using the Notification Filtering entitlement. We rushed out to implement it in our app, only to find out that the permission was set for the wrong bundle identifier. We expected to get the permission for the notification extension's bundle identifier, yet it is added for the main app's bundle identifier. Per the official docs, the entitlement permission should be in the notification service extension target: After you receive permission to use the entitlement, add com.apple.developer.usernotifications.filtering to the entitlements file in the Notification Service Extension target. However, this fails to get signed when compiling for non-simulator targets because of the bundle mismatch issue. Simulator perfectly filters notifications. Adding the entitlement to the main app does compile, but filtering does not work (as expected). We reached out to Apple twice (Case-ID: 14330583) but we have yet to receive any response. Could there be something else wrong instead of the identifier mismatch?

Xcode 27 creates a placeholder for the bundle identifier of a new project. devplaceholder.$(PROJECT_UNIQUE_VALUE:identifier).$(PRODUCT_NAME:identifier) I have two questions. Is it enough to change the bundle id from the Signing & Capabilities panel or do we need to change it somewhere else? What are Apple recommendations? Should we only replace the devplaceholder value and keep the unique value and product name, provide our won id but keep the product name, or replace everything with our own bundle ID? Thanks

I work for a company which develops as part of our product suite a System Extension implementing an Endpoint Security client. Our local developer workflow for testing and validating changes is to build locally with Developer certificates (not a legitimate/production Developer ID certificate) and deploy local builds in to a VM, where to get the System Extension to load and be accepted we need to disable SIP & AMFI. macOS 27 VM is refusing to allow me to disable SIP. Is there an alternate approach we can use for this workflow to allow macOS VMs to accept our software when signing with a (same teamID, but different certificate to the provisioningprofile) developer certificate for local validation?

We are facing following message "A timestamp was expected but was not found" during codesign for following .dylib and .pkg and it cause notarization process failed. We are facing this issue for last 3 days and we have access for timestamp.apple.com and 17.0.0.0/8 and we didn't change firewall settings. We are facing this issue randomly and not for all time(scenario is 3:1). We tried the below command to sign the package, codesign --verbose --deep --force --timestamp --options=runtime --sign "<CODE SIGN IDENTITY>" <TO BE SIGNED PACAKGE> Kindly let us know how to fix this probelm.

Hello, I have been unable to install any development-signed app on any physical device for five months. Builds succeed, code signing passes locally, but every device rejects the app at install time with: Failed to verify code signature of .../extracted/MyApp.app : 0xe8008018 (The identity used to sign the executable is no longer valid.) ApplicationVerificationFailed The app installs briefly, then iOS immediately removes it. This started right after my account (Team ID MB4DXDTDMT) was reinstated following a duplicate-account flag. Background: I had a personal account that was converted to a business account (Wakeout LLC), then created a new personal account, which Apple flagged as a duplicate and later reinstated. The signing failure began immediately after that reinstatement. Isolation already done (this is not a local-setup problem) I have run the full isolation sequence — including every step DTS typically asks for — and the result points squarely at the account/team, not my machine: New blank Xcode project, automatic signing, new bundle ID → same 0xe8008018. Brand-new macOS user account → same failure. Multiple Macs, fresh Xcode installs → same failure. Multiple iOS devices (iPhone 17 Pro, iPhone 15 Pro, others) → same failure. Different Apple ID / different developer team on the same Mac + same device → installs fine. This is the decisive one: the local environment is healthy; only Team MB4DXDTDMT is rejected. Xcode Cloud builds for this same team install fine. Apple's cloud signing trusts MB4DXDTDMT; the device-verification backend does not. That gap can only exist server-side. I have also: revoked/regenerated all certificates multiple times, deleted/recreated all provisioning profiles, cleared ~/Library/MobileDevice/Provisioning Profiles, cleared DerivedData and CoreDevice, removed device pairing records, re-paired devices, confirmed Developer Mode and correct system time. Simulators work. codesign --verify --deep --strict passes. Profile certificate SHA-1 matches the signing cert exactly. Entitlements match. Why I'm posting here This is the same failure documented in thread 755762, where Quinn concluded: "this seems to be tied to your primary developer account and only DevPrograms has access to those details." That matches my evidence exactly: the problem isolates cleanly to one team, and only DevPrograms can see the account-side state. I've already gone through Developer Support on this — an open case has been with them for about five months without a resolution, which is what convinced me the fix isn't something I can reach from the support side. I'm posting here in case a DTS engineer can confirm the diagnosis and point me to the right path. Question for any DTS engineer: given that the failure isolates to a single team — different teams sign and install fine on the same Mac and same device, and Xcode Cloud builds for this same team install fine — can you confirm this is an account-side signing-trust state that has to be reset by Apple, and what's the most direct way to get that reset actioned? Happy to attach a sysdiagnose, full console output, or codesign -dvvv dumps on request. Thank you.

I've been trying to notarize an installer (.pkg file) on a new laptop. Previous versions have been notarized successfully on a previous Mac. However, in spite of having the required certificates (same as the old Mac, generated for the new Mac) the submission gets stuck at "In Progress". Doing it multiple times (even hours apart) doesn't help. Is there a FAQ / suggested list of steps to help resolve this issue? Here's what I see: xcrun notarytool history --keychain-profile "(my profile name)" results in (problem started with v4, the first version I've tried on this new Mac): createdDate: 2023-10-17T01:34:36.911Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v4.pkg status: In Progress -------------------------------------------------- createdDate: 2023-10-17T01:33:59.191Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v4.pkg status: In Progress -------------------------------------------------- createdDate: 2023-10-16T21:01:25.832Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v4.pkg status: In Progress -------------------------------------------------- createdDate: 2023-10-16T19:57:44.776Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v4.pkg status: In Progress -------------------------------------------------- createdDate: 2023-10-02T14:17:34.108Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v3.pkg status: Accepted -------------------------------------------------- createdDate: 2023-09-28T14:04:46.211Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v2.pkg status: Accepted -------------------------------------------------- createdDate: 2023-09-20T17:28:46.168Z id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx name: xxxxxxxxxx-v1.pkg status: Accepted -------------------------------------------------- xcrun notarytool log xxxxxxxxxxxxxxxxxxxx --keychain-profile "(my profile name)" results in: Submission log is not yet available or submissionId does not exist id: xxxxxxxxxxxxxxxxxxxxxxxx

macOS allows you to directly distribute a Network Extension using Developer ID signing, but with an important wrinkle. This post explains that wrinkle, its affect on Xcode, and how you get around it. If you have questions or comments, start a new thread here on the forums. Put it in the App & System Services > Networking and tag it with Network Extension. That way I’ll be sure to see it go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Exporting a Developer ID Network Extension macOS supports a variety of Network Extension (NE) provider types. Starting with macOS 10.15, it’s possible to distribute an app containing NE providers directly, using Developer ID signing. See TN3134 Network Extension provider deployment for the full list of supported provider types. For your NE provider to work when distributed directly, it must: Be packaged as a system extension. Use Developer ID specific entitlements This post is focused on that second point, because it’s a common source of confusion. Note If you’re currently shipping an app extension and you want to move to a system extension, see Network Extension Provider Packaging. This post assumes that you’re building your app with Xcode; if you’re building your app outside of Xcode, you’ll have to adapt these steps to your build system. Entitlement Matters A Network Extension system extension and its container app must be signed with the Network Extension entitlement (com.apple.developer.networking.networkextension). That entitlement is an array, with a variety of different element values based on the provider type. For example, a standard NE content filter provider must include the content-filter-provider value. There are two groups of these values: the standard ones and the ones with the -systemextension suffix. During development and for App Store distribution, use the appropriate standard value. For direct distribution using Developer ID, use the corresponding value with the -systemextension suffix. For example, a Developer ID signed NE content filter must use content-filter-provider-systemextension instead of content-filter-provider. Xcode Issues IMPORTANT Xcode 27.0b1 is reported to have fixed this issue, meaning that it should now be possible to export a Developer ID signed app with an Network Extension system extension from the Xcode organiser. I did some basic tests of that here in my office and it seems to work. Yay! So the following is only relevant if you have to build your app with an earlier version of Xcode. Xcode 26 and earlier are not aware of this requirement. If you build your NE provider container app using Xcode, you might expect to export it for direct distribution using the Direct Distribution workflow in the Xcode organiser. This does not work on older versions of Xcode (r. 108838909). To get around this, manually export your app from your Xcode archive. Before attempting that, there are a few things to confirm: By default Xcode’s Signing & Capabilities editor uses the standard values for the NE entitlement. Leave them that way. During day-to-day development it’s best to use an Apple Development signing identity [1], and the standard values work with that. Continue to use Build > Archive [2] to create an Xcode archive for your product. The steps below replace the Direct Distribution workflow, and they assume you’re starting with an Xcode archive. Note For hints and tips about how to bring up and then debug an NE provider, see Debugging a Network Extension Provider. [1] Don’t use Developer ID for day-to-day development; see The Care and Feeding of Developer ID for more on that topic. [2] Or, if you’re automating this, the archive action in xcodebuild. Assemble Your Assets Imagine you’re working on a content filter for the Mac called WaffleFilter. You’ve used Xcode to build the app into an Xcode archive: % ls "WaffleFilter.xcarchive/Products/Applications" WaffleFilter.app That app is development signed: % codesign -d -vvv "WaffleFilter.xcarchive/Products/Applications/WaffleFilter.app" … Authority=Apple Development: … … IMPORTANT The steps in this section are based on the much more comprehensive instructions in Creating distribution-signed code for macOS. If anything is unclear, read that documentation for clarification. To re-sign this app for direct distribution you’ll need three things: A Developer ID application signing identity. This is named Developer ID Application: TTT, where TTT identifies your team. A Developer ID provisioning profile for the app. In this example I’ve called this WaffleFilter_Dev_ID.provisionprofile. A Developer ID provisioning profile for the system extension. In this example I’ve named this WaffleFilter_WFProvider_DevID.provisionprofile. If you’re not sure how to create these things, see Developer Account Help. Re-sign the App To start, make a copy of the app: % ditto "WaffleFilter.xcarchive/Products/Applications/WaffleFilter.app" "WaffleFilter.app" Dump the entitlements of the app and its embedded system extension: % codesign -d --entitlements "WaffleFilter.entitlements" --xml "WaffleFilter.app" % codesign -d --entitlements "WaffleFilter_WFProvider.entitlements" --xml "WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension" And reformat them to make them more readable: % plutil -convert xml1 "WaffleFilter.entitlements" % plutil -convert xml1 "WaffleFilter_WFProvider.entitlements" Now edit these files to add the -systemextension suffix. The result will look something like this: % cat "WaffleFilter.entitlements" … <dict> … <key>com.apple.developer.networking.networkextension</key> <array> <string>content-filter-provider-systemextension</string> </array> … </dict> </plist> % cat "WaffleFilter_WFProvider.entitlements" … <dict> … <key>com.apple.developer.networking.networkextension</key> <array> <string>content-filter-provider-systemextension</string> </array> … </dict> </plist> Before you re-sign with these entitlements, replace the embedded provisioning profiles with their Developer ID variants: % cp "WaffleFilter_Dev_ID.provisionprofile" "WaffleFilter.app/Contents/embedded.provisionprofile" % cp "WaffleFilter_WFProvider_DevID.provisionprofile" "WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension/Contents/embedded.provisionprofile" Now re-sign the app and the system extension with their new entitlements, from the inside out: % codesign -s "Developer ID Application" -f --entitlements "WaffleFilter_WFProvider.entitlements" --timestamp -o runtime "WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension" WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension: replacing existing signature % codesign -s "Developer ID Application" -f --entitlements "WaffleFilter.entitlements" --timestamp -o runtime "WaffleFilter.app" WaffleFilter.app: replacing existing signature If you have multiple Developer ID Application signing identities, you’ll need to replace Developer ID Application with the name of the specific identity you want to use. IMPORTANT If your app contains other code items, like frameworks or an app extension, re-sign those as well. For advice on how to manually re-sign a more complex app, see Creating distribution-signed code for macOS. And you’re done! Manually Notarise Xcode’s Direct Distribution workflow also deals with notarisation. As you’re not using that workflow, manually notarise your app. For advice on how to do that, see Customizing the notarization workflow. You should also look at Packaging Mac Software for Distribution, which has a bunch of general info about packaging Mac apps. Revision History 2026-06-22 Xcode 27.0b1 is reported to have fixed this issue. Added information about that. Made other minor editorial changes. 2023-09-21 First posted.

Hello. I am developing our company's SDK for iOS as a third-party library. This SDK consists of a static library and header files wrapped within a framework (and wrapping the target-specific frameworks in xcframework). I understand that codesign is required even for static frameworks, is it correct? Should I update the distributed files when the certificate expires? Does this depend on whether it is static or dynamic? When is the signature verified?

i'am still getting crash while testing dotnetmaui my app, here is my environment info and crash report @shanselman macOS Tahoe 26.5, macOS Rider 2026.1.2 dotnet workload list Workload version: 10.0.300.3 Installed Workload Id Manifest Version Installation Source ios 26.5.10284/10.0.100 SDK 10.0.300 maccatalyst 26.5.10284/10.0.100 SDK 10.0.300 maui-android 10.0.20/10.0.100 SDK 10.0.300 maui-ios 10.0.20/10.0.100 SDK 10.0.300 xcodebuild -version Xcode 26.5 Build version 17F42 crash-report.txt

Hi, I recently enrolled in the Apple Developer Program and I’m trying to notarize my first Developer ID apps for distribution outside the Mac App Store. All of my valid notarization submissions are stuck in “In Progress”. The oldest one has been stuck since 2026-06-03, and newer submissions are stuck too. None of the valid submissions have moved to Accepted or Invalid, and no log is available. Team ID: TP32Y96XC5 Feedback Assistant: FB22994785 https://feedbackassistant.apple.com/feedback/22994785 Oldest stuck submission: 07865316-b2e0-4529-9790-97a63746d9a9 Hello Developer ID Test.dmg Created: 2026-06-03T12:20:18.595Z Status: In Progress This also happens with other apps/artifacts, so it seems like it may be account-level or team-level rather than an issue with one specific build. Other stuck submissions include: f1574597-154e-4386-a0b1-5560a57dde9d Azad IDE.zip Created: 2026-06-03T23:40:55.335Z aab15661-a883-413a-8a5d-8c78d1d0dabb Azad IDE.zip Created: 2026-06-05T11:29:46.664Z df4bb6dd-38fc-4083-92fa-d0846037fd53 MyMacOSApp-0.1.1-Darwin.dmg Created: 2026-06-05T11:52:54.093Z 305d56b7-a66a-4881-b649-c8738e39f3f2 Azad IDE.zip Created: 2026-06-08T10:58:24.724Z 1947d3c3-fc84-4479-9bee-355c16d51670 Azad IDE.zip Created: 2026-06-08T11:19:58.848Z What I checked: Developer ID certificate is installed and valid. The apps are signed with Developer ID Application: Matan Nahmani (TP32Y96XC5). codesign verification passes locally. Hardened runtime is enabled. notarytool authentication works. notarytool history/info works. notarytool log says the submission log is not yet available for the stuck submissions. I have not received a rejection email for the stuck submissions. Apple Developer System Status shows the notary service as available. Note: I do have one Invalid submission, but that one was intentional. I created it as a negative-control test while following a notarytool tutorial, to confirm that invalid submissions can produce a terminal status. The issue is that all valid Developer ID submissions remain stuck in In Progress. I understand that first-time notarization can take longer because of deeper analysis, but this has now been several days and every valid submission is still pending. Could someone from Apple DTS or the notarization team check whether Team ID TP32Y96XC5 is stuck in the first-time review/notarization queue? Thanks.

I've read Quinn's response on thread 827096 about Developer ID notarization submissions held for "in-depth analysis" on new teams. That guidance fits the general shape of what I'm seeing, but I'm posting a separate thread because (a) my situation does not involve an app transfer — these are the first-ever notarizations under a newly activated team, and (b) I've passed the "usually clears in a day or two" expectation and want to ask a few specific questions that thread didn't cover. Setup macOS app distributed outside the App Store Rust universal binary (aarch64-apple-darwin + x86_64-apple-darwin, merged via lipo) Binary signed with Developer ID Application, hardened runtime (--options runtime) and Secure Timestamp (--timestamp) .pkg built via pkgbuild + productsign with Developer ID Installer Team was activated 2026-05-29 — these are our first notarizations under the account, no prior submission history Submissions Submission A — submitted 2026-05-29T19:18:02Z, currently 100+ hours In Progress Submission B — submitted 2026-06-01, currently 30+ hours In Progress, identical polling behavior (Submission IDs available to DTS on request — happy to share via DM or via the Apple Developer Support case we have open on the same issue.) I submitted B specifically to test whether A was a one-off stuck queue entry. Both stalling identically rules that out and points at a team-level condition rather than a per-submission issue. xcrun notarytool log returns Submission log is not yet available or submissionId does not exist for both — same as the OP's experience on 827096. Local verification — every check in TN2206 passes $ pkgutil --check-signature .pkg Status: signed by a developer certificate issued by Apple for distribution Signed with a trusted timestamp on: 2026-05-29 19:15:36 +0000 Certificate Chain: Developer ID Installer: () Developer ID Certification Authority Apple Root CA $ codesign --verify --strict --verbose=2 valid on disk satisfies its Designated Requirement $ codesign --display --verbose=4 | grep -E '^(Authority|Timestamp|Runtime|TeamIdentifier)=' Authority=Developer ID Application: () Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=May 29, 2026 at 12:13:40 PM TeamIdentifier= Runtime Version=26.5.0 xcrun notarytool history returns successfully and lists both submissions, so authentication and connectivity to the notary service are healthy. Developer System Status has shown the Developer ID Notary Service as "Available" throughout. Questions for DTS (Quinn or whoever picks this up) Quinn's 827096 reply describes "in-depth analysis" for new teams clearing in a day or two. Is there a known long-tail beyond that window, and is there anything a team can do to flag itself as ready for processing rather than waiting passively? Does resubmitting (as I did with submission B) extend, restart, or sit independently from the review of submission A? Is the review-completion clock driven by the team's activation date, the first submission, or the cumulative submission history? In other words, does each new submission help the team's signal, or does the system wait for the first to fully clear before evaluating subsequent ones? If we hit the 1-week mark Quinn referenced as the escalation tripwire without resolution, what's the recommended channel — a follow-up reply here, a new thread, Feedback Assistant, or another route? We also have an open Apple Developer Support case on this, currently silent for 4 days. Working that channel in parallel. Thanks in advance for any guidance — and thanks to Quinn for the public visibility he's given this pattern on 827096; it's the most useful documentation on it I've been able to find.

I’m seeing several Developer ID notarization submissions stuck in “In Progress” after an app transfer. This is for a macOS app distributed outside the Mac App Store. The app was recently transferred to a new Apple Developer team. After the transfer, notarization uploads succeed, but the submissions never complete. The app appears to be Developer ID signed correctly with the new team. I submitted the app through both Xcode Direct Distribution and command-line notarytool. The upload succeeds, but the submissions remain in “In Progress”, and no notarization log is available. Example submission IDs: 5e411dc6-0610-4f9c-8eef-e2a3d0b6a2fb 01bdeeda-3c7e-421a-ae72-6dc081b75e79 986b0c5e-e32f-489f-bc86-3b3c7d7ec91d 193f29b7-b23a-40e7-8324-c076859ca843 notarytool log returns: Submission log is not yet available or submissionId does not exist I also see older submissions from the previous day still stuck in “In Progress”, so this does not look like a normal notarization delay. I’m trying to determine whether this is caused by the recent app transfer / Team ID change, or whether there is anything else I can check locally. Questions: Is it expected for Developer ID notarization jobs to remain “In Progress” for more than a day with no log available? Is there any known issue with Developer ID notarization after an app transfer? If the upload succeeds but no log is ever generated, is there a recommended escalation path for stuck notarization backend jobs?

Hello Apple Developer Support Team, This is my first app submission. I submitted my app on 18 May 2026, and since then all notarization submissions have remained in “In Progress” for an unusually long period without completing. Environment macOS 26.2 Notarization tool: xcrun notarytool submit Team ID: HRZ4D6R846 Developer ID signing identity is valid and correctly detected Timeline Issue started on 18 May 2026 Multiple submissions have remained in “In Progress” for 24–72+ hours Current count: 3+ submissions stuck in progress Checks already completed Verified the Developer ID Application certificate is valid and properly installed. Verified app signatures using: codesign -vvv --deep --strict Checked Apple Developer System Status, which currently shows all services as operational Re-submitted using fresh builds and credentials, but the behavior remains unchanged Could you please confirm whether there is any known notarization processing issue on Apple’s side during this period, and advise on the following: How to unblock the currently stuck submissions Whether the “In Progress” submissions should be cancelled and re-submitted Thank you for your assistance. Best regards, Rishikesh Galande

I tried every possible but it just won't work on my device. The program runs well on the simulator by the way

While testing Flutter applications on macOS 26 beta with Xcode 26 beta, iOS builds consistently fail during Flutter.framework codesigning with: "resource fork, Finder information, or similar detritus not allowed" Investigation suggests newer Xcode beta versions now reject additional extended attributes beyond com.apple.FinderInfo during codesigning. Flutter tooling currently removes only: xattr -r -d com.apple.FinderInfo Replacing it with: xattr -cr successfully resolves the issue. Environment: macOS 26.4.1 beta Xcode 26.4.1 beta Apple Silicon (ARM64) Flutter 3.41.9 Flutter issue: https://github.com/flutter/flutter/issues/186372 Apple Feedback Assistant report: FB22756923 Interested to know whether other developers on Xcode 26 beta are seeing similar stricter codesigning validation behavior.

I'm hitting a kernel-side rejection on IOServiceOpen from a host app against my DEXT's IOUserService, before any code in my DEXT's NewUserClient runs. DEXT activation and USB matching succeed; only the user-client connection fails. What works DEXT activates and shows as [activated enabled] in systemextensionsctl list. DEXT matches IOUSBHostInterface for the target device and Start() runs to completion. Inside Start(), CopyInterface() returns successfully and CopyPipe() for the expected endpoints all succeed. Host app receives the matching notification for the DEXT's IOUserService and calls IOServiceOpen(service, mach_task_self(), 0, &connect). What fails IOServiceOpen returns kIOReturnError (0xE00002BC). My DEXT's NewUserClient override is never reached — verified by the absence of any breadcrumb log and by stepping through under lldb (no entry on the DEXT side). This reproduces both with: The original com.apple.developer.driverkit.userclient-access entitlement listing the host bundle ID. The dev fallback com.apple.developer.driverkit.allow-any-userclient-access = true on host + DEXT. (Background: the App ID portal has the bundle-ID list for userclient-access stored as a single newline-joined string instead of separate array entries — see Support Thread 822652 — so I've been using allow-any-userclient-access = true for now. The IOServiceOpen failure persists either way.) Diagnostics I can't get I'd like to confirm the kernel-side rejection reason, but DEXT os_log output is suppressed in Console and: sudo log config --process <dext-pid> --mode "level:debug" log: Unable to set mode for pid <dext-pid> I've tried by PID and by subsystem; both refuse. SIP is in its default state. Any pointer to the correct invocation (or a Configuration Profile to enable DriverKit verbose logging) would unblock me. Environment macOS 26.3.1 (build 25D2128) Xcode 26.3 (build 17C529) Host app: AppKit, sandboxed, Mac App Store distribution DEXT: matches IOUSBHostInterface on idVendor: 0x1452 (DNP) and (pending capability approval) 0x1343 (Citizen) Entitlements on host: com.apple.developer.driverkit, com.apple.developer.driverkit.userclient-access (or allow-any-userclient-access = true for dev) Entitlements on DEXT: com.apple.developer.driverkit, com.apple.developer.driverkit.transport.usb, com.apple.developer.driverkit.allow-any-userclient-access for dev Questions Is IOServiceOpen → kIOReturnError before NewUserClient always an entitlement/sandbox check failure, or are there other kernel-side reasons (matching score, IOService class hierarchy mismatch) that produce the same generic code? What's the correct way to enable DEXT os_log capture so I can see the rejection reason? Is there a known interaction between a malformed userclient-access array on the App ID (Forums Thread 822652) and the kernel's user-client authorization path that would persist even after switching to allow-any-userclient-access = true? Sample profiles, codesign output, and the exact matching dictionary available on request. Thanks.

Hi, I’m seeing WeatherKit fail on device with a JWT permission error even though the app appears to be signed correctly with the WeatherKit entitlement. Error: Failed to generate jwt token for: com.apple.weatherkit.authservice Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Setup verified: iOS physical device, tested after clean install/reboot Tested on more than one physical device Bundle ID: com.elilindenDinematch.Al-Outfits Team ID: FYGW4LHN42 App ID has WeatherKit capability enabled Fresh provisioning profile includes: application-identifier = FYGW4LHN42.com.elilindenDinematch.Al-Outfits com.apple.developer.team-identifier = FYGW4LHN42 com.apple.developer.weatherkit = true Signed app binary entitlements also include com.apple.developer.weatherkit = true codesign -dv confirms TeamIdentifier=FYGW4LHN42 Cleared DerivedData and regenerated/reinstalled with a fresh profile Toggled WeatherKit capability off/on in Developer portal and regenerated profile The failure occurs when calling: let weather = try await WeatherKit.WeatherService.shared.weather(for: location) The request takes a few seconds before failing, which makes it seem like the WeatherKit daemon is reaching Apple’s auth service but being rejected during JWT generation. Has anyone seen WeatherKit entitlement propagation get stuck server-side for a specific Team ID + Bundle ID? Is there anything else I can verify locally, or does this require Apple to inspect the WeatherKit auth service registration for this App ID?