You can now easily request access to managed capabilities for your App IDs directly from the new Capability Requests tab in Certificates, Identifiers & Profiles > Identifiers. With this update, view available capabilities in one convenient location, check the status of your requested capabilities, and see any notes from Apple related to your requests. Learn more about capability requests.

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"

Hi support, Currently we are in a process of migrating our Qt application for MAC OS - ventura -v13.4. There is a specific feature in our application in which client tries to communicate with server (Socket communication) using Qt's QsslSocket Apis . To achieve this we are using self signed Ca certificate (.pem ) generated by using openSSl commands which uses IP address of the server. We are manually installing the certificate inside MAC OS - keychain and trusting it manually as well after installing . This is working fine in XCode environment in debug mode in MAC OS and client -server handshake is happening successfully. How ever after creating .dmg file (installer) the same handshake is not happening and we are getting error -Connection time out. Upon investigating this online, we got to know there has to be codesigning (both app bundle and the dmg file )along with notarization of the .dmg file in order to access keychain of MAC OS at runtime to access the self signed certificate installed. Now we have 2 queries here. Is code signing mandatory if we want to verify our app through keychain with .dmg file ? If yes, whats the best way to achieve this ? We have tried 2 options without any luck. option1 - Trying to build our specific target among 'ALL_BUILD' with signing key settings inside xcode where we are providing developer provisional certificate with apple team ID . After that we are trying to archive to generate dmg file which is code signed. We are failing here as the signed dmg is not getting installed due to other app related dependencies are missing . option 2- Code signing the dmg and the app bundle manually outside the environment of xcode with developer certificate and team ID. We are failing here as notarization needs to be done it seems to access keychain for certificate verification If Code signing is not mandatory then whats the best possible way to achieve this considering manually installation of certificate inside keychain with adding trust option is not working at the moment. Please specify the best solution if possible.

Hi, I read that notarization should be fairly quick. I thought that it was stuck, so I ended up sending a few submissions of the same app. I was wondering if you'd able to tell me the status of my latest submission (id: a094f93d-8bb2-47fe-a411-b6e357456ec7). It has been saying "In Progress" for over 3 hours now. If it is held for in-depth review, would you be able to tell me what's the wait period is like? Thanks!

To ship a product outside of the Mac App Store, you must notarise it. The notary service issues a notarised ticket, and the ultimate consumer of that ticket is Gatekeeper. However, Gatekeeper does not just check the ticket; it also applies a variety of other checks, and it’s possible for those checks to fail even if your notarised ticket is just fine. To avoid such problems showing up in the field, test your product’s compatibility with Gatekeeper before shipping it. To do this: Set up a fresh machine, one that’s never seen your product before. If your product supports macOS 10.15.x, x < 4, the best OS version to test with is 10.15.3 [1]. Download your product in a way that quarantines it (for example, using Safari). Disconnect the machine from the network. It might make sense to skip this step. See the discussion below. Install and use your product as your users would. If the product is signed, notarised, and stapled correctly, everything should work. If not, you’ll need to investigate what’s making Gatekeeper unhappy, fix that, and then retest. For detailed advice on that topic, see Resolving Trusted Execution Problems. Run this test on a fresh machine each time. This is necessary because Gatekeeper caches information about your product and it’s not easy to reset that cache. Your best option is to do this testing on a virtual machine (VM). Take a snapshot of the VM before the first test, and then restore to that snapshot when you want to retest. Also, by using a VM you can disable networking in step 3 without disrupting other work on your machine. The reason why you should disable networking in step 3 is to test that you’ve correctly stapled the notarised ticket on to your product. If, for some reason, you’re unable to do that stapling, it’s fine to skip step 3. However, be aware that this may cause problems for a user if they try to deploy your product to a Mac that does not have access to the wider Internet. For more background on this, see The Pros and Cons of Stapling. [1] macOS 10.15.4 fixes a bug that made Gatekeeper unnecessarily strict (r. 57278824), so by testing on 10.15.3 you’re exercising the worst case. The process described above is by far the best way to test your Gatekeeper compatibility because it accurately tests how your users run your product. However, you can also run a quick, albeit less accurate test, using various command-line tools. The exact process depends on the type of product you’re trying to check: App — Run syspolicy_check like this: % syspolicy_check distribution WaffleVarnish.app This tool was introduced in macOS 14. On older systems, use the older spctl tool. Run it like this: % spctl -a -t exec -vvv WaffleVarnish.app Be aware, however, that this check is much less accurate. Disk image — Run spctl like this: % spctl -a -t open -vvv --context context:primary-signature WaffleVarnish.dmg Installer package — Run spctl like this: % spctl -a -t install -vvv WaffleVarnish.pkg Other code — Run codesign like this: % codesign -vvvv -R="notarized" --check-notarization WaffleVarnish.bundle This command requires macOS 10.15 or later. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision history: 2024-12-05 Added instructions for using syspolicy_check. Made other minor editorial changes. 2023-10-20 Added links to Resolving Trusted Execution Problems and The Pros and Cons of Stapling. Made other minor editorial changes. 2021-02-26 Fixed the formatting. 2020-04-17 Added the section discussing spctl. 2020-03-25 First version.

So we are building a Tauri app and I have no been able to get our App to be Notarized using Developer ID. We have a ticket open for 3 months now. Can anyone help me out here? { "logFormatVersion": 1, "jobId": "e2ec4d13-bb83-41d4-a497-ba80cf830af1", "status": "Rejected", "statusSummary": "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.", "statusCode": 7000, "archiveFilename": "HIDDEN", "uploadDate": "2026-01-23T16:13:37.589Z", "sha256": "fd52815d5edf14b66b25529e89c207b2acff2c41642261e1049a479f19f2b72f", "ticketContents": null, "issues": null } How do we escalate to engineering team? Sincerely, Nash Gadre https://camouflagenetworks.com

I started the notarization process for my electron app (just a browser window loading a URL) yesterday (26/03/2025) at around 05:23 GMT. I noticed in a couple of posts here in the forum that it may sometimes take a day to notarize the first app submitted by a team, but it has been over 30 hours now. Here's the log from xcrun notarytool history. createdDate: 2025-03-26T05:23:11.102Z id: ddcb3fca-4667-4acb-8fd1-3298a7c244cc name: xolock-browser.zip status: In Progress Do help me out here, I have zero idea why this is taking so long. Thanks in advance!

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

IMPORTANT The underlying issue here (FB8830007) was fixed in macOS 11.3, so the advice in this post is irrelevant if you’re building on that release or later. Note This content is a repost of info from another thread because that thread is not world readable (it’s tied to the DTK programme). A number of folks have reported problems where: They have a product that supports older versions of macOS (anything prior to 10.11). If they build their product on Intel, everything works. If they build their product on Apple Silicon, it fails on those older versions of macOS. A developer filed a bug about this (FB8830007) and, based on the diagnosis of that bug, I have some info to share as to what’s going wrong and how you can prevent it. Let’s start with some background. macOS’s code signing architecture supports two different hash formats: sha1, the original hash format, which is now deprecated sha256, the new format, support for which was added in macOS 10.11 codesign should choose the signing format based on the deployment target: If your deployment target is 10.11 or later, you get sha256. If your deployment target is earlier, you get both sha1 and sha256. This problem crops up because, when building for both Intel and Apple Silicon, your deployment targets are different. You might set the deployment target to 10.9 but, on Apple Silicon, that’s raised to the minimum Apple Silicon system, 11.0. So, which deployment target does it choose? Well, the full answer to that is complex but the executive summary is that it chooses the deployment target of the current architecture, that is, Intel if you’re building on Intel and Apple Silicon if you’re building on Apple Silicon. For example: intel% codesign -d --arch x86_64 -vvv Test664892.app … Hash choices=sha1,sha256 … intel% codesign -d --arch arm64 -vvv Test664892.app … Hash choices=sha1,sha256 … arm% codesign -d --arch x86_64 -vvv Test664892.app … Hash choices=sha256 … arm% codesign -d --arch arm64 -vvv Test664892.app … Hash choices=sha256 … The upshot is that you have problems if your deployment target is less than 10.11 and you sign on Apple Silicon. When you run on, say, macOS 10.10, the system looks for a sha1 hash, doesn’t find it, and complains. The workaround is to supply the --digest-algorithm=sha1,sha256, which overrides the hash choice logic in codesign and causes it to include both hashes: arm% codesign -s - --digest-algorithm=sha1,sha256 Test664892.app arm% codesign -d --arch x86_64 -vvv Test664892.app … Hash choices=sha1,sha256 … % codesign -d --arch arm64 -vvv Test664892.app … Hash choices=sha1,sha256 … Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Not accepted yet (all are still processing, none are rejected) 387af103-42d3-4d95-ae22-0289f90a8559 — In Progress 2d836594-9fb2-41a5-990c-7ea4e0870af0 — In Progress e61ba9e3-5ff1-4856-8e9d-39c08445ff63 — In Progress 1defdeec-50b4-45c5-b32d-53ca6e4538bb — In Progress 34e60b80-20c3-4ea7-93a7-2bb9e7c6f05c — In Progress 09222b71-eae1-4c5c-aca4-368f697b2a39 — In Progress eb5327e8-161e-4185-9920-3facf60b7b4b — In Progress 784fc210-d0bf-4924-b0a6-eb8bbac0f2c8 — In Progress 74bc8f31-b1b0-4bed-9142-0c03100a062a — In Progress 4739620c-894a-4283-a43b-df57b29a1771 — In Progress have created new certificate as well same result. waiting for apple support to give any answers.

Validation failed (409) Missing Code Signing Entitlements. No entitlements found in bundle 'com.seeyon.yiboyun.child' for executable 'Payload/M3.app/PlugIns/CMPSharePublish.appex/CMPSharePublish'." (ID: 6e5429ed-b896-45a0-ab23-bb8fcb472072)

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

Hey, when I try to launch my app it prompts me with a "Apple could not verify" popup. The thing is the app has been signed and stapled. xcrun stapler validate .app for my app returns "The validate action worked!" If I also run syspolicy_check distribution .app it returns: "App passed all pre-distribution checks and is ready for distribution" Any idea?

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

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

I am trying to build/deploy app to my phone however I get this message: "provisioning profile doesn't include the currently selected device" My developer account is pretty old one and used to be one the paid-version one. My understanding is that I should be able to deploy apps using free account but I don't see where I can add or delete devices....stuck in the loop over here! :-) I've created support request via email but I don't know if that is being worked or not...four days since I put it in. I suppose my other options are new apple-id or pay $99 and hope apple pays attention then? Any other suggestions?

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

I'm submitting my first macOS app (a native SwiftUI menu bar app, signed with Developer ID Application certificate, Hardened Runtime enabled) for notarization using xcrun notarytool submit with keychain profile authentication. All 9 of my submissions have been stuck at "In Progress" for up to 16 hours. None have transitioned to "Accepted" or "Invalid." Logs are unavailable for all of them (notarytool log returns "Submission log is not yet available"). Environment macOS: 26.2 (25C56) Xcode: 26.1.1 (17B100) notarytool: 1.1.0 (39) App: Native SwiftUI, universal binary (x86_64 + arm64), ~2.2 MB DMG Bundle ID: com.gro.ask Team ID: 4KT56S2BX6 What I've verified Code signing is valid: $ codesign --verify --deep --strict GroAsk.app passes with no errors $ codesign -dvvv GroAsk.app Authority=Developer ID Application: Jack Wu (4KT56S2BX6) Authority=Developer ID Certification Authority Authority=Apple Root CA CodeDirectory flags=0x10000(runtime) # Hardened Runtime enabled Runtime Version=26.1.0 Format=app bundle with Mach-O universal (x86_64 arm64) Entitlements are minimal: com.apple.security.app-sandbox com.apple.security.network.client Uploads succeed — each submission receives a valid submission ID and the file uploads to Apple's servers without error. Submission history Created (UTC): 04:40 ID: eeb12389-... File: GroAsk-1.6.0.dmg Status: Invalid (Hardened Runtime missing — since fixed) ──────────────────────────────────────── Created (UTC): 04:42 ID: 6e537a32-... File: GroAsk-1.6.0.dmg Status: In Progress (16+ hrs) ──────────────────────────────────────── Created (UTC): 07:52 ID: 5ee41736-... File: GroAsk-1.6.0.dmg Status: In Progress ──────────────────────────────────────── Created (UTC): 08:19 ID: f5c6b9a5-... File: GroAsk-1.6.0.dmg Status: In Progress ──────────────────────────────────────── Created (UTC): 08:27 ID: 0f1c8333-... File: GroAsk-1.6.0.dmg Status: In Progress ──────────────────────────────────────── Created (UTC): 08:29 ID: 77fd9cd4-... File: GroAsk-1.6.0.dmg Status: In Progress ──────────────────────────────────────── Created (UTC): 08:51 ID: db9da93e-... File: GroAsk-1.6.1.dmg Status: In Progress ──────────────────────────────────────── Created (UTC): 09:05 ID: 3c43c09f-... File: GroAsk.zip Status: In Progress ──────────────────────────────────────── Created (UTC): 12:01 ID: b2267a74-... File: GroAsk-1.6.3.dmg Status: In Progress ──────────────────────────────────────── Created (UTC): 12:15 ID: ae41e45c-... File: GroAsk.zip Status: In Progress The very first submission (eeb12389) came back as Invalid within minutes because Hardened Runtime wasn't enabled on the binary. I fixed the build configuration and confirmed flags=0x10000(runtime) is present on all subsequent builds. However, every submission after that fix has been stuck at "In Progress" with no state transition. What I've tried Submitting both .dmg and .zip formats — same result Verified notarytool log — returns "Submission log is not yet available" for all stuck submissions Apple Developer System Status page shows the Notary Service as "Available" I've also emailed Apple Developer Support but have not received a response yet Questions Is this the expected behavior for a first-time notarization account? I've seen other threads mentioning that new accounts may be held for "in-depth analysis," but 16+ hours with zero feedback seems excessive. 2. Is there any manual configuration Apple needs to do on their end to unblock my team for notarization? 3. Should I stop submitting and wait, or is there something else I can try? Any guidance from DTS would be greatly appreciated. This is blocking the release of my app.

Seeing my notarizations getting stuck. This is becoming a blocker for releasing. What's strange is that earlier versions of the same app (very similar) passed notarization very quickly. Any advice or recourse?

General: Forums topic: Code Signing Forums subtopic: Code Signing > Notarization Forums tag: Notarization WWDC 2018 Session 702 Your Apps and the Future of macOS Security WWDC 2019 Session 703 All About Notarization WWDC 2021 Session 10261 Faster and simpler notarization for Mac apps WWDC 2022 Session 10109 What’s new in notarization for Mac apps — Amongst other things, this introduced the Notary REST API Notarizing macOS Software Before Distribution documentation Customizing the Notarization Workflow documentation Resolving Common Notarization Issues documentation Notary REST API documentation TN3147 Migrating to the latest notarization tool technote Fetching the Notary Log forums post Q&A with the Mac notary service team Developer > News post Apple notary service update Developer > News post Notarisation and the macOS 10.9 SDK forums post Testing a Notarised Product forums post Notarisation Fundamentals forums post The Pros and Cons of Stapling forums post Resolving Error 65 When Stapling forums post Many notarisation issues are actually code signing or trusted execution issue. For more on those topics, see Code Signing Resources and Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

When completing signing on Xcode, it shows the following error message "No certificate for team '' matching 'Developer ID Application' found" I have already followed the steps to generate a certificate from keychain and made a new certificate on developer portal, along with its associated provisioning profile. Viewing "Manage Certificate" window shows the newly created certificate, but Xcode seems to not be able to locate it.

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?