Search results for

“codesign”

3,221 results found

Post

Replies

Boosts

Views

Activity

Reply to PCI Transport Entitlements
There are some key things to keep in mind here: Your provisioning profile acts as an entitlement allowlist. Your .entitlements file is source code that feeds into the code signing machinery. The entitlements claimed by your app are baked into the app’s code signature. Likewise for embedded app extensions, DEXTs, and so on. The fact that you’ve been granted access to a capability lets you create an provisioning profile that authorises your use of the associated entitlements. However, you still have to claim that access, by updating your .entitlements file. You can then verify that the claim and the profile are in sync using the codesign and security tools, respectively. For the exact commands, and more general background, see TN3125 Inside Code Signing: Provisioning Profiles. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: App & System Services SubTopic: Core OS Tags:
2w
Title Notarization submissions stuck “In Progress” for 5+ days (SwiftUI macOS menu bar app)
Notarization submissions stuck “In Progress” for 5+ days (SwiftUI macOS menu bar app) Hello, I’m experiencing an issue where all notarization submissions remain “In Progress” for several days. Environment macOS native app written in Swift / SwiftUI Menu bar application Built with Xcode Developer ID Application signing Hardened Runtime enabled App Sandbox disabled Uses SMAppService for “Start at Login” Artifact structure ClaudeUsageTracker.zip └ ClaudeUsageTracker.app (no nested directory) Verification codesign --verify --deep --strict --verbose=2 ClaudeUsageTracker.app This succeeds without errors. Notarization submissions 2026-03-06 — In Progress ID=215814fc-57c5-4f99-88fe-ed2db4d3e3d9 2026-03-06 — In Progress ID=70948178-191c-4840-a9c7-52c321b725e5 2026-03-09 — In Progress ID=14a88b79-df4d-4d83-9bfe-fa6eafc9bf76 All submissions remain In Progress for 5+ days, and notarytool log is not available yet. Command used xcrun notarytool submit ClaudeUsageTracker.zip --keychain-profile notarytool-profile T
9
0
391
2w
Unable to enable eligibility for External Purchase Link APIs — seeking clarification
Hello, I am currently implementing External Purchase Link and External Purchase Custom Link and am encountering an issue where both ExternalPurchaseLink.canOpen and ExternalPurchaseCustomLink.isEligible always return false under all test conditions. I would like to confirm whether my setup is missing any required steps or whether this behavior is expected. Below are the details of my current environment and configuration: 🔧 1. Development Environment Xcode: 16.3, 16.4, 26.0 beta 4 Devices: iPhone running iOS 26.2 beta iPhone running iOS 16.7.12 macOS 15.5 (real device testing) Simulator iOS 18.0 Build Type: Local development build using a Developer Provisioning Profile Sandbox account signed in during testing 🔑 2. Entitlements (Developer site & Xcode) In Certificates → Identifiers → App ID, both capabilities are enabled: StoreKit External Purchase StoreKit External Purchase Link The .entitlements file in Xcode includes: com.apple.developer.storekit.external-purchase = YES com.apple.developer.storekit.ex
2
0
237
2w
Reply to App group broken on Sequoia
[quote='879587022, jblum2000, /thread/817268?answerId=879587022#879587022, /profile/jblum2000'] The first problem is that the entitlements validated flag is not set. [/quote] OK. That explains the runtime behaviour you’re seeing, because: The system won’t grant you access to the container because it can’t trust your entitlements. And it won’t display the standard UI because it knows that file providers run in the background. [quote='879587022, jblum2000, /thread/817268?answerId=879587022#879587022, /profile/jblum2000'] And the codesign result shows that the new app group is not present [/quote] And that’d do it. As to how it got built this, it’s hard to say without digging deeper into your build process. [quote='879587022, jblum2000, /thread/817268?answerId=879587022#879587022, /profile/jblum2000'] I'll try a complete rebuild and get back to you ASAP. [/quote] That’s always a good start. And if that doesn’t help, you can look at the build transcript to see how entitlement values are flowing from your
Topic: Code Signing SubTopic: Entitlements Tags:
2w
Reply to invalid API object reference
Thanks for the download link. I’m not sure what the actual problem is here. I ran your app through (roughly) the process described in Testing a Notarised Product, and everything seemed to work just fine. Specifically: In a fresh macOS 26.3.1 VM, I downloaded that zip archive in a way that sets quarantine. I unpacked it using the Finder. And then I opened the app using the Finder. It passed Gatekeeper, launched, and showed its initial UI. I then ran some basic validity checks, and those also passed with flying colours: % syspolicy_check distribution umldiagrammer.app App passed all pre-distribution checks and is ready for distribution. % codesign -v --deep --strict -vvv umldiagrammer.app … umldiagrammer.app: valid on disk umldiagrammer.app: satisfies its Designated Requirement % spctl -vvvv --assess --type exec umldiagrammer.app umldiagrammer.app: accepted source=Notarized Developer ID origin=Developer ID Application: Humberto Sanchez II (NA8Z96F8V9) Please run through these steps yourself and let me
2w
Reply to App group broken on Sequoia
Thanks, Quinn! The first problem is that the entitlements validated flag is not set -- here's the relevant text: code signing info = valid refuse invalid pages kill on invalid pages require enforcement allowed mach-o platform dyld And the codesign result shows that the new app group is not present, just the old one: Executable=/Applications/MyApp.app/Contents/PlugIns/EMPFileProvider.appex/Contents/MacOS/EMPFileProvider [Dict] [Key] com.apple.security.app-sandbox [Value] [Bool] true [Key] com.apple.security.network.client [Value] [Bool] true [Key] keychain-access-groups [Value] [Array] [String] XXXXXXXXXX.com.mydomain.MyApp.Shared [Key] com.apple.security.application-groups [Value] [Array] [String] group.com.mydomain.MyApp [Key] com.apple.application-identifier [Value] [String] $(AppIdentifierPrefix)$(PRODUCT_BUNDLE_IDENTIFIER) ...which is odd because the embedded.provisionprofile inside the .appex lists all three: com.apple.security.application-groups group.XXXXXXXXXX.com.mydomain.MyApp group.com.my
Topic: Code Signing SubTopic: Entitlements Tags:
3w
Reply to invalid API object reference
Thanks for the help. I put the zipped application and the zipped log file on GitHub as a pre-release for my app. They are here: https://github.com/hasii2011/umldiagrammer/releases/tag/0.3.0 Code sign command: codesign --sign ${IDENTITY} '--force --timestamp --options=runtime <.so or .dylib to sign> Verification Command /usr/sbin/spctl -vvvv --assess --type exec /Users/humberto.a.sanchez.ii/PycharmProjects/umldiagrammer/dist/umldigrammer.app
3w
Reply to App group broken on Sequoia
I’m not sure what’s going wrong here but I have a couple of diagnostics tests for you to run. Both require you to get your file provider started. Once you have that: Use launchctl procinfo to check whether the process has the entitlements validated flag set. App Groups: macOS vs iOS: Working Towards Harmony has an explanation of how to do this. Use codesign to check the entitlements of the running process: % codesign -d --entitlements - PID where PID is the process ID. What do you see? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: Code Signing SubTopic: Entitlements Tags:
3w
Reply to invalid API object reference
That message corresponds to errSecCSInvalidObjectRef (-67071). That’s an obscure one. I’ve been supporting Mac coded signing for almost a decade and I’ve never seen it before. Well done! [quote='818406021, hasii2021, /thread/818406, /profile/hasii2021'] Can't figure out how to post the log file. [/quote] You can post log files as text attachments. I have info on how to do that in Posting a Crash Report. Its focus is on crash reports, but the process for posting a text attachment is the same in both cases. However, the notary log is unlikely to help here because, as you say, the app notarises successfully. Rather, this is a code signing error on your local Mac. [quote='818406021, hasii2021, /thread/818406, /profile/hasii2021'] when I try to verify the signature I get the above error. [/quote] How are you doing that? Normally I’d verify a signature like so: % codesign -v --deep --strict /path/to/my.app Is that what you’re doing? As to the potential causes of errSecCSInvalidObjectRef, there are very few
3w
First-time notarization submissions stuck "In Progress" for 72+ hours
Hi, I'm a new Developer ID account holder submitting my first app for notarization. All submissions have been stuck In Progress for 72+ hours. Apple System Status has shown all services operational throughout. Team ID: 4L9YA7S99L $ xcrun notarytool history --keychain-profile blackbox Successfully received submission history. history -------------------------------------------------- createdDate: 2026-03-09T11:19:41.697Z id: 2c0cdf3d-a3ac-4d86-8eb0-2f601b2d09c5 name: Blackbox-0.2.0.dmg status: In Progress -------------------------------------------------- createdDate: 2026-03-07T18:11:37.660Z id: 5ab09d84-b2e2-4738-9b63-100a7dd46882 name: Blackbox-0.1.0.dmg status: In Progress -------------------------------------------------- createdDate: 2026-03-06T22:47:21.410Z id: 1c90fa3e-c52a-4468-8056-06ff5d7d3752 name: Blackbox-0.1.0.dmg status: In Progress -------------------------------------------------- createdDate: 2026-03-06T22:34:55.803Z id: 4bbd6f77-7ff6-445f-817c-21f9909dfe7a name: Blackbox-0.1.0.dmg status: I
1
0
129
3w
First macOS Developer ID notarization stuck In Progress for multiple valid submissions
I am trying to notarize my first macOS app for direct distribution outside the Mac App Store using Developer ID Application signing. Team ID: 32S6XVAQPY Environment: macOS app distributed via Developer ID notarytool with a saved keychain profile archive exported locally, app zipped with ditto What I already verified locally: The archived app is signed with: Developer ID Application: (32S6XVAQPY) codesign --verify --deep --strict passes spctl shows: source=Unnotarized Developer ID syspolicy_check distribution only reports the expected missing notary ticket Hardened runtime is enabled The app bundle and nested Sparkle executables were re-signed and now have valid Developer ID signatures with secure timestamps Important note: I previously had a real signing issue in nested Sparkle binaries, and Apple rejected that submission quickly as Invalid. I fixed those signatures, and now new submissions no longer fail quickly but remain stuck In Progress. Submission IDs currently stuck: bea6c4b3-b107-4c81-8042-6c
3
0
368
3w
All notarization submissions stuck "In Progress" for 24-36+ hours (first-time submission)
I am submitting my first macOS app for notarization and all submissions have been stuck at In Progress for over 24-36 hours. The notarytool log command returns Submission log is not yet available for all of them. App details: macOS menu bar app (Apple Silicon only, arm64) Signed with Developer ID Application certificate Hardened Runtime enabled Secure timestamp included No get-task-allow entitlement Team ID: 3426FSU868 Submission history: bd5a8bf3-809f-42d5-9ab3-1cb665e4dfa6 (Mar 3, 13:02 UTC) - Status: Invalid This was expected. It was a Debug build with get-task-allow and missing secure timestamp. c3e54eef-650e-41ba-ac8f-8948147cc7e1 (Mar 3, 13:06 UTC) - Status: In Progress (36+ hours) b6c4515a-93dd-417c-8956-158a73f62dee (Mar 3, 14:06 UTC) - Status: In Progress (35+ hours) 478b7e57-3492-46eb-98fb-04b52bff1f17 (Mar 4, 01:08 UTC) - Status: In Progress (24+ hours) Submissions 2-4 were all built with Release configuration, signed with Developer ID Application certificate, hardened runtime, and secure timestamp
7
0
380
3w
Reply to Driver Activation failure error code 9. Maybe Entitlements? Please help
Kevin, ssmith_c, thank you both so much for your help. Thanks to your help and patience, I am finally able to get my driver to load. It errors out almost immediately, but it's writing to the logs, which is the most functionality I've gotten out of this enterprise since I started writing in December. FWIW, I think it was the * that did it, so I'll be accepting that answer for this question. Based on ssmith_c's reply I suspect I have some re-thinking to do with respect to my programmatic approach, but I think that's going to be the subject of a different question. For additional context on how I got there... if you care... I had initially switched over to number for vendor ID in my entitlements file but it continued to fail the entitlements check. Eventually I compared the output of security cms -D -i against the output of codesign -d --entitlements and discovered a discrepancy -- the codesign result included the integer vendor ID, while the embedded profile included a wildcard. I had been u
Topic: App & System Services SubTopic: Drivers Tags:
3w
All notarization submissions stuck "In Progress" for 24+ hours — first-time Electron app
I'm submitting my first macOS app (an Electron app, signed with Developer ID Application certificate and hardened runtime) for notarization using xcrun notarytool submit with App Store Connect API key authentication. All 6 of my submissions have been stuck at In Progress for over 24 hours now. The oldest submission is 27+ hours old. None have transitioned to Accepted or Invalid. Here's what I've verified: Code signing is valid: codesign --verify --deep --strict passes Hardened runtime is enabled Uploads succeed: Each submission receives a valid submission ID and the file uploads successfully to Apple's servers API key auth is working: Using App Store Connect API key (.p8 file), Key ID, and Issuer ID Tried both locally and via GitHub Actions CI — same result Polling Apple's status endpoint eventually times out with NSURLErrorDomain Code=-1001 The request timed out when checking https://appstoreconnect.apple.com/notary/v2/submissions/ Logs are not available (notarytool log returns not yet available for
17
0
1.5k
3w
Reply to All notarization submissions stuck "In Progress" for 24-36+ hours (first-time submission)
Hello! I'm trying to notarize my first app. My notarization submissions via xcrun notarytool submit are hanging indefinitely. The upload completes, but the processing never finishes. Upload ID: d1a3ef28-4255-4938-96e1-c6a9b73beb06 122ba838-f362-44fb-aaff-bbf27ec9d963 Details: Artifact type: macOS .app bundle packaged as .zip via ditto -c -k --keepParent Signing identity: Developer ID Application Code signing flags: --force --options runtime --deep Architecture: arm64 (also amd64 in previous attempts) macOS version: Darwin 25.3.0 What I've verified: Code signature passes codesign --verify --deep --strict
3w
Reply to PCI Transport Entitlements
There are some key things to keep in mind here: Your provisioning profile acts as an entitlement allowlist. Your .entitlements file is source code that feeds into the code signing machinery. The entitlements claimed by your app are baked into the app’s code signature. Likewise for embedded app extensions, DEXTs, and so on. The fact that you’ve been granted access to a capability lets you create an provisioning profile that authorises your use of the associated entitlements. However, you still have to claim that access, by updating your .entitlements file. You can then verify that the claim and the profile are in sync using the codesign and security tools, respectively. For the exact commands, and more general background, see TN3125 Inside Code Signing: Provisioning Profiles. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
2w
Title Notarization submissions stuck “In Progress” for 5+ days (SwiftUI macOS menu bar app)
Notarization submissions stuck “In Progress” for 5+ days (SwiftUI macOS menu bar app) Hello, I’m experiencing an issue where all notarization submissions remain “In Progress” for several days. Environment macOS native app written in Swift / SwiftUI Menu bar application Built with Xcode Developer ID Application signing Hardened Runtime enabled App Sandbox disabled Uses SMAppService for “Start at Login” Artifact structure ClaudeUsageTracker.zip └ ClaudeUsageTracker.app (no nested directory) Verification codesign --verify --deep --strict --verbose=2 ClaudeUsageTracker.app This succeeds without errors. Notarization submissions 2026-03-06 — In Progress ID=215814fc-57c5-4f99-88fe-ed2db4d3e3d9 2026-03-06 — In Progress ID=70948178-191c-4840-a9c7-52c321b725e5 2026-03-09 — In Progress ID=14a88b79-df4d-4d83-9bfe-fa6eafc9bf76 All submissions remain In Progress for 5+ days, and notarytool log is not available yet. Command used xcrun notarytool submit ClaudeUsageTracker.zip --keychain-profile notarytool-profile T
Replies
9
Boosts
0
Views
391
Activity
2w
Unable to enable eligibility for External Purchase Link APIs — seeking clarification
Hello, I am currently implementing External Purchase Link and External Purchase Custom Link and am encountering an issue where both ExternalPurchaseLink.canOpen and ExternalPurchaseCustomLink.isEligible always return false under all test conditions. I would like to confirm whether my setup is missing any required steps or whether this behavior is expected. Below are the details of my current environment and configuration: 🔧 1. Development Environment Xcode: 16.3, 16.4, 26.0 beta 4 Devices: iPhone running iOS 26.2 beta iPhone running iOS 16.7.12 macOS 15.5 (real device testing) Simulator iOS 18.0 Build Type: Local development build using a Developer Provisioning Profile Sandbox account signed in during testing 🔑 2. Entitlements (Developer site & Xcode) In Certificates → Identifiers → App ID, both capabilities are enabled: StoreKit External Purchase StoreKit External Purchase Link The .entitlements file in Xcode includes: com.apple.developer.storekit.external-purchase = YES com.apple.developer.storekit.ex
Replies
2
Boosts
0
Views
237
Activity
2w
Reply to App group broken on Sequoia
[quote='879587022, jblum2000, /thread/817268?answerId=879587022#879587022, /profile/jblum2000'] The first problem is that the entitlements validated flag is not set. [/quote] OK. That explains the runtime behaviour you’re seeing, because: The system won’t grant you access to the container because it can’t trust your entitlements. And it won’t display the standard UI because it knows that file providers run in the background. [quote='879587022, jblum2000, /thread/817268?answerId=879587022#879587022, /profile/jblum2000'] And the codesign result shows that the new app group is not present [/quote] And that’d do it. As to how it got built this, it’s hard to say without digging deeper into your build process. [quote='879587022, jblum2000, /thread/817268?answerId=879587022#879587022, /profile/jblum2000'] I'll try a complete rebuild and get back to you ASAP. [/quote] That’s always a good start. And if that doesn’t help, you can look at the build transcript to see how entitlement values are flowing from your
Topic: Code Signing SubTopic: Entitlements Tags:
Replies
Boosts
Views
Activity
2w
Reply to invalid API object reference
Thanks for the download link. I’m not sure what the actual problem is here. I ran your app through (roughly) the process described in Testing a Notarised Product, and everything seemed to work just fine. Specifically: In a fresh macOS 26.3.1 VM, I downloaded that zip archive in a way that sets quarantine. I unpacked it using the Finder. And then I opened the app using the Finder. It passed Gatekeeper, launched, and showed its initial UI. I then ran some basic validity checks, and those also passed with flying colours: % syspolicy_check distribution umldiagrammer.app App passed all pre-distribution checks and is ready for distribution. % codesign -v --deep --strict -vvv umldiagrammer.app … umldiagrammer.app: valid on disk umldiagrammer.app: satisfies its Designated Requirement % spctl -vvvv --assess --type exec umldiagrammer.app umldiagrammer.app: accepted source=Notarized Developer ID origin=Developer ID Application: Humberto Sanchez II (NA8Z96F8V9) Please run through these steps yourself and let me
Replies
Boosts
Views
Activity
2w
Reply to App group broken on Sequoia
Thanks, Quinn! The first problem is that the entitlements validated flag is not set -- here's the relevant text: code signing info = valid refuse invalid pages kill on invalid pages require enforcement allowed mach-o platform dyld And the codesign result shows that the new app group is not present, just the old one: Executable=/Applications/MyApp.app/Contents/PlugIns/EMPFileProvider.appex/Contents/MacOS/EMPFileProvider [Dict] [Key] com.apple.security.app-sandbox [Value] [Bool] true [Key] com.apple.security.network.client [Value] [Bool] true [Key] keychain-access-groups [Value] [Array] [String] XXXXXXXXXX.com.mydomain.MyApp.Shared [Key] com.apple.security.application-groups [Value] [Array] [String] group.com.mydomain.MyApp [Key] com.apple.application-identifier [Value] [String] $(AppIdentifierPrefix)$(PRODUCT_BUNDLE_IDENTIFIER) ...which is odd because the embedded.provisionprofile inside the .appex lists all three: com.apple.security.application-groups group.XXXXXXXXXX.com.mydomain.MyApp group.com.my
Topic: Code Signing SubTopic: Entitlements Tags:
Replies
Boosts
Views
Activity
3w
Reply to invalid API object reference
Thanks for the help. I put the zipped application and the zipped log file on GitHub as a pre-release for my app. They are here: https://github.com/hasii2011/umldiagrammer/releases/tag/0.3.0 Code sign command: codesign --sign ${IDENTITY} '--force --timestamp --options=runtime <.so or .dylib to sign> Verification Command /usr/sbin/spctl -vvvv --assess --type exec /Users/humberto.a.sanchez.ii/PycharmProjects/umldiagrammer/dist/umldigrammer.app
Replies
Boosts
Views
Activity
3w
Reply to App group broken on Sequoia
I’m not sure what’s going wrong here but I have a couple of diagnostics tests for you to run. Both require you to get your file provider started. Once you have that: Use launchctl procinfo to check whether the process has the entitlements validated flag set. App Groups: macOS vs iOS: Working Towards Harmony has an explanation of how to do this. Use codesign to check the entitlements of the running process: % codesign -d --entitlements - PID where PID is the process ID. What do you see? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: Code Signing SubTopic: Entitlements Tags:
Replies
Boosts
Views
Activity
3w
Reply to invalid API object reference
That message corresponds to errSecCSInvalidObjectRef (-67071). That’s an obscure one. I’ve been supporting Mac coded signing for almost a decade and I’ve never seen it before. Well done! [quote='818406021, hasii2021, /thread/818406, /profile/hasii2021'] Can't figure out how to post the log file. [/quote] You can post log files as text attachments. I have info on how to do that in Posting a Crash Report. Its focus is on crash reports, but the process for posting a text attachment is the same in both cases. However, the notary log is unlikely to help here because, as you say, the app notarises successfully. Rather, this is a code signing error on your local Mac. [quote='818406021, hasii2021, /thread/818406, /profile/hasii2021'] when I try to verify the signature I get the above error. [/quote] How are you doing that? Normally I’d verify a signature like so: % codesign -v --deep --strict /path/to/my.app Is that what you’re doing? As to the potential causes of errSecCSInvalidObjectRef, there are very few
Replies
Boosts
Views
Activity
3w
First-time notarization submissions stuck "In Progress" for 72+ hours
Hi, I'm a new Developer ID account holder submitting my first app for notarization. All submissions have been stuck In Progress for 72+ hours. Apple System Status has shown all services operational throughout. Team ID: 4L9YA7S99L $ xcrun notarytool history --keychain-profile blackbox Successfully received submission history. history -------------------------------------------------- createdDate: 2026-03-09T11:19:41.697Z id: 2c0cdf3d-a3ac-4d86-8eb0-2f601b2d09c5 name: Blackbox-0.2.0.dmg status: In Progress -------------------------------------------------- createdDate: 2026-03-07T18:11:37.660Z id: 5ab09d84-b2e2-4738-9b63-100a7dd46882 name: Blackbox-0.1.0.dmg status: In Progress -------------------------------------------------- createdDate: 2026-03-06T22:47:21.410Z id: 1c90fa3e-c52a-4468-8056-06ff5d7d3752 name: Blackbox-0.1.0.dmg status: In Progress -------------------------------------------------- createdDate: 2026-03-06T22:34:55.803Z id: 4bbd6f77-7ff6-445f-817c-21f9909dfe7a name: Blackbox-0.1.0.dmg status: I
Replies
1
Boosts
0
Views
129
Activity
3w
First macOS Developer ID notarization stuck In Progress for multiple valid submissions
I am trying to notarize my first macOS app for direct distribution outside the Mac App Store using Developer ID Application signing. Team ID: 32S6XVAQPY Environment: macOS app distributed via Developer ID notarytool with a saved keychain profile archive exported locally, app zipped with ditto What I already verified locally: The archived app is signed with: Developer ID Application: (32S6XVAQPY) codesign --verify --deep --strict passes spctl shows: source=Unnotarized Developer ID syspolicy_check distribution only reports the expected missing notary ticket Hardened runtime is enabled The app bundle and nested Sparkle executables were re-signed and now have valid Developer ID signatures with secure timestamps Important note: I previously had a real signing issue in nested Sparkle binaries, and Apple rejected that submission quickly as Invalid. I fixed those signatures, and now new submissions no longer fail quickly but remain stuck In Progress. Submission IDs currently stuck: bea6c4b3-b107-4c81-8042-6c
Replies
3
Boosts
0
Views
368
Activity
3w
All notarization submissions stuck "In Progress" for 24-36+ hours (first-time submission)
I am submitting my first macOS app for notarization and all submissions have been stuck at In Progress for over 24-36 hours. The notarytool log command returns Submission log is not yet available for all of them. App details: macOS menu bar app (Apple Silicon only, arm64) Signed with Developer ID Application certificate Hardened Runtime enabled Secure timestamp included No get-task-allow entitlement Team ID: 3426FSU868 Submission history: bd5a8bf3-809f-42d5-9ab3-1cb665e4dfa6 (Mar 3, 13:02 UTC) - Status: Invalid This was expected. It was a Debug build with get-task-allow and missing secure timestamp. c3e54eef-650e-41ba-ac8f-8948147cc7e1 (Mar 3, 13:06 UTC) - Status: In Progress (36+ hours) b6c4515a-93dd-417c-8956-158a73f62dee (Mar 3, 14:06 UTC) - Status: In Progress (35+ hours) 478b7e57-3492-46eb-98fb-04b52bff1f17 (Mar 4, 01:08 UTC) - Status: In Progress (24+ hours) Submissions 2-4 were all built with Release configuration, signed with Developer ID Application certificate, hardened runtime, and secure timestamp
Replies
7
Boosts
0
Views
380
Activity
3w
Reply to Driver Activation failure error code 9. Maybe Entitlements? Please help
Kevin, ssmith_c, thank you both so much for your help. Thanks to your help and patience, I am finally able to get my driver to load. It errors out almost immediately, but it's writing to the logs, which is the most functionality I've gotten out of this enterprise since I started writing in December. FWIW, I think it was the * that did it, so I'll be accepting that answer for this question. Based on ssmith_c's reply I suspect I have some re-thinking to do with respect to my programmatic approach, but I think that's going to be the subject of a different question. For additional context on how I got there... if you care... I had initially switched over to number for vendor ID in my entitlements file but it continued to fail the entitlements check. Eventually I compared the output of security cms -D -i against the output of codesign -d --entitlements and discovered a discrepancy -- the codesign result included the integer vendor ID, while the embedded profile included a wildcard. I had been u
Topic: App & System Services SubTopic: Drivers Tags:
Replies
Boosts
Views
Activity
3w
All notarization submissions stuck "In Progress" for 24+ hours — first-time Electron app
I'm submitting my first macOS app (an Electron app, signed with Developer ID Application certificate and hardened runtime) for notarization using xcrun notarytool submit with App Store Connect API key authentication. All 6 of my submissions have been stuck at In Progress for over 24 hours now. The oldest submission is 27+ hours old. None have transitioned to Accepted or Invalid. Here's what I've verified: Code signing is valid: codesign --verify --deep --strict passes Hardened runtime is enabled Uploads succeed: Each submission receives a valid submission ID and the file uploads successfully to Apple's servers API key auth is working: Using App Store Connect API key (.p8 file), Key ID, and Issuer ID Tried both locally and via GitHub Actions CI — same result Polling Apple's status endpoint eventually times out with NSURLErrorDomain Code=-1001 The request timed out when checking https://appstoreconnect.apple.com/notary/v2/submissions/ Logs are not available (notarytool log returns not yet available for
Replies
17
Boosts
0
Views
1.5k
Activity
3w
Reply to All notarization submissions stuck "In Progress" for 24-36+ hours (first-time submission)
Hello! I'm trying to notarize my first app. My notarization submissions via xcrun notarytool submit are hanging indefinitely. The upload completes, but the processing never finishes. Upload ID: d1a3ef28-4255-4938-96e1-c6a9b73beb06 122ba838-f362-44fb-aaff-bbf27ec9d963 Details: Artifact type: macOS .app bundle packaged as .zip via ditto -c -k --keepParent Signing identity: Developer ID Application Code signing flags: --force --options runtime --deep Architecture: arm64 (also amd64 in previous attempts) macOS version: Darwin 25.3.0 What I've verified: Code signature passes codesign --verify --deep --strict
Replies
Boosts
Views
Activity
3w