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!

Can't figure out how to post the log file.

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.

when I try to verify the signature I get the above error.

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. Most of them will throw that error and also log more details to the system log. So, you can often learn more by:

1. Verifying the code signature.
2. Then immediately triggering a log snapshot.
3. Looking in that snapshot for the first instance of error -67071.
4. Then looking around those log entries for things that seem relevant.

See Your Friend the System Log for lots of hints and tips on how to use the system log effectively.

Alternatively, if you’re able to post a URL to a place where I can download your app, I’d be happy to take a look.

See tip 14 in Quinn’s Top Ten DevForums Tips for advice on how to post links.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

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:

1. In a fresh macOS 26.3.1 VM, I downloaded that zip archive in a way that sets quarantine.
2. I unpacked it using the Finder.
3. 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 know what you see.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Ok, I get the same results as you. Not sure what is going on. It also executes with no problems on another macbook air I have. I will assume that I am good and proceed. Thank you for your time and effort on this

Weird.

On the machine with this problem, are you running your tests on a non-Apple file system? So, something like FAT32, rather than APFS or HFS Plus? That’s sometimes the cause of weird problems like this.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

So I am running APFS. But ... Instead of the default case-insensitive, I set up the file system as APFS case-sensitive. Hmm ...

I set up the file system as APFS case-sensitive.

I’ve seen that cause problems in the past. However, I don’t think that’s the case here. I created a case-sensitive APFS disk image, copied your zip archive to that, and repeated my tests there, and everything still worked.

But, yeah, a disk image is a great way to test stuff like this.

If you managed to figure out what’s causing this, please reply here with the info. I’m super curious.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I have not managed to figure out what is causing this. Since it runs on my OSX VM w/o problems, I am kind of just ignoring it. I will continue to monitor this as I continue to my 1.0 release

I will continue to monitor this

Please update this thread if you learn more. I try to keep track of all the weird code signing errors and what causes them — one day I’ll write a technote based on that — and I’m super curious how you’re hitting this.

Oh, actually, come to think of it, you can reproduce this, so it’d be worth filing a bug about it. So, if you have the time and inclination:

1. Create a read/write disk image that’s big enough to hold your app.

2. Copy the app on to it.

3. Reproduce the error.

4. And then immediately trigger a log snapshot:

   % sudo log collect --last 5m
   

   Adjust the --last parameter to a bigger value if code signing takes a really log time (-:

5. And then a sysdiagnose log.

6. Unmount the disk image.

7. File a bug with that disk and the logs from steps 4 and 5.

Once you’re done, reply here with the bug number and I’ll see what I can uncover.

But I do understand if you’re not able to do this; you have a workaround already and an app to ship!

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I have the log files ready. Can you point me to where to file this bug report

I put them here but not sure if this is correct

https://feedbackassistant.apple.com/feedback/22267132

I put them [in FB22267132] but not sure if this is correct

That’s cool.

When I open the system log snapshot you included (system_logs.logarchive) I see this:

type: default
time: 2026-03-17 21:32:51.951555 -0500
process: spctl
subsystem: com.apple.securityd
category: security_exception
message: UNIX error exception: 2

type: default
time: 2026-03-17 21:32:51.951587 -0500
process: spctl
subsystem: com.apple.securityd
category: security_exception
message: MacOS error: -67068

type: default
time: 2026-03-17 21:32:51.951603 -0500
process: spctl
subsystem: com.apple.securityd
category: security_exception
message: MacOS error: -67071

type: default
time: 2026-03-17 21:32:51.951615 -0500
process: spctl
subsystem: com.apple.securityd
category: security_exception
message: MacOS error: -67071

This seems like an understandable error cascade:

• The first error, 2, is ENOENT, which is an error commonly returned by the BSD subsystem when a file is not found.
• The next, -67068, is errSecCSStaticCodeNotFound, which is an obvious mapping of that.
• And that gets translated into -67071, the error we’re hunting here.

Unfortunately there isn’t any info about the actual paths involved. You might be able to get that info by running fs_usage and looking for that error 2 being reported to spctl.

When fs_usage reports an error it places it within square brackets. For example, this is what I see what I try to cat a file that doesn’t exist:

% sudo fs_usage -w | grep cat 
…
15:08:21.962560  open       [  2] (R…)  does-not-exist.txt      0.000022   cat.2356285
…

where [ 2] indicates that the open failed with ENOENT.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"