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, I'm notarizing my Electron macOS app (DMG) for the first time with our new Developer ID, and most submissions have been stuck in "In Progress" for over 24 hours. Environment: Team ID: BSS9KAH6Z2 Certificate: Developer ID Application (valid until 2031) Tool: xcrun notarytool submit (Xcode CLI) App: Electron 28, signed with hardened runtime File: DMG (~131MB), 104 files inside .app What happened: Total 19 submissions over the past 24 hours Only 4 were Accepted (2 DMGs + 2 zips) The other 15 are still "In Progress" with no log available The 4 Accepted ones took 1~1.5 hours each codesign --verify --deep --strict passes with no issues Accepted submission log shows "issues": null Apple System Status shows "Developer ID Notary Service: Available" What I've tried: Submitting as DMG directly Submitting as ditto zip of .app Submitting via electron-builder's built-in notarize Using both app-specific password and keychain profile auth Verified entitlements (allow-jit, disable-library-validation) Since some submissions did get Accepted, I don't think there's an issue with my signing or configuration. Is this expected for first-time submissions from a new team? Is there anything on Apple's side that needs to be configured for my team? Any help would be appreciated. Thank you.

Hi, I’m hoping someone can help clarify the correct entitlement format for the Enhanced Security capability in a macOS App Store build. Context Our app is a sandboxed macOS app built with Xcode 26.4. We enabled the Enhanced Security capability in Signing & Capabilities, and we configured the entitlements based on the current documentation. What’s confusing me The Xcode 26.4 release notes say apps that already adopted Enhanced Security should remove: com.apple.security.hardened-process.enhanced-security-version com.apple.security.hardened-process.platform-restrictions and replace them with: com.apple.security.hardened-process.enhanced-security-version-string with value 1 com.apple.security.hardened-process.platform-restrictions-string with value 2 Reference: https://aninterestingwebsite.com/documentation/xcode-release-notes/xcode-26_4-release-notes The entitlement reference pages also seem consistent with that: https://aninterestingwebsite.com/documentation/bundleresources/entitlements/com.apple.security.hardened-process.enhanced-security-version-string https://aninterestingwebsite.com/documentation/bundleresources/entitlements/com.apple.security.hardened-process.platform-restrictions-string So our app currently uses the new -string entitlements with values "1" and "2". Our App Review rejection said: The app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Entitlement "com.apple.security.hardened-process.enhanced-security-version-string" value must be boolean and true. Entitlement "com.apple.security.hardened-process.platform-restrictions-string" value must be boolean and true. That’s the part I can’t reconcile with the documentation. Questions For a Mac App Store submission built with Xcode 26.4, should these two entitlements use the new string-based form, or Boolean true? If the expected format has changed, is there any updated guidance beyond the Xcode 26.4 release notes and current entitlement reference? If Apple staff or anyone familiar with this can clarify what format is currently expected, I’d really appreciate it. Thanks.

Hello, I am a new macOS developer. I've been working on my first Mac application and I am trying to notarize it for distribution using notarytool. However, I've encountered a persistent issue where all my submissions are stuck in the "In Progress" status for several days. As this is my first time going through this process, I initially thought I might have done something wrong. However, I have verified my app with codesign --verify --verbose --deep and it returns "valid on disk" and "satisfies its Designated Requirement". I have also tried bumping the version from 0.1.0 to 0.1.1 and removing spaces from the file names, but the new submission is also stuck. Stuck Submission History (Total 4 submissions): ID: 8cb4aebb-e2d5-4091-b279-18272c3a6ca9 (Created: 2026-04-03 - Latest) ID: 0e9a3584-1a21-471a-bc72-4da3f98e2683 (Created: 2026-04-02) ID: 59b70ef1-0b8e-480d-ba33-df872a691610 (Created: 2026-04-01) ID: 685d8fdb-1e55-4cdd-8203-688991c50dd3 (Created: 2026-04-01) As a first-time developer, it’s frustrating to see these initial submissions hang for so long without any logs or errors to troubleshoot. Is there any specific reason why a first-time submission for a new Mac app might be queued this long? I would appreciate it if someone from Apple could help clear these stuck submissions or provide some guidance as to what might be causing this delay. Thank you very much.

Hello! All notarization submissions for our team (i.e., me) have been stuck "In Progress" since my first attempt on 2026-03-31. This includes a trivial Hello World CLI binary (single print statement, ~8KB), confirming the issue is account/team-level, not related to package content. Team ID: KK4X4YSB8V (Selitic B.V.) This is our first time notarizing. Binary is properly signed with Developer ID Application certificate, hardened runtime enabled, valid timestamp. codesign --verify and spctl pass locally. Submission history (all stuck): Successfully received submission history. history -------------------------------------------------- createdDate: 2026-04-01T11:29:01.416Z id: 39f5e536-d1a6-429b-947d-1a3ac497c03d name: hello-test2.zip status: In Progress -------------------------------------------------- createdDate: 2026-04-01T09:21:47.585Z id: 46322e0f-026c-4b9d-ab1f-d15d7013c6c6 name: hello-test.zip status: In Progress -------------------------------------------------- createdDate: 2026-04-01T07:23:47.576Z id: 8199ab8c-7897-461e-8a85-329d3eb22568 name: nekode-notarize.zip status: In Progress -------------------------------------------------- createdDate: 2026-04-01T05:49:10.593Z id: 410ebd83-8f7d-436a-b30e-2106e9847b2a name: nekode-notarize.zip status: In Progress -------------------------------------------------- createdDate: 2026-04-01T05:48:52.555Z id: 3d096415-46f9-4743-9dee-692f1c359249 name: nekode-notarize.zip status: In Progress -------------------------------------------------- createdDate: 2026-03-31T20:07:52.318Z id: a0e2e5a5-e0ea-4815-86d4-d1c335c4680a name: nekode-notarize.zip status: In Progress -------------------------------------------------- createdDate: 2026-03-31T20:07:15.593Z id: 1684585c-c454-479d-add6-7fd33ae8da2a name: nekode-notarize.zip status: In Progress notarytool log returns "Submission log is not yet available" for all submissions, indicating Apple's backend has not started processing. No pending agreements visible on aninterestingwebsite.com/account. Certificate is valid (expiry 2031). Could someone check the backend queue status for my team? Any guidance appreciated.

We have an app with the default email entitlement that was granted several years ago. During our latest deployment, we received an error from our pipeline. When testing a manual submission in Xcode, we saw this error: Entitlement com.apple.developer.mail-client not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. We checked the provisioning profile, and the default email entitlement is still present. It is visible on the certificate portal and also in the embedded.mobileprovision file. Can you suggest what we can do to release a new version of our app?

I'm trying to sign my application but the build times out after 90 minutes waiting for notarytool to return. This seems to be getting worse and worse. I have now updated the timeout to 10hours, to see if I can get a response at all. Something is very wrong with the tool. This was working fine up until about the 28th March 2026.

Team ID: MB9VR977ND We have changed apple developer account for the our application, after changing account we have submitted app for notarization multiple times but all showing in-progress without any logs. do we need to wait until this passed from apple side ? does submitting many request has any issue ? Submission id: 8c5ac51d-bcd3-4fc4-9b38-671e5ea2bf14

My company only needed an Apple Developer Program account in order to sign macOS binaries. Because our scope was very limited, we enrolled with an individual account. Now our scope may grow, supporting more Apple features. As a result, we may need to change to an Organization account. If we change the account type, will this invalidate the certificate we use to sign the macOS binaries?

Hi, I submitted a Family Controls (Distribution) entitlement request for my app Faith Lock (com.faithlock.ios) - a prayer-focused iOS app that uses the Screen Time API to help users block distracting apps. I received an approval email, but the portal still shows the request as "Submitted" and the Distribution option does not appear under Additional Capabilities for my identifier. This is blocking me from submitting to App Store Connect. Details: Bundle ID: com.faithlock.ios Team ID: F86P575UNP Request IDs: 3PWTDR8KL3 / 885ZK276KK Status in portal: Submitted (unchanged since approval email) Has anyone experienced this? Is there a way to get the portal manually updated to reflect the approval? Any help or escalation from a DTS engineer would be greatly appreciated. Thank you.

All notarization submissions remain stuck "In Progress" and never complete. Tested both DMG and ZIP formats — same result. This has been consistent across 5+ attempts on March 29, 2026. App: Electron desktop app (arm64), signed with Developer ID Application, hardened runtime enabled, secure timestamp present. DMG submissions (all stuck): 568cc9c3-e711-41ba-99ce-6af5a1860ae9 (10 min timeout) e0a345c3-ddf8-4771-bdda-e0bc133ff723 (20 min timeout) 6757e5a9-d95b-45b3-95d5-41cb23384bea (20 min timeout) ZIP submission (.app bundle via ditto, ~207MB): Also stuck "In Progress" for 10+ minutes notarytool log returns "Submission log is not yet available" for all submissions. Developer ID Notary Service shows "Available" on System Status page. Environment: macOS GitHub Actions runner (macos-latest), latest Xcode, xcrun notarytool. Seeing similar reports from other developers this week. Is there a known service issue?

Hi, My first notarization submission has been stuck in "In Progress" for several hours with no status change. I'm wondering if it's being held for in-depth analysis given the nature of the app. The app is a macOS dictation utility triggered by a global hotkey. It captures audio input, transcribes it, and pastes the result at the cursor position in whatever app the user is focused on. Because of how it works, it relies on a combination of APIs that may be less common in typical submissions: continuous microphone access, programmatic clipboard manipulation, global keyboard event monitoring, and Accessibility APIs to inject text into the frontmost application. This is the first submission for this app, so there's no prior notarization history for the system to learn from. Is this the kind of profile that typically triggers in-depth analysis? Is there anything I should check or provide, or is waiting the right move here? Thanks

We have 8 consecutive notarytool submit submissions for the same .dmg artifact all stuck In Progress with no movement and no logs available. Submission IDs (all Recall-0.3.6-arm64.dmg, Team ID: H9S7XRPUCA): Diagnostic evidence: notarytool log on all 8 returns exit 69 (log not available) — no rejection reason, no processing output The app bundle submitted as a ZIP (same binary, same signing, submission d21e9fea) was accepted in 41 seconds at 2026-03-27T02:15Z A separate probe submission of a small signed binary on the same team (fcf018c5) was accepted in ~5 minutes All prior Recall DMG builds (0.1.0–0.3.5) processed normally in ~8 minutes on this same team Normal processing time for this team/account is ~8 minutes Conclusion: Content and signing are clean. Account queue is healthy. The issue appears specific to the DMG submission path for this build. Requesting Apple investigate the stuck DMG submissions and advise on next steps.

I have an existing app in App Store Connect. I added the SharedWithYou functionality to the app code and tested it on several devices. Everything is working as expected. One of the first steps was to add the com.apple.developer.shared-with-you entitlement to the Entitlements.plist file. This required a round of updates for app identifiers and provisioning profiles. When I upload the production build for testing in TestFlight I receive the following error: 90919: Invalid entitlement. The “” bundle has the com.apple.developer.shared-with-you entitlement, but it doesn’t use the Shared with You framework. Please remove the entitlement and upload a new build. I'm using SWHighlight, SWHighlightCenter, and SWAttributionView in several places throughout my app... I filed an issue in the Feedback Assistant but so far, have not received any response.

The following process to sign my .pkg installer for distribution outside the app store have been working for over a year and recently the notarization fails with a rc = 69. I not aware of any changes other then xtools updates for the latest macos 15.6.1. Admittedly I felt lucky to have gotten it all to work initially and I could really use help. Thanks in advance! Bill The signing (no errors): productsign --sign macos_cert myapp.pkg The notarization (rc=69): xcrun -v notarytool submit myapp.pkg --apple-id my_apple_id --team-id XXXXXXXXXX

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

Hello, At work, we want to release a new version of our cross-platform desktop application this week. Unfortunately, I've had issues getting the dmg signed by the Apple notary service, which will delay the release until it's successful. However, I remade and successfully signed the previously released version (also dmg) with the same credentials, so I know it's not a problem with the file format or my account. I have tried the following to no avail: Lots of Googling Running xcrun notarytool submit with the -v option (verbose) to see more error messages Going to the URL given (appstoreconnect.apple.com/notary/v2/submissions/{submission_id}) and examining the file it downloaded (not much info, let alone helpful info) Contacting Apple developer support over the phone (they couldn't help with this particular issue, since it's "code-level support") The only big change we made this time was switching to Maven for our build tool and dependency management (we previously used Ant with manual dependency management). Does anyone here have any insight? Is there a list of known issues or dependencies that will cause a submission to be invalidated? Or, even better, any way to see why the submission is invalid? Thanks.

Hi Apple Developer Support, We are reaching out to request guidance on a testing constraint we have encountered related to iOS Universal Links and Associated Domains entitlements. As part of aligning with updated recommendations from our authentication provider, we have transitioned our mobile apps to use HTTPS redirect callbacks (Universal Links) instead of custom URI schemes. This works as expected in production and on real physical devices. However, we are encountering a significant issue in our cloud-based device testing environment. When our testing platform re-signs the app to run it on their infrastructure, the re-signing process strips the Associated Domains entitlement from the app bundle. As a result, iOS no longer honors our Universal Links, which breaks the authentication redirect flow — the callback cannot route back into the app after the user authenticates. We have identified a potential workaround that would involve disabling app re-signing in the testing platform, but this requires provisioning under an Apple Enterprise Developer account. This introduces considerable operational complexity, as it would require us to maintain separate signing and distribution paths alongside our existing Apple Developer Program membership. Before pursuing that path, we wanted to understand Apple's perspective on the following: Is there a supported or recommended approach for preserving Associated Domains entitlements when an app is re-signed by a third party (e.g., a cloud testing platform)? Are there any provisioning or entitlement configurations that would allow Universal Links to function correctly in re-signed builds without requiring an Enterprise Developer account? Does Apple have documented best practices for validating Universal Link–based flows in automated or cloud-based testing environments? Are there any alternative deep linking patterns that would be more resilient to re-signing while still meeting App Store and platform security requirements? Any guidance or recommendations from Apple on how to handle this within the bounds of the standard Apple Developer Program would be greatly appreciated. Thank you for your time.

I enrolled in the Apple Developer Program as an Individual on March 16, 2026 (Team ID: CAZ8X23YWW). I've been trying to notarize a macOS Electron desktop app ever since. Every submission is immediately rejected with: Status code: 7000 Message: "Team is not yet configured for notarization" What I've done: Accepted all agreements on aninterestingwebsite.com Accepted all agreements on App Store Connect Created a Developer ID Application certificate (G2 Sub-CA) App is properly signed with hardened runtime Submitted a support ticket under "Distribution > Other Distribution Questions" on March 18 — no response after 4 days

Hi there, I signed up for Apple Developer Program a few hours back and am trying to sign and notarize a MacOs App. I am using this command xcrun notarytool history --apple-id "" --password "App-specific-password" --team-id "5XR5PM3Y5S" I keep getting this error. I have verified that the apple-id, password and team-id is accurate. This is surely something on Apple's side. Can you help resolve this ? Error: HTTP status code: 403. Invalid or inaccessible developer team ID for the provided Apple ID. Ensure the Team ID is correct and that you are a member of that team.

Since 2026-03-17 09:06 UTC, all notarization submissions for one of our teams are stuck in "In Progress" indefinitely. Submission logs return "not yet available", indicating Apple's backend has not started processing. Sample submission IDs: 789d40c4-ff83-469f-9b9b-2ac93183125e 2d4685ed-56ac-49db-8e38-63f0b15650c1 5dc3f242-0add-4725-8386-bb32f8383240 18+ submissions affected. Hundreds of successful notarizations before this date with no issues. Please advise or check backend queue status.