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.

Hey Quinn, another update. At this point everything except my two original Accepted builds has disappeared from the system. notarytool history now shows only the two that went through on June 2 and June 3. Every other submission, going all the way back to early June that was stuck In Progress is gone, and notarytool info on any of those IDs returns "Submission does not exist or does not belong to your team." None of them ever flipped to Accepted or Invalid. There was never an outcome email or a log to pull. The one thing that has changed is the timing. The early June submissions sat at In Progress for weeks, some close to a month, before they eventually dropped off. My most recent submissions are failing much faster: the four I sent over the last two days each showed In Progress in history right after I submitted, then disappeared within 24 hours. I did not catch the exact moment they dropped, but they were gone inside the day. The four most recent, all now returning "does not belong to your team": f0afb08f-c039-4d0b-99e6-62a1e86f61a7 Dockside-1.6.2.dmg (Jul 5, 03:50 UTC) e1cbc151-ba6e-46cc-9645-532ff07a6489 Dockside-1.6.2-arm64.dmg (Jul 5, 03:49 UTC) bed02f50-03db-4e5f-b271-97c18072c14c Dockside-1.7.0.dmg (Jul 6, 15:19 UTC) 8b1782c7-df50-476c-bf06-f4ba65a1af39 Dockside-1.7.0-arm64.dmg (Jul 6, 15:18 UTC) So the end result is the same across dozens of attempts where nothing completes, and the submissions eventually get dropped from the system entirely. The only two that ever succeeded are still the two from June 2 and June 3, both Accepted. Signing setup is unchanged and I re-verified it again: Developer ID Application, hardened runtime with a secure timestamp, no get-task-allow, universal native module inside the app, and codesign --verify --deep --strict passes clean and satisfies the Designated Requirement. It is identical to the two builds that came back Accepted, so I am confident this is not a signing problem on my end. It has now been over a month and this is still the only thing blocking my launch. Happy to pull anything else that would help. Thanks again for staying with this.

And the log attempt on the same ID returns nothing: % xcrun notarytool log a4a00bca-8c8a-470e-b5e8-cd12502166e0 --keychain-profile dockside Submission log is not yet available or submissionId does not exist id: a4a00bca-8c8a-470e-b5e8-cd12502166e0 So 16 days in: info says "In Progress" with no message or issues, and log says the log isn't available yet. The submission ID clearly exists (info resolves it fine), it's just never reached a state where a log gets generated.

Here's what I see % xcrun notarytool info a4a00bca-8c8a-470e-b5e8-cd12502166e0 --keychain-profile dockside Successfully received submission info createdDate: 2026-06-02T01:13:38.226Z id: a4a00bca-8c8a-470e-b5e8-cd12502166e0 name: Dockside.zip status: In Progress

No worries at all, thanks for circling back. Yes, still stuck unfortunately. You're right: a4a00bca-8c8a-470e-b5e8-cd12502166e0 is the oldest, created June 2 and it's now been "In Progress" about 16 days. Since we last spoke I've made meaningful progress on the build, and I'm now at the point of launching. Notarization is the one and only blocker left before I can distribute. I'm at 23 submissions total since June 2: 2 Accepted, 21 still stuck "In Progress," none reaching a terminal state. Same signing throughout, and the 2 that passed confirm the setup is fine. My latest build is 1.6.2 (June 17), and it's stuck along with everything else: 9b1f37c6-8333-4689-bd17-7b485bd407dd — 1.6.2, Jun 17 9ab65288-64f5-433c-8a2f-0b6cc7908106 — 1.6.2 arm64, Jun 17 826d5318-211e-4253-9d81-fdd46efe8e8b — 1.6.1, Jun 16 8b9c2b0e-3fa0-4578-ae7e-4ef21e7eb9d9 — 1.6.1 arm64, Jun 16 So a4a00bca is the oldest, but 1.6.2 is the current release I'm trying to ship. Happy to send the full list of all 21 if helpful. Anything that gets these moving would unblock the launch. Appreciate the help!

Hey Quinn, a status update since it's now been over a week. Since June 2 I've submitted 17 times. 2 came back Accepted. 13 are still stuck at "In Progress" with no terminal state. The oldest has been sitting around 234 hours now (June 2), there's a group from June 3 at about 200 hours, and another from June 6 at 130-plus hours. The two newest are from today so I'm not counting those. Same as before, the signing checks out on all of them, codesign --verify --deep --strict passes, hardened runtime with a secure timestamp, no get-task-allow, Developer ID, and the DMGs are signed before submission. One thing I noticed: it doesn't seem to be architecture or format specific. One of the two that went through was an x64 DMG, but other x64 DMGs from the same builds are among the stuck ones, with identical signing. So it really looks like the service is just not processing most of what I send. Here are the stuck submission IDs, oldest first, in case they help: a4a00bca-8c8a-470e-b5e8-cd12502166e0, Jun 2 c7d6a78c-eb77-42f3-bcac-bee5c45087ce, Jun 2 17231cbb-f3d7-4515-a332-3412aa9383eb, Jun 2 03a9f77a-b9e6-4c87-a248-578d0ed658a4, Jun 2 b0370f43-d853-40db-8baa-fde0802c0d15, Jun 3 86cea307-bf66-4e96-bc74-425f9c628fa9, Jun 3 06870927-c658-4eca-abce-abcbf03b9e05, Jun 3 a501ba81-1f40-439b-8317-4fb836cd6d92, Jun 6 fedfb6c6-0816-4f9d-916d-d6444207a2d8, Jun 6 865404c2-0986-48d4-8c76-f82886549d70, Jun 6 a6d39244-0d08-4ae6-84ba-8a91d8f294d9, Jun 6 beb2e92a-4141-438d-af92-4215cd221579, Jun 7 e7a4fc67-8e44-456c-887b-f3132ab16f36, Jun 7 I get from the Q&A that held submissions should complete eventually, and I'm not trying to rush the new-account evaluation, but ten days with no movement on the oldest ones is past the point where waiting feels right, and it's holding up a shipping app. Is there any way to get these specific IDs looked at on the back end, rather than waiting them out further? FB22939442 is still open and so is my Developer Support case. Thanks again your help and happy to provide any more details!

@tginart did you ever find a solve? I'm attempting to notarize a new app and have had a couple of random successful accepts but 10+ submissions just sitting in progress for days and days now

Thanks Quinn, this is really helpful. I went through the notary service Q&A and it lines up with what I'm seeing, a new app from a new Developer ID getting extra evaluation while the system builds a profile of it. That makes sense. One practical question. Several of my submissions are now held at "In Progress" anywhere from about 73 hours up to over 106 hours (more than four days) without completing. A couple of others did go through and came back Accepted, so I know the signing and credentials are good. For the ones held this long, should I expect them to finish on their own eventually, or is it better to stop waiting on those and just keep submitting updated versions so newer uploads can go through as the system learns my app? Mostly want to make sure I'm not sitting on submissions that are effectively stuck. Happy to share the specific submission IDs if that helps. Thanks again.