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.

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?

ID：f73305f0-c566-482d-ab2d-84082e9b8634 status: In Progress 详情：2026-07-24 ，应用签名 ->提交公证 -> 公证一直无法成功 In Progress，请帮忙检查并解决

All notarization submissions from our team are stuck at “In Progress”; none has reached a terminal state (neither Accepted nor Invalid). Environment • Team ID: F2Q623H7F9 • Developer ID Application certificate issued 2026-07-25 18:35 UTC. These are this team's first-ever notarization submissions — there is no prior successful notarization to compare with. • Auth: App Store Connect API key (.p8 + key ID + issuer ID), not an Apple ID password. • Submitted with • Payload: xcrun notarytool submit from GitHub-hosted macos-14 runners, not a local Mac, so a client-side upload crash is not a factor. ditto -c -k --keepParent zip of Mel.app, ~17 MB — a native Rust/egui desktop app. Not Electron; no accessibility APIs. Stuck submissions — all three still “In Progress”, confirmed via both xcrun notarytool info and independently via the Notary REST API ( GET /notary/v2/submissions/{id} ): 1. 8ad4dde0-06f1-43b5-acf4-2847b4cce10e — created 2026-07-25 21:39:24 UTC (oldest; 17+ hours elapsed) 2. 9d60e50e-474c-41f6-920d-1b4a1e1f57b4 — created 2026-07-26 10:24:32 UTC 3. cea068bb-6ffa-4a18-ba49-0dec625071ca — created 2026-07-26 11:25:48 UTC Every upload was accepted (“Successfully uploaded file”). None was rejected. xcrun notarytool log returns “Submission log is not yet available”, which we understand is expected for a non-terminalsubmission. Signing verified locally before each submission codesign --force --deep --timestamp --options runtime --entitlements /mel.entitlements --sign "Developer ID Application: … (F2Q623H7F9)" Mel.app codesign --verify --deep --strict --verbose=2 Mel.app → “Mel.app: valid on disk” and “Mel.app: satisfies its Designated Requirement”. Hardened runtime enabled; secure timestamp present. Service status — the Developer ID Notary Service has shown “Operational” on developer.apple.com/systemstatus for the entire window covering all three submissions. What we have deliberately not done — we have stopped resubmitting. We understand that re-uploading the same build only adds backlog for the service to grind through once the state clears, so we are holding at three submissions and polling instead of retrying. Request — we are not asking for a rejection reason; nothing has been rejected. We are reporting the UUIDs and creation dates as the guidance asks, so these can be distinguished from orphaned submissions that will never reach a terminal state. Question: Are a new team's first submissions subject to an extended review period, and if so what completion time should we expect for 8ad4dde0-06f1-43b5-acf4-2847b4cce10e?

The notary service requires that all Mach-O images be linked against the macOS 10.9 SDK or later. This isn’t an arbitrary limitation. The hardened runtime, another notarisation requirement, relies on code signing features that were introduced along with macOS 10.9 and it uses the SDK version to check for their presence. Specifically, it checks the SDK version using the sdk field in the LC_BUILD_VERSION Mach-O load command (or the older LC_VERSION_MIN_MACOSX command). There are three common symptoms of this problem: When notarising your product, the notary service rejects a Mach-O image with the error The binary uses an SDK older than the 10.9 SDK. When loading a dynamic library, the system fails with the error mapped file has no cdhash, completely unsigned?. When displaying the code signature of a library, codesign prints this warning: % codesign -d vvv /path/to/your.dylib … Library validation warning=OS X SDK version before 10.9 does not support Library Validation … If you see any of these errors, read on… The best way to avoid this problem is to rebuild your code with modern tools. However, in some cases that’s not possible. Imagine if your app relies on the closed source libDodo.dylib library. That library’s vendor went out of business 10 years ago, and so the library hasn’t been updated since then. Indeed, the library was linked against the macOS 10.6 SDK. What can you do? The first thing to do is come up with a medium-term plan for breaking your dependency on libDodo.dylib. Relying on an unmaintained library is not something that’s sustainable in the long term. The history of the Mac is one of architecture transitions — 68K to PowerPC to Intel, 32- to 64-bit, and so on — and this unmaintained library will make it much harder to deal with the next transition. IMPORTANT I wrote the above prior to the announcement of the latest Apple architecture transition, Apple silicon. When you update your product to a universal binary, you might as well fix this problem on the Intel side as well. Do not delay that any further: While Apple silicon Macs are currently able to run Intel code using Rosetta 2, that support is going away soon. About the Rosetta Translation Environment says: Rosetta … will be available through macOS 27 … Beyond this timeframe, we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles But what about the short term? Well, I’m glad you asked! Xcode includes a command-line tool, vtool, that can change the LC_BUILD_VERSION and LC_VERSION_MIN_MACOSX commands in a Mach-O. You can use this to change the sdk field of these commands, and thus make your Mach-O image ‘compatible’ with notarisation and the hardened runtime. Before doing this, consider these caveats: Any given Mach-O image has only a limited amount of space for load commands. When you use vtool to set or modify the SDK version, the Mach-O could run out of load command space. The tool will fail cleanly in this case but, if it that happens, this technique simply won’t work. Changing a Mach-O image’s load commands will break the seal on its code signature. If the image is signed, remove the signature before doing that. To do this run codesign with the --remove-signature argument. You must then re-sign the library as part of your normal development and distribution process. Remember that a Mach-O image might contain multiple architectures. All of the tools discussed here have an option to work with a specific architecture (usually -arch or --architecture). Keep in mind, however, that macOS 10.7 and later do not run on 32-bit Macs, so if your deployment target is 10.7 or later then it’s safe to drop any 32-bit code. If you’re dealing with a Mach-O image that includes 32-bit Intel code, or indeed PowerPC code, make your life simpler by removing it from the image. Use lipo for this; see its man page for details. It’s possible that changing a Mach-O image’s SDK version could break something. Indeed, many system components use the main executable’s SDK version as part of their backwards compatibility story. If you change a main executable’s SDK version, you might run into hard-to-debug compatibility problems. Test such a change extensively. It’s also possible, but much less likely, that changing the SDK version of a non-main executable Mach-O image might break something. Again, this is something you should test extensively. This list of caveats should make it clear that this is a technique of last resort. I strongly recommend that you build your code with modern tools, and work with your vendors to ensure that they do the same. Only use this technique as part of a short-term compatibility measure while you implement a proper solution in the medium term. For more details on vtool, read its man page. Also familiarise yourself with otool, and specifically the -l option which dumps a Mach-O image’s load commands. Read its man page for details. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision history: 2026-07-24 — Updated to reference Apple’s publicly announced plans for Rosetta 2. 2025-04-03 — Added a discussion of common symptoms. Made other minor editorial changes. 2022-05-09 — Updated with a note about Apple silicon. 2020-09-11 — First posted.

All our workflows started to fail today due to timeouts - the notarization process is unable to finish in under 1 hour. The latest submission ID that failed after 45mins: 7449abcb-0d24-441b-a992-d5c7e7d279e3 It has never been a problem for us for the past years - is there something off on Apple side?

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: e48ead02-a837-42cd-9d90-c4c0f014e589 However, the notarization has remained in: Status: In Progress for more than 2 hours. Running both: xcrun notarytool info and xcrun notarytool history continues to report: Status: In Progress No notarization log is available yet. I have already contacted Apple Developer Support, but I wanted to ask the community: Is it normal for a notarization submission to remain "In Progress" for several hours? Has anyone experienced this recently and eventually received an "Accepted" status? Could this indicate a temporary Apple-side queue or backend issue? Any insight would be greatly appreciated. Thank you.

Title: First notarization submissions stuck "In Progress" (new Developer ID account) Hello, Our first-ever notarization submissions are stuck at "In Progress": d1009b64-8c1c-4d78-bb18-f5b3f1135e72 — submitted 2026-07-21 08:54 UTC a5915e00-8f39-415d-a2de-945dedbbfa69 — the same file, resubmitted 2026-07-21 12:10 UTC Team ID: 9NAR899PX9 The file is a small (~5 MB) macOS utility (Klipto.zip). It passes strict codesign verification with a valid Developer ID Application certificate and hardened runtime enabled. These are the account's first submissions, so we understand extended analysis is expected — but could you please check whether they are held and help unblock them? Thank you! — Margarita at Klipto

Hi — I'm hoping someone from the Notary team can take a look. This is the FIRST notarization on a brand-new individual Developer ID account, and every submission has been stuck at "In Progress" for well over 40 hours. Normal submissions for me would be expected in minutes. Team ID: 4FT9BQJ765 Submissions (all still "In Progress" as of 2026-07-20 21:00 UTC): 08953b37-a6a7-43a3-bf76-0bb7d7450b10 (.dmg) submitted 2026-07-19 01:33 UTC (~43h) 3b1c0d76-11e9-4689-b699-e247b4659c5e (.zip) submitted 2026-07-19 01:09 UTC (~44h) 9025ba6f-0f7e-4137-888c-8ca4c7a2f42b (.zip) submitted 2026-07-18 22:44 UTC (~46h) What I've verified: My very first submission (9d595afa-5603-42b4-9ac9-0ea638c7eca0) returned "Invalid" within ~3 minutes with real signature errors (unsigned nested dylibs). I fixed those — signed every nested Mach-O inside-out with --options runtime --timestamp using my Developer ID Application cert — so the pipeline and my account clearly work. Since fixing the signature, every re-submission just hangs at "In Progress" and never completes (both .zip of the .app and a signed .dmg). Signature checks pass locally: codesign --verify --deep --strict is clean, hardened runtime is enabled, secure timestamp present, and the Developer ID Application cert is valid. The pattern matches other "first notarization on a new account stuck for 24-48h" reports here. Could someone please manually push these submissions through (or let me know if something on the account side needs attention)? Tools: notarytool (Xcode 26), macOS 25, Apple Silicon (arm64). Thanks very much.

I enrolled as an individual Apple Developer on 2026-07-18 (Team ID W6ZKZYL87M) and I'm setting up Developer ID notarization for a macOS app distributed outside the App Store (notarytool + Developer ID Application signing). My first notarization submissions have been stuck at status "In Progress" and have never completed: notarize.zip — submitted 2026-07-18 15:34 UTC — id 9787a18e-e4a7-44cc-abe4-94900f51d336 — still In Progress (~54h) probe.zip — submitted 2026-07-19 13:23 UTC — id 0f7db26d-5abb-468a-9ea5-1bec4f71e1cf — still In Progress (~33h) The second submission (probe.zip) is a trivial ~8 KB Mach-O, locally signed with hardened runtime + secure timestamp, submitted purely to isolate the variable — and it is stuck exactly like the real app. This strongly suggests an account-level hold rather than a problem with any particular package. What I've already verified: Developer ID Notary Service is green on the system status page; submissions enter the queue with no error (no 403 / 7000 / auth failure — I authenticate with an App Store Connect API key); I am NOT re-submitting in a loop; agreements look in order in App Store Connect. This matches the documented "in-depth analysis / notarization profile-building" behavior for newly enrolled accounts, but 50+ hours is past the typical 24-72h window, so I would appreciate a check on whether my account is pending notarization profile provisioning or team configuration. I have an open Developer Support ticket (case 102946182596) but am raising it here in case a DTS engineer can look at the account state. Team ID: W6ZKZYL87M

Team ID: Y6YAJ7YNT2 (Individual) App: Variable Visualizer (com.variablevisualizer.app) Signed with Developer ID Application (G2), Hardened Runtime enabled. Submitted via notarytool + App Store Connect API key. Three submissions all stuck In Progress with no logs: 2debeb8f-9a67-4bb6-9ec6-31f4245cb469 created 2026-07-18T08:55:40Z 6299bcc0-40ee-4e9a-95ec-993e2e01b726 created 2026-07-18T09:11:19Z 5fa55506-88c7-4f10-9f2e-0f288c2b3961 created 2026-07-18T14:47:07Z Stapler returns CloudKit Record not found (Error 65). Apple Developer Program License Agreement accepted. Developer system status normal. Also filed Developer Support case 102945911358. These are the first notarization submissions for this app/team. Can someone on the notarization side check whether these are held for first-time deep analysis, or whether the team needs configuration? Thank you.

Team ID: U4TKZ5TH92 (individual enrollment, first-ever submissions) Submissions (UTC): 2026-07-18 04:45:23 a186c59f-bf3b-4ac9-9780-248045a2eda9 Sentry-notarize.zip -> Invalid in ~5 minutes. Legitimate (unsigned nested binaries); fixed and verified with codesign before resubmitting. 2026-07-18 04:50:13 055e92dc-3a88-42bd-b2df-dc7c30c02443 Sentry-notarize.zip -> In Progress, 38+ hours, no log available 2026-07-18 22:34:41 7db6ada0-f3f8-4bf8-80e5-404e59425321 NotaryTest.zip (16 KB) -> In Progress, 19+ hours The third submission is a deliberate minimal reproducer: a copy of /bin/echo inside a bare .app, Developer-ID signed with --options runtime --timestamp, a single Mach-O, no nested code, 16 KB total. It has now been In Progress for over 19 hours. A package that small cannot plausibly require extended analysis, which points to an account/team-level issue rather than package content. Note the FIRST submission was processed and returned Invalid within about five minutes, so the notary service was working for this account earlier the same day. Something changed between 04:45 and 04:50 UTC. Environment: Developer ID Application certificate valid (verified via security find-identity, G2 intermediate installed), notarytool credentials validated successfully via store-credentials, Developer ID Notary Service shows Available on the system status page. One possibly relevant detail: I have a WITHDRAWN organization enrollment (9L795ANY7S) on the same Apple ID, withdrawn for a website-verification failure. Could that withdrawal affect notarization for my individual team U4TKZ5TH92? Could someone check the backend notary queue status for team U4TKZ5TH92? Support case 102943331355 is open but has so far been routed to enrollment rather than notarization.