In this article
The distinction matters when an app’s name looks unfamiliar, a download appears damaged, or a guide tells you that printing a developer name proves everything is fine. You can gather useful evidence without launching the app or changing its security settings.
Start with the exact app in Finder
Find the installed .app in Finder. If you have multiple copies, choose the one you actually intend to inspect. An app in Downloads, an older copy on an external disk, and the copy in Applications can have different versions and signatures.
Open Applications → Utilities → Terminal. The examples below use /Applications/Example.app as a placeholder; replace it with the actual app path. Keep the quotation marks when the name contains spaces. Alternatively, type the command and its final space, then drag the app from Finder into Terminal to insert its path.
These inspection commands do not launch the selected app, re-sign it, or require sudo. A path error is a reason to check your selection, not to change permissions.
Read the signing information
Run:
codesign --display --verbose=4 "/Applications/Example.app"
For a Developer ID signed app, the output commonly includes an identifier, one or more authority entries, and a team identifier. The authority names describe the signing certificate chain; the team identifier helps distinguish developers whose display names might otherwise be confusing.
Compare that information with evidence from the developer’s official distribution or support documentation. A familiar-looking app name is not a substitute for matching the expected developer. Conversely, a publisher’s legal company name can differ from the product’s brand.
Treat an ad-hoc signature differently: it can seal files for integrity checks without establishing a Developer ID certificate chain. “Signed” is therefore too vague a label to answer who distributed an app. Apple explains the certificate relationship in Inside Code Signing: Certificates.
The display command can also show diagnostic information on Terminal’s standard-error stream. Seeing that output does not, by itself, mean the command failed. Read the actual message rather than judging the stream or the amount of text.
Verify the bundle separately
For a separate integrity check, run:
codesign --verify --deep --strict --verbose=2 "/Applications/Example.app"
This requests verification, including nested code, with stricter bundle checks. It can take longer for a large application. Apple’s Code Signing Tasks guide documents examining and validating signatures as different operations.
A successful verification means the selected code passed that check under the stated options. It does not evaluate whether the app’s behavior is desirable, whether you intended to install it, or whether its requested access is appropriate for your work.
If verification fails, retain the error and the app’s version. A modified resource, a missing file, and a malformed bundle are different findings. Do not automatically label every failure as malware, and do not “repair” an unfamiliar download by replacing its signature. Obtain a fresh copy from the developer’s official source or ask the developer to explain the specific error.
A controlled test: display still worked after a change
We tested this on macOS 15.7.5 on October 2, 2026, using a disposable local app bundle. It contained a copied system executable and one text resource, and was signed ad hoc for this experiment. We did not launch it, modify an installed application, or use a Developer ID certificate.
First, both commands completed successfully. We then changed only the text resource inside that same bundle and repeated the checks.
| Check | Before changing the resource | After changing the resource |
|---|---|---|
| Display signing information | Exit status 0; identifier visible | Exit status 0; identifier still visible |
| Verify the signed bundle | Exit status 0 | Exit status 1; modified resource reported |
The second display result did not undo the failed verification. It showed that signing information was readable even though a sealed resource had changed.
This is a narrow demonstration of command behavior, not a test of Gatekeeper, notarization, or malware detection. The fixture had no third-party developer identity to validate. Its useful lesson is practical: do not substitute readable signature details for a verification result.
Keep Gatekeeper and notarization as separate questions
Gatekeeper applies macOS policy to downloaded software. Apple’s guide to safely opening apps describes checks involving developer identity, alteration, notarization, and known malicious software. A notarized submission has been checked by Apple for known malware; that is not an unlimited guarantee about future behavior or suitability.
For an app you have not decided to trust, you do not need to launch it just to collect the signing information above. If macOS has already displayed a warning, keep that warning and the exact message as part of your evidence. A successful codesign verification is not an instruction to override it.
The three questions are distinct:
| Question | Useful evidence |
|---|---|
| Who signed this copy? | Signing certificate information and an expected developer identity |
| Did its signed files pass verification? | The separate codesign --verify result |
| Does macOS allow this downloaded software under its policy? | The relevant Gatekeeper assessment or warning |
Also keep signatures separate from privacy access. An entitlement embedded in signed code does not prove that you granted Camera, Microphone, or Full Disk Access. Our guide to entitlements versus current macOS permissions explains that boundary.
Use the result to identify the next step
If the signer is expected and verification succeeds, you have stronger identity and integrity evidence. You still need to consider the download source and what the app does. If the identity is unexpected or verification fails, stop treating the filename as proof and resolve that discrepancy first.
VaultDog’s application passport can help connect an installed app with its signing identity and related artifacts. Its identity check is not a full bundle-integrity or Gatekeeper assessment, and Apple notarization for other apps is not checked. Use the separate native verification above when integrity is your question.
If this investigation began with an unfamiliar helper, continue with identifying an unknown background item. Match its path and owner before deciding whether it belongs to software you use. A developer identity is one piece of that investigation, not the final verdict.
