I'm hitting what looks like a service-side notarization problem and could use a pointer on how to get it escalated.
Over the past 3 days I've submitted 9 times with notarytool. Only 2 came back Accepted. The other 7 are stuck at "In Progress" and never reach a terminal state, no Accepted, no Invalid, no log (notarytool log says it isn't available yet), and no email. The oldest has been sitting ~71 hours.
Signing checks out: codesign --verify --deep --strict passes and satisfies the Designated Requirement, hardened runtime with a secure timestamp, no get-task-allow, signed with my Developer ID, and the DMGs are signed before submission. The 2 submissions that completed were Accepted, so credentials and signing are fine. It really looks like the service just isn't processing most of my submissions.
This is a newly enrolled account, and I've filed FB22939442 and have an open Developer Support case.
Is this a known issue for new accounts, and is there a way to get these submissions looked at?
Environment: macOS 26.2, Xcode 26.5, notarytool 1.1.2 (41).
Good news first! I'm unblocked and shipping. With your nudge toward the upload I found a path that works, and the release is out and installing cleanly, including on a locked-down managed work Mac. So thank you, that pointer made the difference.
The way I got there: I moved notarization off my Mac and onto a GitHub Actions runner with a small retry loop that resubmits until an attempt gets through, and then I staple locally. That has been reliable and both DMGs came back Accepted on their initial notarization attempt.
I also dug into why it was failing locally, and wanted to pass along what I saw in case it is useful to the team. None of this is conclusive and I am definitely no expert, but here is what I found.
notarytool seems to be crashing on my end partway through the upload. Each submission gets an ID, starts the multipart upload, completes a few chunks, and then exits with "zsh: bus error." That lined up with my original report, where submissions sat at In Progress, never resolved, and then disappeared a day or so later. If the upload never finishes, that would explain why there was never an outcome email or a log to pull.
From the crash reports, as best I can tell, it looks like a stack overflow from some kind of runaway recursion. The parts that stood out:
- Exception: EXC_BAD_ACCESS (SIGBUS), subtype "Could not determine thread index for stack guard region," with the fault landing in the Stack Guard region.
- Faulting thread queue: nio.nioTransportServices.connectionchannel.
- The stack shows the same small set of notarytool frames repeating over and over, through String.init(format:) into __CFStringAppendFormatCore, until it runs out of stack.
- It crashes a few chunks into the upload of a roughly 328 MB DMG, and the chunk where it dies is different every run (I saw 0, 1, 4, and 16 of 66), so it feels timing related rather than anything about the file itself.
My best guess is that a network change happening during the upload might be triggering it. My Mac has a lot of iCloud Continuity and Handoff activity (rapportd creating and removing utun tunnels for AirDrop, notifications, and so on), and quieting some of that down (Bluetooth off, Handoff off, awdl0 down, even pausing rapportd and sharingd) seemed to let the upload get further before crashing, though it never fully stopped. It also happened on a second Mac and occasionally on a GitHub-hosted macos-latest runner, so it does not seem specific to my machine.
Just wanted to share this in case it helps you all track down whatever is going on, since it seems like it could affect other people notarizing larger files.
I have .ips crash reports and can attach them here. I did attach them on the Feedback (FB22939442) with my update on that that ticket for the team. Thanks again for all the help.
