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"

New team (529ANB8634, enrolled 2026-08-07); these are our first notarization submissions. All four are still In Progress — none has returned Accepted or Invalid, and notarytool log reports no log available for any of them. Created (UTC) Request UUID 2026-08-08 11:40:15 f6f28c7e-e2a8-4f24-95eb-22510b61ca6e 2026-08-08 15:09:24 c2fb9487-eb40-4b30-a977-14714a6371d5 2026-08-09 05:31:45 b59b86a7-35e3-40a8-b364-9c46cb6388d9 2026-08-09 13:33:10 2e5d3709-e9fb-4bd0-b956-bc7fd9af375f I understand first submissions can be held for additional analysis. I'm posting because every submission is affected with none processing normally — including the last two, a 16 KB "hello world" control binary built specifically to rule out our own app. Signing verified before each submission: Developer ID chain, hardened runtime, secure timestamp, codesign --verify --deep --strict clean. Submitted with notarytool from both the Command Line Tools and Xcode 26.6; both upload fine. Are these genuinely queued, or is there something at our end I've missed?

Hello! I am hoping a DTS engineer or someone who knows the Capability Requests portal can help, because I am stuck between a written support confirmation and what the portal actually shows. Background. We are building a native macOS iSCSI initiator for SOHO and home NAS use, developed over close to two years. A userspace daemon runs the iSCSI protocol and a DriverKit system extension presents the remote LUN as a block device. The code is essentially complete. Only the DriverKit extension cannot be signed, loaded and validated without the entitlement. We submitted request 32PC8MGU57 for two entitlements: com.apple.developer.driverkit.family.block-storage-device for the extension com.aviontex.iscsi.AviontexISCSI.AviontexInitiator com.apple.developer.driverkit.userclient-access for the app com.aviontex.iscsi.AviontexISCSI, scoped to the extension bundle id The problem. On June 25 Developer Support confirmed in writing that both entitlements were granted. The portal does not match that: Block Storage Device: No Requests: on both App IDs UserClient Access: Assigned: on the app SCSI Controller: Submitted: on the app So the one entitlement we actually need, Block Storage Device, shows as never requested, even though request 32PC8MGU57 covered it and support confirmed the grant. The case was escalated to the senior team on July 2 (case 102922935570). Follow-up emails since then have not received a response. Why Block Storage Device specifically Our initiator has no PCI or Thunderbolt bus and no DMA path, so SCSIControllerDriverKit does not fit. This is confirmed by DTS in thread 776020, where Kevin Elliott explains that SCSIControllerDriverKit passes data through fBufferIOVMAddr as a physical address with no mechanism to convert it into a VM address the dext can access. He also notes it cannot be used with any bus other than PCI or Thunderbolt. Block Storage Device is therefore the family we need. My questions: Am I reading the portal correctly: Block Storage Device not requested, UserClient Access assigned, SCSI Controller submitted? From here, what is the correct way to get Block Storage Device onto these two App IDs, with both the Development and the Distribution grant, since our public beta depends on Distribution? Should I submit a new request through the Capability Requests tab or does the escalated case handle it? Is there any way to get visibility on the escalated case, since email follow-ups are not being answered? A full technical justification is prepared and we are happy to share the source code. Any guidance would be appreciated. Thank you.

I have an app for iOS already on the AppStore and I'm trying to add a macOS version of it. The AppID prefix for this app is different than my Team ID. This mismatch was always fine for submitting my iOS app. However for some reason, the macOS version gets rejected when I upload it. It tells me the AppID prefix must match my Team ID. I do not control my TeamID and I do not control my AppID prefix, they are both given to me by Apple. Yet the error message tells me they must match. How do I get past this? Here is the error message: Validation failed Invalid code signing entitlements. Your application bundle's signature contains code signing entitlements that aren't supported on macOS. Specifically, the "APPID_PREFIX.MY_BUNDLE_ID" value for the com.apple.application-identifier key in "MY_PACKAGE" isn't supported. This value should be a string that starts with your Team ID, followed by a dot ('"), followed by the bundle ID. (ID: 930b77ae-099f-4798-a14a-2803f2a9be9e) Thanks in advance for any pointer.

Every notarization submission from our team has been stuck in "In Progress" since our first attempt about 18 hours ago. None of them has ever produced a log. This includes a deliberately trivial test payload, which is why I believe this is an account-level hold rather than a problem with our app. Team ID: SSHD524FKZ Submissions (all still "In Progress", none has a log), as of 2026-08-06 14:44 UTC: 7aa0f57f-3ada-4867-8951-db832a9ac605 — created 2026-08-05 20:48:16 UTC — app archive, ~125 MB — 18h eea0e40b-d343-4818-b57b-d8bc821adf00 — created 2026-08-05 21:18:47 UTC — app archive, ~125 MB — 17h 6ffa47f1-4420-4fa3-b8a2-ef31451dfbea — created 2026-08-06 10:34:15 UTC — app archive, ~125 MB — 4h 0d05113d-4772-46df-bc1f-2daaf996165c — created 2026-08-06 11:24:49 UTC — test payload, 210 bytes — 3h The key data point: submission 0d05113d is a 210-byte zip containing a single plain text file. It is not signed and contains no executable code at all, so I expected it to be rejected as Invalid within a minute or two. Instead it has in-depth analysis, the delay does not appear to be related to the content, size or signature of our actual app. notarytool log for every submission above returns: Submission log is not yet available or submissionId does not exist which suggests the backend never began processing any of them. What I have already verified locally — the app is correctly signed with a Developer ID Application certificate, with hardened runtime enabled and a secure timestamp: $ codesign -dv --verbose=2 e-muavin.app Identifier=com.e-muavin.app CodeDirectory v=20500 ... flags=0x10000(runtime) Authority=Developer ID Application: E MUAVIN EGITIM TEKNOLOJILERI ... (SSHD524FKZ) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=6 Aug 2026 at 13:34:02 TeamIdentifier=SSHD524FKZ $ codesign -vvv --deep --strict e-muavin.app e-muavin.app: valid on disk e-muavin.app: satisfies its Designated Requirement $ spctl -a -vvv -t install e-muavin.app e-muavin.app: rejected source=Unnotarized Developer ID So the only thing missing is notarization itself. Other checks: the Apple Developer System Status page lists the Developer ID Notary Service as Operational. We are not re-submitting repeatedly — the four submissions listed above are every submission this team has ever made. These are in fact our team's first notarization attempts; our Developer ID certificates were issued yesterday. Environment: macOS 26.6 (25G72), Xcode 26.6 (17F113), notarytool 1.1.2 (41), submitting with an App Store Connect API key via electron-builder 26.15.3. Could someone from the notary service team please look at why submissions from this team are not being processed? Happy to provide any further detail. Thank you.

Hi team, Earlier, Apple’s documentation clearly mentioned that we needed to submit a request to Apple to obtain the Location Push Service Extension (com.apple.developer.location.push) entitlement. However, when I checked the Apple Developer Portal now, I don’t see an option to request this entitlement for my App ID. Could you please confirm whether this entitlement is still required to be requested from Apple, or if the process has changed and the request is no longer required? Thanks

Hello, I'm trying to notarize my Electron macOS application using a valid Developer ID Application certificate. Environment: Apple Developer Program: Active Developer ID Application certificate: Successfully created App size: ~130 MB (ZIP) Using notarytool (via electron-builder / GitHub Actions) The submission was uploaded successfully, and I received a Submission ID. Submission ID: 8a2bd38d-08da-46c0-afdf-f37b63ae4e82 However, the notarization has remained in: Status: In Progress for more than 3 hours. Running both: xcrun notarytool info and xcrun notarytool history continues to report: Status: In Progress No notarization log is available yet. Is it normal for a notarization submission to remain "In Progress" for several hours? And if its pulled to deeper checks, is there a way of knowing that is so, and its not just stuck. Knowing it could be crucial so I am not wasting my time on a stuck progress loop. Any insight would be greatly appreciated. Thank you.

I’m attempting to notarize my first macOS application for direct distribution outside the Mac App Store. I now have several submissions stuck indefinitely in In Progress, with no logs and no way to cancel them. The application is an Electron app containing: Standard Electron and Chromium components Native components written in Rust A Swift helper application used for voice dictation Submission chronology 1. First GitHub Actions submission — Invalid My first submission was produced and uploaded by my GitHub Actions CI pipeline. Apple processed it quickly and returned Invalid: 489bd350-8be3-407e-ad0e-799c6d8aa3ec — Invalid I investigated and discovered that some nested native components had not been signed correctly. That rejection was completely reasonable. 2. Second GitHub Actions submission — stuck In Progress I temporarily removed the affected optional Python-based local feature and ran the GitHub Actions pipeline again. This second GitHub submission was the first one to become stuck: f8fe6edd-c150-4427-9a26-77ac0ab27b8d — In Progress Created: 2026-08-05T04:21:23Z The GitHub job produced no output for approximately 20 minutes, so I believed it had stalled and cancelled the runner to avoid continuing macOS runner costs. The Apple submission remained In Progress after the GitHub job was cancelled. Because this CI invocation used JSON output, multipart-upload progress was suppressed. Apple created a submission record, but I cannot retrospectively prove whether every upload chunk completed. It is possible this became an orphaned submission following an incomplete upload. 3. Troubleshooting moved to my local Mac After the second GitHub run became stuck, I stopped using GitHub Actions for troubleshooting. I moved the complete signing, packaging and notarization process to my local Mac so I could inspect every stage without consuming CI time. During this local work, I discovered additional mistakes in my custom signing process for nested components. I therefore expect some of my early local submissions to be invalid. However, they have never become Invalid or produced diagnostic logs. They remain In Progress: d3b3b11e-156d-4c71-a1e5-4f1ca6fa4de4 — In Progress fbf5de13-46c6-4a51-b75b-e9e4a02ecef3 — In Progress 4. Corrected and locally verified submission I corrected the signing process and added strict pre-submission verification covering: Main application signature All nested executables, frameworks and helper applications Developer ID certificate fingerprints Team ID Hardened Runtime Secure timestamps Distribution entitlements DMG integrity and checksum Final DMG signature Packaged-application launch testing The corrected 0.7.2 submission passed those checks but also remains stuck: 16101ad1-89a5-411f-94ff-326e10c3e966 — In Progress 5. Version 0.7.3 with definitively completed upload I have now built version 0.7.3 from current main and submitted it manually using verbose notarytool output: Submission ID: 60acb64e-7f3f-4ebe-8882-a189bcdb1bef File: Velvet-Avocado-0.7.3-macos-arm64.dmg Size: 161 MB Created: 2026-08-06T06:35:27Z Status: In Progress Unlike the earlier CI submission, I captured definitive proof that this multipart upload completed: Completed [33/33] chunks of a multipart upload. Upload progress: 100.00% (161 MB of 161 MB) Received new upload status: Succeeded Multipart upload process has completed successfully. Successfully uploaded file. The submitted DMG’s SHA-256 was: 46b3730a122d557c957a7709e1c9f7e6b8a2a66b83a34f85c473686bdb4af1dc For every submission still In Progress, notarytool log reports that the submission log is not yet available. I have opened an Apple Developer Support request asking for the older submissions to be cancelled or investigated. There appears to be no self-service cancellation mechanism. I understand that the incorrectly signed builds should fail. My concern is that they never reach a terminal status, never produce diagnostic logs, and may be interfering with subsequent corrected submissions. Apple’s documentation says most notarizations complete within five minutes and 98% complete within fifteen minutes. Some of these submissions have remained In Progress for more than a day. I do not want to create further duplicate submissions, but I cannot complete my macOS release until Apple returns a terminal result and makes the notarization ticket available. How should I proceed?

New Developer account: notarization submissions stuck In Progress over 32 hours I’m attempting to notarize my first macOS application for direct distribution outside the Mac App Store. I now have several submissions stuck indefinitely in In Progress, with no logs and no way to cancel them. The application is an Electron app containing: Standard Electron and Chromium components Native components written in Rust A Swift helper application used for voice dictation Submission chronology 1. First GitHub Actions submission — Invalid My first submission was produced and uploaded by my GitHub Actions CI pipeline. Apple processed it quickly and returned Invalid: 489bd350-8be3-407e-ad0e-799c6d8aa3ec — Invalid I investigated and discovered that some nested native components had not been signed correctly. That rejection was completely reasonable. 2. Second GitHub Actions submission — stuck In Progress I temporarily removed the affected optional Python-based local feature and ran the GitHub Actions pipeline again. This second GitHub submission was the first one to become stuck: f8fe6edd-c150-4427-9a26-77ac0ab27b8d — In Progress Created: 2026-08-05T04:21:23Z The GitHub job produced no output for approximately 20 minutes, so I believed it had stalled and cancelled the runner to avoid continuing macOS runner costs. The Apple submission remained In Progress after the GitHub job was cancelled. Because this CI invocation used JSON output, multipart-upload progress was suppressed. Apple created a submission record, but I cannot retrospectively prove whether every upload chunk completed. It is possible this became an orphaned submission following an incomplete upload. 3. Troubleshooting moved to my local Mac After the second GitHub run became stuck, I stopped using GitHub Actions for troubleshooting. I moved the complete signing, packaging and notarization process to my local Mac so I could inspect every stage without consuming CI time. During this local work, I discovered additional mistakes in my custom signing process for nested components. I therefore expect some of my early local submissions to be invalid. However, they have never become Invalid or produced diagnostic logs. They remain In Progress: d3b3b11e-156d-4c71-a1e5-4f1ca6fa4de4 — In Progress fbf5de13-46c6-4a51-b75b-e9e4a02ecef3 — In Progress 4. Corrected and locally verified submission I corrected the signing process and added strict pre-submission verification covering: Main application signature All nested executables, frameworks and helper applications Developer ID certificate fingerprints Team ID Hardened Runtime Secure timestamps Distribution entitlements DMG integrity and checksum Final DMG signature Packaged-application launch testing The corrected 0.7.2 submission passed those checks but also remains stuck: 16101ad1-89a5-411f-94ff-326e10c3e966 — In Progress 5. Version 0.7.3 with definitively completed upload I have now built version 0.7.3 from current main and submitted it manually using verbose notarytool output: Submission ID: 60acb64e-7f3f-4ebe-8882-a189bcdb1bef File: Velvet-Avocado-0.7.3-macos-arm64.dmg Size: 161 MB Created: 2026-08-06T06:35:27Z Status: In Progress Unlike the earlier CI submission, I captured definitive proof that this multipart upload completed: Completed [33/33] chunks of a multipart upload. Upload progress: 100.00% (161 MB of 161 MB) Received new upload status: Succeeded Multipart upload process has completed successfully. Successfully uploaded file. The submitted DMG’s SHA-256 was: 46b3730a122d557c957a7709e1c9f7e6b8a2a66b83a34f85c473686bdb4af1dc For every submission still In Progress, notarytool log reports that the submission log is not yet available. I have opened an Apple Developer Support request asking for the older submissions to be cancelled or investigated. There appears to be no self-service cancellation mechanism. I understand that the incorrectly signed builds should fail. My concern is that they never reach a terminal status, never produce diagnostic logs, and may be interfering with subsequent corrected submissions. Apple’s documentation says most notarizations complete within five minutes and 98% complete within fifteen minutes. Some of these submissions have remained In Progress for more than a day. I do not want to create further duplicate submissions, but I cannot complete my macOS release until Apple returns a terminal result and makes the notarization ticket available. How should I proceed?

team 29ZP95Z3NX, a new Developer ID account whose first notarization was yesterday. Three submissions, none has ever reached a terminal state: cefe29b8-628c-4aaf-84f2-bb376dbce5b6 2026-08-05 15:12 UTC now 15h 044fdff5-2a8a-4fe7-8572-c1569b7c56cc 2026-08-05 17:32 UTC now 13h 45185356-2b9f-4d1f-93d1-76521b606553 2026-08-05 19:36 UTC now 11h notarytool log returns "not yet available" for all three. The middle one is a control I built to rule my own bundle out: four lines of C, universal, 100 KB, signed with the same Developer ID certificate, --options runtime --timestamp, no nested code, no entitlements, no provisioning profile. It hangs exactly like the real app. What makes me post rather than just wait is that three other teams are describing the same thing right now: · Kamyab, team XBX2Z359B8 — first three submissions succeeded on 2026-07-31, every one since has been stuck, earliest now well past 26h. Independently reports that a 16 KB signed hello-world hangs exactly like their 40 MB DMG. Developer Program Support case 20000125886455 open since 2026-08-02, no reply yet. · ruththapa, team FYSU26MR78 — two submissions stuck at 68h and 57h, while two others from the same team, same day, same build pipeline and signing configuration were accepted normally. · Dom_W, team TSH4QXMCU8 — brand-new membership, first submissions, 24h+. I've read the additional-analysis answer in the thread from ruththapa, and I understand that first submissions from an unknown account can be held while the system learns to recognise them. That fits my case and Dom_W's. It doesn't seem to fit the other two: Kamyab's first three went through and everything after stopped, and ruththapa had submissions accepted on the same day as the ones that stalled. Those two look like requests entering the queue and not leaving it, rather than an unfamiliar app being examined. Two observations that might narrow it down. Size and content appear to be irrelevant — two of us have now independently confirmed that a signed hello-world of a few kilobytes behaves identically to a full application bundle. And the earliest stuck request anyone has reported is Kamyab's from 2026-07-31 22:40 UTC, which would make this roughly six days old rather than something from today. For completeness on my side: macOS 26.5.2, Xcode 26.6, notarytool 1.1.2 (41). The app is a universal x86_64/arm64 bundle, hardened runtime, secure timestamp, codesign --verify --strict passes and it satisfies its designated requirement. Certificate valid until 2027-02-01, membership active, no pending agreements. Uploads always succeed and return a submission ID; only processing never finishes. Developer ID Notary Service has shown as operational throughout. What would actually help: could someone look at whether these requests are genuinely queued or stuck, and if they are stuck, release or cancel them so the queues can drain? notarytool has no cancel command, so there's nothing any of us can do from the outside. Several of us are blocked on shipping. Happy to provide anything further.

My first notarization submissions have been stuck at "In Progress" for over 24 hours. This is a brand-new Apple Developer Program membership (enrolled this week), and these are the account's first submissions. Team ID: TSH4QXMCU8 Submission IDs (oldest first): c74c1f21-9847-44e7-96f6-a7370fff4fab (created 2026-08-05T00:20:22Z) 182000c9-abd8-47eb-b3fe-45ced930f4c5 (created 2026-08-05T00:58:55Z) d8f3f404-5fe8-47f3-9da3-8e1b278aa7a7 (created 2026-08-05T01:04:52Z) The app is a signed Electron desktop application (Developer ID Application certificate, hardened runtime enabled), submitted as a zip via notarytool through electron-builder. The three submissions are the same app; the duplicates exist because interrupted builds resubmitted. notarytool history shows all three as In Progress. I understand first submissions from new accounts can take longer for in-depth analysis, but at 24+ hours I'd appreciate someone taking a look. Happy to provide any further information.

My notarization submission has been stuck in In Progress for over four days (100+ hours) and I'd appreciate a status check. Submission ID: e1b209de-c30b-42b7-b431-afaf39e9681b Team ID: Q77SU7HBNQ Submitted: July 28, 2026 (late evening, US Eastern) via xcrun notarytool submit Payload: a zip containing a signed macOS app bundle (arm64, Developer ID Application certificate), about 90 MB compressed Additional context: This is a brand-new Developer ID account — these are my first-ever submissions. An earlier submission (2b1c4738…) appeared to be lost entirely: after several hours, notarytool info and notarytool history no longer returned it, so I resubmitted the identical zip as the submission ID above. The current submission definitely exists — notarytool info returns it and reports In Progress on every poll, and has for 100+ hours. I have not resubmitted again, per the guidance in similar threads that first-time submissions can be held for extended analysis. I understand from other threads (e.g. 821679, 818256, 814827, 821858) that first submissions from new accounts can be held for in-depth analysis. Could someone take a look at this submission and let me know whether it is still progressing normally, or whether something is wedged and I should resubmit? Thank you!

Hi — first-time notarization for a newly enrolled individual team. Three submissions, none have resolved. The oldest has been In Progress for just over 18 hours. Team ID: MYFWTHMK9U Submissions (all still "In Progress" as of 2026-08-06T00:29Z): id: 2cab98b4-530c-4b82-9b2f-6580687d935a name: Sunnyside.zip createdDate: 2026-08-05T06:15:41.200Z elapsed: ~18h 13m id: 2d84505e-2379-4633-ab2d-271f7c8c6c50 name: Sunnyside AI.zip createdDate: 2026-08-05T06:28:55.557Z elapsed: ~18h 00m id: 67c5f798-6f33-4da1-94b9-8ed1f8706498 name: SunnysideAI-0.5.0-arm64.dmg createdDate: 2026-08-06T00:19:02.679Z elapsed: ~10m The first two are zipped .app bundles submitted by electron-builder. The third is a DMG I submitted manually, to rule out anything specific to the zip path. No submission from this team has ever reached Accepted or Invalid — every one has stayed In Progress. Environment: macOS 15.7.7 (24G720) Xcode 16.2 (16C5032a) notarytool 1.0.0 (37) Electron 32, electron-builder 25.0.5 Auth: notarytool keychain profile (App Store Connect API key, Developer role) The submissions upload cleanly and notarytool returns a submission ID each time, so credentials and the upload path appear fine. Signing looks correct to me. From the packaged app: $ codesign -dv --verbose=4 "Sunnyside AI.app" Identifier=com.trysunnyside.desktop Format=app bundle with Mach-O thin (arm64) CodeDirectory v=20500 size=772 flags=0x10000(runtime) hashes=13+7 location=embedded Authority=Developer ID Application: Deepu Nair (MYFWTHMK9U) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=5 Aug 2026 at 1:05:39 PM TeamIdentifier=MYFWTHMK9U $ codesign --verify --deep --strict --verbose=2 "Sunnyside AI.app" Sunnyside AI.app: valid on disk Sunnyside AI.app: satisfies its Designated Requirement Hardened Runtime is enabled, the signature carries a secure timestamp, and the nested helper binaries (a Swift ScreenCaptureKit helper in Contents/Resources, plus better_sqlite3.node) are all re-signed under the same Developer ID identity with the runtime flag — I checked each one individually rather than relying on --deep. I've read thread 821552, which describes a very similar situation on a new team. I understand from that thread that first submissions from a new team can be routed for in-depth analysis and take longer than usual. I'm not assuming this is a configuration error on my end — I'd just like to know whether these three are actually progressing, or whether they're wedged and I should resubmit. Since notarytool only reports "In Progress" with no queue position or estimate, there's no way for me to distinguish "still being analyzed" from "stuck". Any visibility into these submission IDs would be appreciated. Thanks.

I'm distributing an open-source command-line tool outside the App Store. Every notarization submission from my team has been stuck "In Progress" since my very first one on 2026-08-01. Fourteen submissions across five days, and not one has ever reached a terminal state — not Accepted, not Invalid, not Rejected. notarytool log returns "not yet available" for all of them, so I have no diagnostic output to work from. Team ID: HYZ2FM38JG Representative submission IDs (all "In Progress"): 3bc8fa7b-f35d-4a70-9b82-4b23b176f746 — 2026-08-01 19:49 UTC, the first submission my team ever made 79455e8c-b1bb-4bc4-9268-5a81b35dfdb7 — 2026-08-03 17:56 UTC 4ecaae74-8b43-4e1d-b18c-c3786d1f8c1e — 2026-08-04 18:11 UTC Plus two fresh submissions made today, 2026-08-05, after a bundle identifier change (see below). Full notarytool history available on request; all fourteen read the same. What I'm submitting: a single Mach-O command-line executable (Rust, arm64 and x86_64 built separately), zipped with ditto -c -k --keepParent <binary> <zip>. No app bundle, no DMG. Each zip is about 2 MB. Signature (codesign -dvvv, today's arm64 build): Identifier=dev.puchalla.trot Format=Mach-O thin (arm64) CodeDirectory v=20500 flags=0x10000(runtime) Authority=Developer ID Application: Marcus Puchalla (HYZ2FM38JG) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=5. Aug 2026 at 11:49:51 TeamIdentifier=HYZ2FM38JG Runtime Version=14.5.0 codesign --verify --strict --verbose=2 reports "valid on disk" and "satisfies its Designated Requirement". Hardened runtime is on, the signature carries a secure timestamp, and there are no entitlements at all, so no get-task-allow. Authentication: App Store Connect API key at Team level, via --key / --key-id / --issuer. Every submission is accepted immediately and returns an ID, so upload and authentication are clearly working — only the processing behind them never runs. Things I have already ruled out: Submission volume / throttling. The very first submission, made on an empty queue, stalled identically. Throttling also rejects at submit time with an error rather than issuing an ID. My CI setup. Some of these submissions come from a GitHub Actions macos-14 runner and others (trot-test.zip) were made by hand from my own Mac with notarytool directly. Both stall the same way, so this follows the account rather than any particular build environment. The bundle identifier. It was com.marcuspuchalla.trot, on a domain I do not own. I changed it today to dev.puchalla.trot, which is reverse-DNS off a domain I do control, and resubmitted. No change — the new submissions sit "In Progress" alongside the rest. (I did not expect this to matter for Developer ID distribution; I mention it so you know it has been eliminated.) Signing problems. Verified above. A signing error would come back Invalid with a log, quickly, rather than as indefinite silence. Expired or unaccepted agreements. Membership active, Program License Agreement accepted, nothing outstanding in the portal or App Store Connect. I understand from other threads here that uploads are sometimes held for in-depth analysis, and that new accounts see this more often — I'm entirely willing to wait if that's all this is. But five days with fourteen submissions and zero completions, including from a brand-new account that has never had a single submission succeed, seemed worth reporting in case something is genuinely wedged on my team's side. Could someone check whether these are actually progressing? One further question, in case it's relevant: I'm submitting a bare Mach-O executable rather than an app bundle, DMG or pkg. It's a command-line tool, so there's nothing to staple to. Is that path handled differently by the analysis pipeline? Every similar report I found here involved a bundle.

Hello, We are experiencing an issue where two recent notarization submissions are stuck indefinitely in the "In Progress" status, with no notarization logs available to inspect. Details for the impacted submissions: Team ID: FYSU26MR78 Submission ID 1: afb11f83-06c2-40c8-89ef-ad7042d1f309 (Submitted: 2026-08-02 05:21 UTC — 68h) Submission ID 2: 65aeb3d0-c204-4906-84c3-f08487989f3f (Submitted: 2026-08-02 16:23 UTC — 57h) Two details that may help narrow this down: Two OTHER submissions from the same team, made within hours of these on the same day, were ACCEPTED normally — including a .dmg of the same application from the same build pipeline and signing configuration. Submission ID 1 has therefore been overtaken by both submissions made before it. Submission ID 2 is a resubmission of the exact same file as Submission ID 1 (byte-identical), made after the first stalled. It is now also stuck, so this does not appear specific to a single upload. The build is a universal (arm64 + x86_64) app signed with a Developer ID Application certificate, hardened runtime enabled, secure timestamp present. codesign --verify --deep --strict passes and the bundle satisfies its Designated Requirement. It is a large bundle — roughly 465 MB .dmg with several thousand nested Mach-O binaries. Uploads succeed and return a submission ID every time; only processing never completes. Is there a known backend delay with the notary service, or can an Apple engineer assist in checking the status of these submission tickets? If they are stuck rather than queued, is there any way to have them cancelled so we can resubmit cleanly? notarytool does not appear to expose a cancel command.

Hello, I am experiencing a very slow macOS notarization submission using xcrun notarytool. Environment: macOS 15.6.1 Xcode 16.0 notarytool 1.0.0 Package type: signed macOS .pkg Package size: approximately 227 MB The package is signed with a valid Developer ID Installer certificate, and local signature verification succeeds. The command reports that the file was uploaded successfully, but the submission remains in In Progress for more than one hour: xcrun notarytool submit <package-path> \ --keychain-profile <keychain-profile> \ --wait Querying the submission with --verbose shows that authentication and status API requests complete successfully with HTTP 200 responses in under two seconds. However, the server-side processing status does not change. xcrun notarytool info <submission-id> \ --keychain-profile <keychain-profile> \ --verbose \ --no-progress The detailed log is also unavailable while the submission is processing: Submission log is not yet available or submissionId does not exist There are also several other submissions in the same account that have remained in In Progress for an extended period. Could you please advise: Is there currently a delay or backlog in the notarization service? Are there account-level submission limits or throttling conditions? Is there a recommended way to obtain more detailed server-side processing diagnostics? Is using --no-wait and polling with notarytool info the recommended workflow for long-running submissions? I can provide the submission identifier and additional diagnostic information privately if required. Thank you.

Hello, We are experiencing an issue where our recent notarization submissions are stuck indefinitely in the "In Progress" status, and no notarization logs are available to inspect. Here are the details for our impacted submissions: Team ID: 34AC638RKM Submission ID 1: 18020127-4742-4d5f-8f56-9742e1aab766 (Submitted: 2026-07-31 13:22 UTC) Submission ID 2: f00b0f39-8b6e-4b80-aaad-dd1690cc7d85 (Submitted: 2026-07-31 21:23 UTC) Prior submissions in June were accepted without issue using the same build pipeline and signing configuration. Is there a known backend delay with the notary service, or can an Apple engineer assist in checking the status of these submission tickets? Thank you!

Team ID: XBX2Z359B8 (Organization, enrolled 2026-07-31) Our first three notarizations succeeded on 2026-07-31: 2c7aee73-5dd3-4971-bc01-fb5e6eb43ae7 19:30:42 UTC Accepted 8f6c46bf-09fb-4ef2-ba29-e93663cbfd54 20:32:26 UTC Accepted a644d9ad-4b18-4bf8-8139-ab193ea40e1e 20:37:44 UTC Accepted Every submission since has been stuck In Progress. None has reached Accepted or Invalid. Earliest stuck request — now over 26 hours: 787e2c7f-8637-48e6-a0c7-0f18c3fd1ce2 2026-07-31 22:40:38 UTC Also stuck: b2fe3ce3-a071-4b23-a261-938e2f58175c 2026-08-01 12:45:39 UTC 26a2d35f-04c5-4309-81c1-3ac042fb58d3 2026-08-01 12:54:47 UTC 66997bd8-2398-41cc-8c28-e11ca1015e4a 2026-08-01 14:48:12 UTC bd05b4bc-d601-44c7-b6ed-b530a674983c 2026-08-01 16:52:12 UTC 3a5611cb-3537-4352-9855-78bf8bb8e2f6 2026-08-01 21:49:20 UTC 844af3e7-0d1d-4326-8ffb-b1ad2b26f781 2026-08-02 00:45:40 UTC I have already contacted Apple Developer Program Support about this — case number 20000125886455, opened 2026-08-02 — and have not yet had a reply. Ruled out: Payload and size — a 16 KB Developer-ID-signed hello-world (844af3e7) hangs exactly like our 40 MB DMG. Artifact type — DMG and ZIP of the .app behave identically. Incomplete upload — submitted with --verbose; upload completes, submission ID returned, every status poll returns 200 "In Progress". Signing — notarytool log for a644d9ad returns "Accepted", "Ready for distribution", issues: []. Developer ID + Hardened Runtime + secure timestamp; codesign --verify --strict --deep passes. Account — membership Active, no pending agreements. 10 submissions total, well under the rate limit. System status shows Developer ID Notary Service as Operational. Since a previously working submission and a 16 KB hello-world now behave identically, this looks like a held request blocking the queue rather than anything in our artifacts. Could someone look into 787e2c7f-8637-48e6-a0c7-0f18c3fd1ce2 and release or cancel it so the queue can drain? This is blocking releases of our app to users and we would be grateful for any help in getting it moving.

Submission UUID: 99192f0b-a0b2-488b-8443-6a6535c300b7 Created: 2026-07-31T09:18:41.522Z Team ID: FNUWX59L8T Artifact: Omitly_2.3.2-beta.2_aarch64.dmg Current status: In Progress (51+ hours) This submission has been In Progress continuously since it was created. I am not asking for it to be rushed — I would like to know whether it is genuinely still being processed, or whether it has failed in a way that will never reach a terminal state, because I cannot tell the difference from the client side and notarytool log is unavailable while it is pending. Before posting I ruled out the causes I could test myself. ┌──────────────────────┬──────────────────────┬─────────────────────┐ │ Created (UTC) │ Artifact │ Result │ ├──────────────────────┼──────────────────────┼─────────────────────┤ │ 2026-07-31T09:18:41Z │ Omitly_…_aarch64.dmg │ In Progress, 51h │ ├──────────────────────┼──────────────────────┼─────────────────────┤ │ 2026-07-31T12:22:38Z │ Probe.zip │ Accepted in ~55 min │ ├──────────────────────┼──────────────────────┼─────────────────────┤ │ 2026-08-02T10:32:37Z │ Probe2.zip │ Accepted in ~41 min │ └──────────────────────┴──────────────────────┴─────────────────────┘ Both probes were a minimal hello-world .app (single arm64 Mach-O, no dependencies), Developer ID signed with hardened runtime using the same identity and same API key. Both returned Accepted / "Ready for distribution" / issues: null. That establishes: the team is configured for notarization (not a 7000 case); certificate and key work end to end; submissions are not serialised behind the stuck one (Probe.zip was submitted three hours later and finished first); and it isn't a weekend effect (Probe2.zip went through on a Sunday morning Pacific in 41 minutes). About the stuck artifact: a Tauri 2 app, arm64, distributed as a DMG. CI verified before submission that the app and every nested Mach-O report Authority=Developer ID Application: with TeamIdentifier=FNUWX59L8T, and that the hardened runtime flag is set. The bundle embeds a qpdf sidecar plus three dylibs (libqpdf.30, libjpeg.8, libcrypto.3) copied from Homebrew, install names rewritten with install_name_tool, then re-signed as part of the bundle. It also ships compressed OCR model data. I appreciate that unfamiliar uploads can be held for additional analysis, and that this is more common for new accounts — this is a recently approved organisation and this was its first submission. My question is whether 51 hours is still within the expected range for that path, or whether this submission is stuck and should be resubmitted.

Since 2026-07-29 every notarization submission for my team (547L3Z8CNP) uploads fine, sits "In Progress" 24h+, then vanishes — notarytool info returns "Submission does not exist." None ever reach Accepted/Invalid. Last success 2026-07-27. Reproduces with a 5.85 KB Developer-ID-signed hello-world (hardened runtime + secure timestamp). codesign --verify --deep --strict is clean; auth works under both an app-specific password and an App Store Connect API key. Submission IDs: 17f9361a-e28d-4cc2-959f-2f3c7ba10325 — In Progress (07-30) f00de349-d449-4539-9d7d-82cac6ef04d7 — now "does not exist" (07-29) 17f1857a-fa44-430f-ad5b-cc42dcc41038 — now "does not exist" (07-29) 4af0cf5d-37e4-4d43-9edf-e78b8594d1db — 5.85 KB probe, In Progress Filed as FB24063069. Anyone else seeing this, or an engineer able to look?

Updating an App for the first time since 2011. Build, Analyze, Archive all successful. Automatically Manage Signing checked. Validation fails with 90286 - Invalid code signing entitlements, and 91130 - Invalid Provisioning Profile dozens of times after tweaks, clean builds, trying manual signing (thought I was done with that), etc. For 90286 it seems my Developer ID , e.g. 346JXXXXX (not Team ID, QZ99XXXXX) is the prefix for the bundle ID, com.company.app-name and that generates the error? For 91130 it's invalid "com.apple.application-identifier" which I assume is the same issue with a Developer ID instead of a Team ID. The original version of the app was QZ99XXXXX.com.company.app-name. I even changed the bundle identifier in Xcode to that, and got this: App Record Creation failed due to request containing an attribute already in use. The app name you entered is already being used for another app in your account. If you would like to use the name for this app you will need to submit an update to your other app to change the name, or remove it from App Store Connect. Yes, the original app name is being used for an app in my account. I was trying to update the app, checked all the boxes, added update text, but of course there was no build to upload. Would appreciate any help.