All notarization submissions stuck "In Progress" — including a 210-byte test payload (Team SSHD524FKZ)

Question

Created 1d

Replies 2

Boosts 0

Participants 2

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.

Answered by DTS Engineer in 900574022

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for additional analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays.

For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive.

This includes a deliberately trivial test payload

Indeed. Once a request is subject to additional analysi, you’ll generally see that all subsequent requests wait behind it.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 1

DTS Engineer OP

Apple

22h

Accepted Answer

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for additional analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays.

For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive.

This includes a deliberately trivial test payload

Indeed. Once a request is subject to additional analysi, you’ll generally see that all subsequent requests wait behind it.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 2

e-muavin OP

15h

Thank you Quinn — that explains it, and the behaviour you described is exactly what we observed.

All three of the original submissions eventually came back Accepted, and the 210-byte test payload correctly came back Invalid. So nothing was actually broken; my test payload was simply queued behind the request that had been pulled in for additional analysis, which is the head-of-line behaviour you described. I had assumed a small unsigned payload would be evaluated independently, and that assumption was wrong.

The "the system will learn to recognise them" part is also very visible in the numbers. For the record, in case it helps anyone finding this thread later:

First submissions: roughly 36 hours before completing.
Today's release build, same app, four submissions back to back (two .app archives and two .pkg installers, arm64 and x86_64): all four Accepted, each within about two minutes. The whole build finished in under ten minutes.

So the practical advice for anyone hitting this on a first Developer ID build appears to be: wait, and do not resubmit. Resubmitting only adds more work behind the request that is already being analysed.

Thanks also for the Notarisation Resources link — the Q&A with the notary service team answered several other questions I had.