Search results for

“codesign”

3,221 results found

Post

Replies

Boosts

Views

Activity

Notarized but Gatekeeper fails macOS 15 only?
Okay, I just pushed a release and notarized. Works great on my test laptop (macOS 26.2) and my test desktop (macOS 14.x) But it seems to fail for a friend who's running macOS 15. I've been using the same GitHub actions successfully for months. How can notarization work for macOS 14 and 26, but not for macOS 15? I think everything looks okay as far as the signing? I've checked codesign -dvv Executable=/Applications/Avogadro2.app/Contents/MacOS/Avogadro2 Identifier=cc.avogadro Format=app bundle with Mach-O thin (arm64) CodeDirectory v=20500 size=11607 flags=0x10000(runtime) hashes=352+7 location=embedded Signature size=8986 Authority=Developer ID Application: Geoffrey Hutchison (…..) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Feb 5, 2026 at 8:47:21 PM Info.plist entries=24 TeamIdentifier=….. Runtime Version=15.5.0 Sealed Resources version=2 rules=13 files=3306 Internal requirements count=1 size=172 And from spctl -a -vv /Applications/Avogadro2.app: accepted source=
1
0
426
Feb ’26
All notarization submissions stuck "In Progress" — first-time notarization, 9 submissions over 16+ hours
I'm submitting my first macOS app (a native SwiftUI menu bar app, signed with Developer ID Application certificate, Hardened Runtime enabled) for notarization using xcrun notarytool submit with keychain profile authentication. All 9 of my submissions have been stuck at In Progress for up to 16 hours. None have transitioned to Accepted or Invalid. Logs are unavailable for all of them (notarytool log returns Submission log is not yet available). Environment macOS: 26.2 (25C56) Xcode: 26.1.1 (17B100) notarytool: 1.1.0 (39) App: Native SwiftUI, universal binary (x86_64 + arm64), ~2.2 MB DMG Bundle ID: com.gro.ask Team ID: 4KT56S2BX6 What I've verified Code signing is valid: $ codesign --verify --deep --strict GroAsk.app passes with no errors $ codesign -dvvv GroAsk.app Authority=Developer ID Application: Jack Wu (4KT56S2BX6) Authority=Developer ID Certification Authority Authority=Apple Root CA CodeDirectory flags=0x10000(runtime) # Hardened Runtime enabled Runtime Version=26.1.0 Format=app bund
2
0
242
Feb ’26
notarization stuck in progress > 24hrs
Hi guys, I am new to the Apple Developer Program (enrolled a few days ago) and this is my first app notarization attempt. I've been experiencing significant delays - all submissions have been stuck at In Progress for over 24 hours. Details: macOS app signed with Developer ID Application certificate Using xcrun notarytool with app-specific password Hardened runtime enabled codesign --verify --deep --strict passes Team ID: QVHM976XC5 Submission IDs (all stuck In Progress): 5f494a89-0db0-4cc6-944f-ca2fe399e870 (latest - 8+ hours) 938f6b8d-0d00-45f5-861d-68fe470df6c2 d0edcbfe-8464-455f-b077-bebaa5b9aab7 I understand new developers may experience longer initial processing, but 24+ hours seems excessive. Is there anything I should check or any additional steps required for new accounts? Any guidance appreciated.
6
0
605
Feb ’26
Reply to Error when updating system extension
[quote='875131022, IHadToChooseAUserNameAndIdidntWantTo, /thread/809959?answerId=875131022#875131022, /profile/IHadToChooseAUserNameAndIdidntWantTo'] Are there public APIs to assess notarization? [/quote] That’s tricky, because it depends on your definition of API. The codesign tool has a --check-notarization operation that does that. See Testing a Notarised Product and the codesign man page. While that’s documented, I’m not a fan of using command-line tools as APIs. The code signing requirement language has the notarized constraint. That’s not documented where it should be but it’s debatable whether that’s just because the parent document is stuck in the Documentation Archive. Annoyingly, an equivalent constraint has not been added to the LightweightCodeRequirements framework. If you think that’d be useful, I encourage you to file an enhancement request for it. And if you do, please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Suppor
Topic: Code Signing SubTopic: Notarization Tags:
Feb ’26
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
Feb ’26
URGENT: Multiple Notarization Submissions Stuck "In Progress" 5+ Days - Blocking Release
Hi Apple Developer Relations / Notary Service Team, CRITICAL: All notarization submissions stuck In Progress since Feb 1, 2026 (5+ days). Blocking product release. Latest (PRIORITY): 9bf1e3ca-33ed-4185-816c-2e06ff539f25 Stuck submissions: a9f1abf6-04a1-462c-b7d1-91e834b44c1a 94a172f8-4aa6-475c-a7ec-fd83c8cfc49a e2c033da-a1d0-480c-a3b5-5401a8dd3d03 eecefd87-8bf9-496c-86c8-c6f0d6a550e0 b1d27d30-7111-4cc7-9f0e-3f44aac43a97 Details: Team ID: JA8C8B5W34 App: 323MB DMG (codesign verified) notarytool log: not available (In Progress) Status page: Green Requests: Process 9bf1e3ca-33ed-4185-816c-2e06ff539f25 Queue status / ETA? @Quinn or Notary team - production blocker!
1
0
324
Feb ’26
Reply to All notarization submissions stuck "In Progress" for 24-72+ hours (including tiny 6KB test binary)
URGENT: Multiple Notarization Submissions Stuck In Progress 5+ Days - Blocking Release Hi Apple Developer Relations / Notary Service Team, CRITICAL: All notarization submissions stuck In Progress since Feb 1, 2026 (5+ days). Blocking product release. Latest (PRIORITY): 9bf1e3ca-33ed-4185-816c-2e06ff539f25 Stuck submissions: a9f1abf6-04a1-462c-b7d1-91e834b44c1a 94a172f8-4aa6-475c-a7ec-fd83c8cfc49a e2c033da-a1d0-480c-a3b5-5401a8dd3d03 eecefd87-8bf9-496c-86c8-c6f0d6a550e0 b1d27d30-7111-4cc7-9f0e-3f44aac43a97 Details: Team ID: JA8C8B5W34 App: 323MB DMG (codesign verified) notarytool log: not available (In Progress) Status page: Green Requests: Process 9bf1e3ca-33ed-4185-816c-2e06ff539f25 NOW Cancel old submissions Queue status / ETA? @Quinn or Notary team - production blocker!
Topic: Code Signing SubTopic: Notarization Tags:
Feb ’26
Verify an app before sending to Notary service
Hi, we are sending MacOS apps packaged in a ZIP archive or DMG disk image to the Notary Service. Before we send the app for notarization, we check the code signature via command codesign -vvv --deep --strict /path/to/app_or_bundle The result is positive and it does not provide any gaps. (And yes, we are following the inside out code signing approach, mentioned at Using the codesign Tool's --deep Option Correctly) Unfortunately, the result of the Notary service provided that one file has no signature, which was not detected by the signature verification command. The path of the binary was in .app.zip/.app/Contents/Resources/inst/ How I can be verify like a the Notary service does it on our side? Best regards, Stefan
1
0
313
Feb ’26
Reply to Team “57AWJ345M2” cannot enable iCloud Key-Value Storage for Bundle ID “com.marsgame.fg2”
That's a surprise to me. Would you mind to try with the following steps and see if the error is still there? Confirm the app transfer process is successfully completed. Confirm your provisioning profile is updated. You can do so by uncheck the Automatically manage signing box in Xcode and then check it back, which has Xcode refresh the provisioning profile. If you manually manage your codesign, download the updated profile from Apple's membership portal. Find the provisioning profile for your app from ~/Library/Developer/Xcode/UserData/Provisioning Profiles/ (or ~/Library/MobileDevice/Provisioning Profiles/ if you are using earlier version Xcode). If you have multiple files in the folder, find the one that has App ID Name tied to your app ID. Open the provisioning profile with your favorite text editor, and try to find the identifier of the key-value store identifier. If everything goes well, the identifier should be there. In your Xcode project, update the value of the com.apple.developer.ubiquity-k
Jan ’26
Reply to Driver Activation failure error code 9. Maybe Entitlements? Please help
First off, a clarification here: I am attempting to write a bridging driver for an older UPS that only communicates via RPC-over-USB rather than the HID Power Device class the OS requires. What's your final goal here? That is, are you: Trying to create a seamless bridge to HID and then relying on the system’s support. OR Direct communication via user client to your own app. In the first case, how seamless do you actually want this to be? Do you not want any app at all? The issue here is that you don't actually need to use DriverKit to talk to a USB device. You could also use the USBHost framework, which would let your app just talk to the device. Unless you're specifically bridging to HID, then I wouldn't use DriverKit at all. In addition, if you're planning to bridge to HID but you're also planning to have an app/daemon, then you could also do this by using the USBHost framework to communicate with your device and a virtual HID device to expose that device to the system. The right choice here really depends
Topic: App & System Services SubTopic: Drivers Tags:
Jan ’26
Error 7000 “Team is not yet configured for notarization” - All submissions rejected
I’m trying to notarize an Electron app for distribution outside the Mac App Store, but every submission is rejected with error 7000. Team Details: Team ID: P3HATASMP9 Organization: Rose Ai Labs, Inc. Role: Account Holder Apple Developer Program: Active membership Certificate: Type: Developer ID Application Identity: “Developer ID Application: Rose Ai Labs, Inc. (P3HATASMP9)” Status: Valid in Keychain Access with full certificate chain App Details: Platform: macOS (Electron) Hardened runtime: Enabled Code signing: Successful (codesign -v passes) Submission History (all rejected with same error): Jan 20, 2026: d2f5e812-d443-4858-895e-ca9828f65d6b Jan 20, 2026: 4864e851-99d4-49df-87b8-22a6b280f4fc Jan 21, 2026: 69b177bd-5f08-4363-a2bb-1d286dd9f047 Jan 21, 2026: a181071b-e874-4794-90f3-c172b112900e Jan 21, 2026: ae3ec87f-60da-4826-91df-a247cd4fd46f Jan 21, 2026: b7165e2f-19a8-4d4a-9e00-21e85550ec8b Jan 24, 2026: 2b83d46d-6606-450f-9ffe-cbfa0f0bf179 Jan 27, 2026: ed8ba49c-b24f-422b-9271-44dff805fb61 Error
1
0
405
Jan ’26
Reply to Notarization submissions stuck "In Progress"
I’m trying to notarize an Electron app for distribution outside the Mac App Store, but every submission is rejected with error 7000. Team Details: Team ID: P3HATASMP9 Organization: Rose Ai Labs, Inc. Role: Account Holder Apple Developer Program: Active membership Certificate: Type: Developer ID Application Identity: “Developer ID Application: Rose Ai Labs, Inc. (P3HATASMP9)” Status: Valid in Keychain Access with full certificate chain App Details: Platform: macOS (Electron) Hardened runtime: Enabled Code signing: Successful (codesign -v passes) Submission History (all rejected with same error): Date Submission ID Status Jan 20, 2026 d2f5e812-d443-4858-895e-ca9828f65d6b Rejected Jan 20, 2026 4864e851-99d4-49df-87b8-22a6b280f4fc Rejected Jan 21, 2026 69b177bd-5f08-4363-a2bb-1d286dd9f047 Rejected Jan 21, 2026 a181071b-e874-4794-90f3-c172b112900e Rejected Jan 21, 2026 ae3ec87f-60da-4826-91df-a247cd4fd46f Rejected Jan 21, 2026 b7165e2f-19a8-4d4a-9e00-21e85550ec8b Rejected Jan 24, 2026 2b83d46d-6606-450f-9
Jan ’26
Reply to Signed App Opens But Doesn't Recognise Plugin
I admire your dedication to this task! It’s hard to offer definitive advice without knowing more about how FileMaker loads plug-ins, but I suspect you’re being blocked by library validation. I downloaded that plug-in and took a look. First, I confirmed that it’s based on native code: % file BaseElements.fmplugin/Contents/MacOS/BaseElements BaseElements.fmplugin/Contents/MacOS/BaseElements: Mach-O … bundle … Next, I looked at its code signature: % codesign -d -vvv BaseElements.fmplugin … Authority=Developer ID Application: Goya Pty Ltd (GUZF844KMZ) … If your runtime is loading this is the traditional manner — that is, loading the plug-in bundle into your process’s address space — then library validation is an issue. Specifically: To distribute your app directly, you must notarise it. Notarisation requires the hardened runtime. The hardened runtime enables library validation by default. Library validation ensures that your app’s process will only load code signed by Apple or by your team. So, your app
Topic: Code Signing SubTopic: General Tags:
Jan ’26
Signed app can't be verified
I've signed an app, zipped it, and uploaded it to github. When I download it on another Mac, I get it can't be opened because it could not be verified for malware. But on that computer, I can verify it with codesign, and it appears to be correct (as far as I can tell). I can copy/paste the app from my other Mac, and that copy will run without problem. sys_policy, however, gives: Notary Ticket Missing File: ReView.app Severity: Fatal Full Error: A Notarization ticket is not stapled to this application. Type: Distribution Error This is the same for the copy that runs, and the copy that doesn't. The difference between them appears to be a quarantine xattr. I can delete this, and the app launches without incident. Is this expected? Why should a signed app be quarantined just because it's been downloaded? The whole point of paying the fee is to avoid the security obstacles...! ;-)
3
0
880
Jan ’26
Reply to "Application damaged and can't be opened' error prompt on 15.6.1 Sequoia
Yes, also on Mac where my application is seen earlier Yes, I perform install using sudo installer command which is a standard way of installation Yes, that's correct. Some more information: Running codesign --verify --deep --strict /path/to/your.app throws the following error, invalid resource directory (directory or signature have been modified) If I run sudo codesign --verify --deep --strict /path/to/your.app, it does not throw any error. I have verified the sudo command run with the verbose option, it says valid on disk and satisfies its Designated Requirement
Topic: Code Signing SubTopic: General Tags:
Jan ’26
Notarized but Gatekeeper fails macOS 15 only?
Okay, I just pushed a release and notarized. Works great on my test laptop (macOS 26.2) and my test desktop (macOS 14.x) But it seems to fail for a friend who's running macOS 15. I've been using the same GitHub actions successfully for months. How can notarization work for macOS 14 and 26, but not for macOS 15? I think everything looks okay as far as the signing? I've checked codesign -dvv Executable=/Applications/Avogadro2.app/Contents/MacOS/Avogadro2 Identifier=cc.avogadro Format=app bundle with Mach-O thin (arm64) CodeDirectory v=20500 size=11607 flags=0x10000(runtime) hashes=352+7 location=embedded Signature size=8986 Authority=Developer ID Application: Geoffrey Hutchison (…..) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Feb 5, 2026 at 8:47:21 PM Info.plist entries=24 TeamIdentifier=….. Runtime Version=15.5.0 Sealed Resources version=2 rules=13 files=3306 Internal requirements count=1 size=172 And from spctl -a -vv /Applications/Avogadro2.app: accepted source=
Replies
1
Boosts
0
Views
426
Activity
Feb ’26
All notarization submissions stuck "In Progress" — first-time notarization, 9 submissions over 16+ hours
I'm submitting my first macOS app (a native SwiftUI menu bar app, signed with Developer ID Application certificate, Hardened Runtime enabled) for notarization using xcrun notarytool submit with keychain profile authentication. All 9 of my submissions have been stuck at In Progress for up to 16 hours. None have transitioned to Accepted or Invalid. Logs are unavailable for all of them (notarytool log returns Submission log is not yet available). Environment macOS: 26.2 (25C56) Xcode: 26.1.1 (17B100) notarytool: 1.1.0 (39) App: Native SwiftUI, universal binary (x86_64 + arm64), ~2.2 MB DMG Bundle ID: com.gro.ask Team ID: 4KT56S2BX6 What I've verified Code signing is valid: $ codesign --verify --deep --strict GroAsk.app passes with no errors $ codesign -dvvv GroAsk.app Authority=Developer ID Application: Jack Wu (4KT56S2BX6) Authority=Developer ID Certification Authority Authority=Apple Root CA CodeDirectory flags=0x10000(runtime) # Hardened Runtime enabled Runtime Version=26.1.0 Format=app bund
Replies
2
Boosts
0
Views
242
Activity
Feb ’26
notarization stuck in progress > 24hrs
Hi guys, I am new to the Apple Developer Program (enrolled a few days ago) and this is my first app notarization attempt. I've been experiencing significant delays - all submissions have been stuck at In Progress for over 24 hours. Details: macOS app signed with Developer ID Application certificate Using xcrun notarytool with app-specific password Hardened runtime enabled codesign --verify --deep --strict passes Team ID: QVHM976XC5 Submission IDs (all stuck In Progress): 5f494a89-0db0-4cc6-944f-ca2fe399e870 (latest - 8+ hours) 938f6b8d-0d00-45f5-861d-68fe470df6c2 d0edcbfe-8464-455f-b077-bebaa5b9aab7 I understand new developers may experience longer initial processing, but 24+ hours seems excessive. Is there anything I should check or any additional steps required for new accounts? Any guidance appreciated.
Replies
6
Boosts
0
Views
605
Activity
Feb ’26
Reply to Error when updating system extension
[quote='875131022, IHadToChooseAUserNameAndIdidntWantTo, /thread/809959?answerId=875131022#875131022, /profile/IHadToChooseAUserNameAndIdidntWantTo'] Are there public APIs to assess notarization? [/quote] That’s tricky, because it depends on your definition of API. The codesign tool has a --check-notarization operation that does that. See Testing a Notarised Product and the codesign man page. While that’s documented, I’m not a fan of using command-line tools as APIs. The code signing requirement language has the notarized constraint. That’s not documented where it should be but it’s debatable whether that’s just because the parent document is stuck in the Documentation Archive. Annoyingly, an equivalent constraint has not been added to the LightweightCodeRequirements framework. If you think that’d be useful, I encourage you to file an enhancement request for it. And if you do, please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Suppor
Topic: Code Signing SubTopic: Notarization Tags:
Replies
Boosts
Views
Activity
Feb ’26
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
Feb ’26
URGENT: Multiple Notarization Submissions Stuck "In Progress" 5+ Days - Blocking Release
Hi Apple Developer Relations / Notary Service Team, CRITICAL: All notarization submissions stuck In Progress since Feb 1, 2026 (5+ days). Blocking product release. Latest (PRIORITY): 9bf1e3ca-33ed-4185-816c-2e06ff539f25 Stuck submissions: a9f1abf6-04a1-462c-b7d1-91e834b44c1a 94a172f8-4aa6-475c-a7ec-fd83c8cfc49a e2c033da-a1d0-480c-a3b5-5401a8dd3d03 eecefd87-8bf9-496c-86c8-c6f0d6a550e0 b1d27d30-7111-4cc7-9f0e-3f44aac43a97 Details: Team ID: JA8C8B5W34 App: 323MB DMG (codesign verified) notarytool log: not available (In Progress) Status page: Green Requests: Process 9bf1e3ca-33ed-4185-816c-2e06ff539f25 Queue status / ETA? @Quinn or Notary team - production blocker!
Replies
1
Boosts
0
Views
324
Activity
Feb ’26
Reply to All notarization submissions stuck "In Progress" for 24-72+ hours (including tiny 6KB test binary)
URGENT: Multiple Notarization Submissions Stuck In Progress 5+ Days - Blocking Release Hi Apple Developer Relations / Notary Service Team, CRITICAL: All notarization submissions stuck In Progress since Feb 1, 2026 (5+ days). Blocking product release. Latest (PRIORITY): 9bf1e3ca-33ed-4185-816c-2e06ff539f25 Stuck submissions: a9f1abf6-04a1-462c-b7d1-91e834b44c1a 94a172f8-4aa6-475c-a7ec-fd83c8cfc49a e2c033da-a1d0-480c-a3b5-5401a8dd3d03 eecefd87-8bf9-496c-86c8-c6f0d6a550e0 b1d27d30-7111-4cc7-9f0e-3f44aac43a97 Details: Team ID: JA8C8B5W34 App: 323MB DMG (codesign verified) notarytool log: not available (In Progress) Status page: Green Requests: Process 9bf1e3ca-33ed-4185-816c-2e06ff539f25 NOW Cancel old submissions Queue status / ETA? @Quinn or Notary team - production blocker!
Topic: Code Signing SubTopic: Notarization Tags:
Replies
Boosts
Views
Activity
Feb ’26
Verify an app before sending to Notary service
Hi, we are sending MacOS apps packaged in a ZIP archive or DMG disk image to the Notary Service. Before we send the app for notarization, we check the code signature via command codesign -vvv --deep --strict /path/to/app_or_bundle The result is positive and it does not provide any gaps. (And yes, we are following the inside out code signing approach, mentioned at Using the codesign Tool's --deep Option Correctly) Unfortunately, the result of the Notary service provided that one file has no signature, which was not detected by the signature verification command. The path of the binary was in .app.zip/.app/Contents/Resources/inst/ How I can be verify like a the Notary service does it on our side? Best regards, Stefan
Replies
1
Boosts
0
Views
313
Activity
Feb ’26
Reply to Team “57AWJ345M2” cannot enable iCloud Key-Value Storage for Bundle ID “com.marsgame.fg2”
That's a surprise to me. Would you mind to try with the following steps and see if the error is still there? Confirm the app transfer process is successfully completed. Confirm your provisioning profile is updated. You can do so by uncheck the Automatically manage signing box in Xcode and then check it back, which has Xcode refresh the provisioning profile. If you manually manage your codesign, download the updated profile from Apple's membership portal. Find the provisioning profile for your app from ~/Library/Developer/Xcode/UserData/Provisioning Profiles/ (or ~/Library/MobileDevice/Provisioning Profiles/ if you are using earlier version Xcode). If you have multiple files in the folder, find the one that has App ID Name tied to your app ID. Open the provisioning profile with your favorite text editor, and try to find the identifier of the key-value store identifier. If everything goes well, the identifier should be there. In your Xcode project, update the value of the com.apple.developer.ubiquity-k
Replies
Boosts
Views
Activity
Jan ’26
Reply to Driver Activation failure error code 9. Maybe Entitlements? Please help
First off, a clarification here: I am attempting to write a bridging driver for an older UPS that only communicates via RPC-over-USB rather than the HID Power Device class the OS requires. What's your final goal here? That is, are you: Trying to create a seamless bridge to HID and then relying on the system’s support. OR Direct communication via user client to your own app. In the first case, how seamless do you actually want this to be? Do you not want any app at all? The issue here is that you don't actually need to use DriverKit to talk to a USB device. You could also use the USBHost framework, which would let your app just talk to the device. Unless you're specifically bridging to HID, then I wouldn't use DriverKit at all. In addition, if you're planning to bridge to HID but you're also planning to have an app/daemon, then you could also do this by using the USBHost framework to communicate with your device and a virtual HID device to expose that device to the system. The right choice here really depends
Topic: App & System Services SubTopic: Drivers Tags:
Replies
Boosts
Views
Activity
Jan ’26
Error 7000 “Team is not yet configured for notarization” - All submissions rejected
I’m trying to notarize an Electron app for distribution outside the Mac App Store, but every submission is rejected with error 7000. Team Details: Team ID: P3HATASMP9 Organization: Rose Ai Labs, Inc. Role: Account Holder Apple Developer Program: Active membership Certificate: Type: Developer ID Application Identity: “Developer ID Application: Rose Ai Labs, Inc. (P3HATASMP9)” Status: Valid in Keychain Access with full certificate chain App Details: Platform: macOS (Electron) Hardened runtime: Enabled Code signing: Successful (codesign -v passes) Submission History (all rejected with same error): Jan 20, 2026: d2f5e812-d443-4858-895e-ca9828f65d6b Jan 20, 2026: 4864e851-99d4-49df-87b8-22a6b280f4fc Jan 21, 2026: 69b177bd-5f08-4363-a2bb-1d286dd9f047 Jan 21, 2026: a181071b-e874-4794-90f3-c172b112900e Jan 21, 2026: ae3ec87f-60da-4826-91df-a247cd4fd46f Jan 21, 2026: b7165e2f-19a8-4d4a-9e00-21e85550ec8b Jan 24, 2026: 2b83d46d-6606-450f-9ffe-cbfa0f0bf179 Jan 27, 2026: ed8ba49c-b24f-422b-9271-44dff805fb61 Error
Replies
1
Boosts
0
Views
405
Activity
Jan ’26
Reply to Notarization submissions stuck "In Progress"
I’m trying to notarize an Electron app for distribution outside the Mac App Store, but every submission is rejected with error 7000. Team Details: Team ID: P3HATASMP9 Organization: Rose Ai Labs, Inc. Role: Account Holder Apple Developer Program: Active membership Certificate: Type: Developer ID Application Identity: “Developer ID Application: Rose Ai Labs, Inc. (P3HATASMP9)” Status: Valid in Keychain Access with full certificate chain App Details: Platform: macOS (Electron) Hardened runtime: Enabled Code signing: Successful (codesign -v passes) Submission History (all rejected with same error): Date Submission ID Status Jan 20, 2026 d2f5e812-d443-4858-895e-ca9828f65d6b Rejected Jan 20, 2026 4864e851-99d4-49df-87b8-22a6b280f4fc Rejected Jan 21, 2026 69b177bd-5f08-4363-a2bb-1d286dd9f047 Rejected Jan 21, 2026 a181071b-e874-4794-90f3-c172b112900e Rejected Jan 21, 2026 ae3ec87f-60da-4826-91df-a247cd4fd46f Rejected Jan 21, 2026 b7165e2f-19a8-4d4a-9e00-21e85550ec8b Rejected Jan 24, 2026 2b83d46d-6606-450f-9
Replies
Boosts
Views
Activity
Jan ’26
Reply to Signed App Opens But Doesn't Recognise Plugin
I admire your dedication to this task! It’s hard to offer definitive advice without knowing more about how FileMaker loads plug-ins, but I suspect you’re being blocked by library validation. I downloaded that plug-in and took a look. First, I confirmed that it’s based on native code: % file BaseElements.fmplugin/Contents/MacOS/BaseElements BaseElements.fmplugin/Contents/MacOS/BaseElements: Mach-O … bundle … Next, I looked at its code signature: % codesign -d -vvv BaseElements.fmplugin … Authority=Developer ID Application: Goya Pty Ltd (GUZF844KMZ) … If your runtime is loading this is the traditional manner — that is, loading the plug-in bundle into your process’s address space — then library validation is an issue. Specifically: To distribute your app directly, you must notarise it. Notarisation requires the hardened runtime. The hardened runtime enables library validation by default. Library validation ensures that your app’s process will only load code signed by Apple or by your team. So, your app
Topic: Code Signing SubTopic: General Tags:
Replies
Boosts
Views
Activity
Jan ’26
Signed app can't be verified
I've signed an app, zipped it, and uploaded it to github. When I download it on another Mac, I get it can't be opened because it could not be verified for malware. But on that computer, I can verify it with codesign, and it appears to be correct (as far as I can tell). I can copy/paste the app from my other Mac, and that copy will run without problem. sys_policy, however, gives: Notary Ticket Missing File: ReView.app Severity: Fatal Full Error: A Notarization ticket is not stapled to this application. Type: Distribution Error This is the same for the copy that runs, and the copy that doesn't. The difference between them appears to be a quarantine xattr. I can delete this, and the app launches without incident. Is this expected? Why should a signed app be quarantined just because it's been downloaded? The whole point of paying the fee is to avoid the security obstacles...! ;-)
Replies
3
Boosts
0
Views
880
Activity
Jan ’26
Reply to "Application damaged and can't be opened' error prompt on 15.6.1 Sequoia
Yes, also on Mac where my application is seen earlier Yes, I perform install using sudo installer command which is a standard way of installation Yes, that's correct. Some more information: Running codesign --verify --deep --strict /path/to/your.app throws the following error, invalid resource directory (directory or signature have been modified) If I run sudo codesign --verify --deep --strict /path/to/your.app, it does not throw any error. I have verified the sudo command run with the verbose option, it says valid on disk and satisfies its Designated Requirement
Topic: Code Signing SubTopic: General Tags:
Replies
Boosts
Views
Activity
Jan ’26