“codesign”

[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

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!

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

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

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

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