There’s no point in signing an app or any other code resource unless you test whether its signature works before it’s used for real. Although normally a reliable process, lots of things can go wrong with signing, and the time to confirm that they haven’t is straight after you’ve signed the app.

Command line tests

Apple and others detail commands that you can use in Terminal which should provide different types of check on the signed app or code bundle. These are typically of the form
codesign --verify --deep --strict --verbose=2 MyApp.app
which is intended to mimic the checks performed by Gatekeeper on a quarantined app.

Unless you thoroughly understand what you are doing, these can become complex and easy to get wrong. If they tell you that your app is signed correctly but it isn’t, they can give you a false sense of confidence. For these reasons, I only recommend their use by the experienced and knowledgeable.

General GUI test

Every Mac user needs to be able to inspect the signature of apps, and the best way to do this is using Objective-See’s free What’s Your Sign?, which puts this in the Finder’s contextual menu (Control-click etc.). Simply select the app and use the Signing Info command.

If you have applied an ad hoc signature to your app, then What’s Your Sign? reports that it has been validly-signed, but points out that there are no signing authorities. Without those authorities, some signature-based requirements, notably Gatekeeper’s full check with a quarantine flag, will fail.

If you have used a personal certificate, What’s Your Sign? identifies that too, and once again a full check by Gatekeeper with the quarantine flag set will fail.

Functional testing

The most reliable and detailed test that you can apply is to assess whether the signed app meets it designated requirement, in other words use it with the sub-system which it has to satisfy.

In the case of Gatekeeper, you can upload your app to a remote site, download it using your browser, and test the downloaded version. You can also mail it to yourself, or move it by AirDrop. Simpler and quicker than those is to apply a quarantine flag then try opening the app. This is readily done using my free Xattred extended attribute editor: open your app, click on the button to Add quarantine xattr, then try opening the app in the Finder.

In the case of ad hoc signing and that using a personal certificate, this is what you will see in response: those signing methods are not sufficient to pass Gatekeeper’s full checks.

Given that ad hoc signing and personal certificates can’t satisfy this particular requirement, the presumption in your using them is that they do enable another feature which expects code to be signed but not as rigorously, such as TCC’s privacy requirements, perhaps. You then need to check that your signed app behaves as expected with the macOS sub-system it requires. This is much harder to do using command tools, but a simple real-world functional check is better.

If your app needs Full Disk Access, try adding it to that list in the Privacy settings and browsing into your ~/Library/Mail and ~/Library/Calendars folders. As I’ll discuss in a future article, gaining access to specific controlled resources like the camera and microphone is more intricate: if you need that, then you’re almost certainly going to be better using Xcode with a proper Developer ID and signing, and the Gatekeeper test.

One final free tool which can be helpful when wrestling with signature problems and entitlements is Taccy. This goes more deeply into settings for sandboxed and hardened apps, and shows important privacy data from the app’s Info.plist file. If you’re getting into these weeds, you should be using a Developer ID with Xcode, or you’ll find the going difficult to say the least.

This conveniently takes me to getting the best out of Mojave’s privacy protection, the subject of the next article.

References

Apple’s Code Signing Guide
TN2206 Code Signing in Depth