Post

Replies

Boosts

Views

Activity

All three notarization submissions stuck In Progress since 2026-08-17, after a successful submission on 2026-08-12
Hi, I'm reporting three notarization submissions that have all been stuck in the "In Progress" state today. I'm posting mainly to ask whether my team has been pulled into in-depth analysis, since as far as I know there is currently no way to determine that from the client side. Team ID: SE3B3RM5Y4 === Stuck submissions (all still "In Progress" as of 2026-08-17 12:15Z) === 99722c12-dc10-4098-88be-84b7b58ff1f4 created 2026-08-17T07:51:19Z a41cf8fe-8883-4073-a043-5143323407da created 2026-08-17T09:45:11Z 35746a17-d332-4398-a353-cd7b1d8520ac created 2026-08-17T11:34:55Z notarytool info returns status "In Progress" with no message field for all three. No errors, no rejections - they simply have not moved. === Immediately prior submission, same pipeline, succeeded === a9138c72-41ee-4b42-adcf-78851eb3e5c7 created 2026-08-12T10:58:00Z Accepted That submission was Accepted in roughly 25 minutes. Every submission before it (2026-08-09 x2, 08-06, 07-26, 07-21, 07-15, 07-09) was also Accepted within a similar window. Today's three are the first that have not completed. === Why I believe this is team-scoped rather than a bad package === The three submissions are not retries of one another: 99722c12 and a41cf8fe are the same app version (1.3.1). 35746a17 is a different build of a different app version (1.3.2), produced from a newer source tree, with different content and a different zip. It was submitted almost 4 hours after the first one and was stuck immediately as well. So a fresh, independently produced package entered the same stuck state right away. That seems more consistent with a team-level hold than with a problem in any individual package. I understand from previous threads that once a team enters in-depth analysis, it affects all notarizations for that team until the state clears, which appears to match what I'm seeing. === What changed between the last successful submission and today === I want to disclose this in case it is relevant to the analysis: Package size grew from ~635 MB to ~751 MB (+116 MB, +18%) for the signed .zip. This is one of the larger single-release size increases in this app's history. A bundled third-party command-line helper was updated to a much newer release. It ships its own separately Developer ID-signed Mach-O executable, so while the file path and its signing identity are unchanged from previous releases, the actual binary content is almost certainly different from what was notarized on 2026-08-12. The app's own main executable is rebuilt every release, so its content always differs between releases. That has never caused a delay before. No new kinds of executables, dylibs, or runtimes were added to the bundle. I verified this by diffing the packaging scripts and the bundle tree: there are no newly introduced binary types, and no new entitlements. The Hardened Runtime entitlements are byte-for-byte identical to the 2026-08-12 build. === What I've already checked === Signing identity is a valid, unexpired Developer ID Application certificate. codesign -vvv --deep --strict passes on the app before submission. Hardened Runtime is enabled; entitlements unchanged from the accepted build. The Developer ID Notary Service shows as operational on the system status page. I am nowhere near the documented submission rate limits (3 submissions today). App-specific password and credentials are valid - notarytool history authenticates and returns results normally. === Environment === macOS host: Apple silicon Xcode command line tools, xcrun notarytool submit --wait Electron-based application, packaged with electron-builder Signed zip: ~751 MB === My questions === Is there any way to confirm from my side whether these submissions have been routed into in-depth analysis? I understand this is a known and frequently requested feature, but I want to make sure I'm not missing an existing diagnostic. Given that these are only a few hours old, I understand this is well below the threshold at which it makes sense to investigate individual submissions. I'm happy to wait. I'd just like to confirm whether waiting is in fact the correct action here, or whether there's anything in the changes described above that I should address on my end before resubmitting. Is submitting an additional build while earlier submissions are still pending harmful in any way? I've read that it's acceptable, but I want to confirm I'm not making the queue situation worse for my own team. I will update this thread when the state resolves, including how long it took, so there's a data point on the record. Thanks very much for your time.
2
0
313
4h
All three notarization submissions stuck In Progress since 2026-08-17, after a successful submission on 2026-08-12
Hi, I'm reporting three notarization submissions that have all been stuck in the "In Progress" state today. I'm posting mainly to ask whether my team has been pulled into in-depth analysis, since as far as I know there is currently no way to determine that from the client side. Team ID: SE3B3RM5Y4 === Stuck submissions (all still "In Progress" as of 2026-08-17 12:15Z) === 99722c12-dc10-4098-88be-84b7b58ff1f4 created 2026-08-17T07:51:19Z a41cf8fe-8883-4073-a043-5143323407da created 2026-08-17T09:45:11Z 35746a17-d332-4398-a353-cd7b1d8520ac created 2026-08-17T11:34:55Z notarytool info returns status "In Progress" with no message field for all three. No errors, no rejections - they simply have not moved. === Immediately prior submission, same pipeline, succeeded === a9138c72-41ee-4b42-adcf-78851eb3e5c7 created 2026-08-12T10:58:00Z Accepted That submission was Accepted in roughly 25 minutes. Every submission before it (2026-08-09 x2, 08-06, 07-26, 07-21, 07-15, 07-09) was also Accepted within a similar window. Today's three are the first that have not completed. === Why I believe this is team-scoped rather than a bad package === The three submissions are not retries of one another: 99722c12 and a41cf8fe are the same app version (1.3.1). 35746a17 is a different build of a different app version (1.3.2), produced from a newer source tree, with different content and a different zip. It was submitted almost 4 hours after the first one and was stuck immediately as well. So a fresh, independently produced package entered the same stuck state right away. That seems more consistent with a team-level hold than with a problem in any individual package. I understand from previous threads that once a team enters in-depth analysis, it affects all notarizations for that team until the state clears, which appears to match what I'm seeing. === What changed between the last successful submission and today === I want to disclose this in case it is relevant to the analysis: Package size grew from ~635 MB to ~751 MB (+116 MB, +18%) for the signed .zip. This is one of the larger single-release size increases in this app's history. A bundled third-party command-line helper was updated to a much newer release. It ships its own separately Developer ID-signed Mach-O executable, so while the file path and its signing identity are unchanged from previous releases, the actual binary content is almost certainly different from what was notarized on 2026-08-12. The app's own main executable is rebuilt every release, so its content always differs between releases. That has never caused a delay before. No new kinds of executables, dylibs, or runtimes were added to the bundle. I verified this by diffing the packaging scripts and the bundle tree: there are no newly introduced binary types, and no new entitlements. The Hardened Runtime entitlements are byte-for-byte identical to the 2026-08-12 build. === What I've already checked === Signing identity is a valid, unexpired Developer ID Application certificate. codesign -vvv --deep --strict passes on the app before submission. Hardened Runtime is enabled; entitlements unchanged from the accepted build. The Developer ID Notary Service shows as operational on the system status page. I am nowhere near the documented submission rate limits (3 submissions today). App-specific password and credentials are valid - notarytool history authenticates and returns results normally. === Environment === macOS host: Apple silicon Xcode command line tools, xcrun notarytool submit --wait Electron-based application, packaged with electron-builder Signed zip: ~751 MB === My questions === Is there any way to confirm from my side whether these submissions have been routed into in-depth analysis? I understand this is a known and frequently requested feature, but I want to make sure I'm not missing an existing diagnostic. Given that these are only a few hours old, I understand this is well below the threshold at which it makes sense to investigate individual submissions. I'm happy to wait. I'd just like to confirm whether waiting is in fact the correct action here, or whether there's anything in the changes described above that I should address on my end before resubmitting. Is submitting an additional build while earlier submissions are still pending harmful in any way? I've read that it's acceptable, but I want to confirm I'm not making the queue situation worse for my own team. I will update this thread when the state resolves, including how long it took, so there's a data point on the record. Thanks very much for your time.
Replies
2
Boosts
0
Views
313
Activity
4h