Frequently Asked Questions
What versions of macOS does Apparency support?
- macOS 10.15 (Catalina)
- macOS 10.14 (Mojave), but note no Quick Look support
We don't know how or if Apparency works on the preview of macOS 11 (Big Sur). Unfortunately, we don't have a spare Mac that's capable of running it, and are't eager to let it near our primary machine. If you find problems under Big Sur, you're welcome to let us know, but we can't promise to fix anything.
Does Apparency automatically check for updates?
Yes, once every 2 weeks — or less, if you use it less often — Apparency will download a small file from our website to get the current version number. If a newer version is available, you'll see an Update Available button on the right side of the app's title bar:
Click on Update Available to open the Apparency download page, where you can get the latest version.
If you want to change the frequency with which Apparency checks for updates, or turn off automatic checking entirely, use Apparency > Preferences > Update:
Apparency never automatically downloads or installs the actual updated app. You make the decision about when or if to download it, and where and how to install it.
Why should I care about these details of an app?
You shouldn't need to care about these details. And maybe you don't need to care about them — that is clearly Apple's position on the matter.
But if you do care about them, shouldn't it be easier to get the information?
Apparency is primarily for people who already know that they wanted something like this. If it doesn't sound like something you want, we won't try to convince you. After all, we make the same $0 whether you use it or not.
“But isn't [security feature X] just more Apple security theater?”
Maybe. Maybe not. But what is theater without an audience? ¯\_(ツ)_/¯
Seriously, we don't claim to be authorities in this. There is no shortage of other people who have opinions on the matter. Apparency simply provides visibility into the mechanisms that exist. You can decide for yourself how much trust to put in them.
Is Apparency “sandboxed”?
Yes, it is. In fact, you can easily see this using Apparency itself.
To quickly open Apparency using Apparency, use Cmd-Option-O. You can see that App Sandbox is enabled.
You can also see that the app has an entitlement for reading user-selected files — this is
required to be able to see the apps that you open, even if they are in a place that is not otherwise
accessible to sandboxed apps (such as your home folder). It also has an entitlement for talking to the
com.apple.security.syspolicy service — this is required for Apparency to successfully check an app for notarization.
Additionally, if you look under the MRSFoundation.framework component, you'll find a com.mothersruin.MRSFoundation.UpdateCheckingService.xpc service, which is also sandboxed and entitled. This is the component that performs the periodic check for updates, and must be entitled to initiate an outgoing network connection.
Why don't I get a Quick Look preview on macOS 10.15 (Catalina)? What if I prefer the standard preview instead?
Once you've opened Apparency for the first time, macOS ought to enable its Quick Look Preview extension, so that previewing an app from the Finder will show the enhanced version.
However, if you don't get the expected preview, open System Preferences and go to Extensions > Quick Look and make sure Apparency is checked.
If you'd rather not use the Apparency preview — but want to keep the Apparency app — you can disable the previews here as well.
Why isn't Quick Look supported on macOS 10.14 (Mojave)?
In macOS 10.15 (Catalina), Apple introduced a new scheme for apps that want to provide Quick Look previews, and has now “deprecated” the old scheme. These schemes are completely different, so supporting the pre-10.15 scheme would be a lot more work with no future. We are not enthusiastic about such work, even though we are sympathetic to people remaining on macOS 10.14 (Mojave) — especially since we are, too!
Why the name “Apparency” anyway?
It's a portmanteau of “app” and “transparency.”
Yeah, we know, but naming things is hard. At least we didn't give it a name that makes people think it's malware, like last time.
What do the different Notarization statuses mean?
In the info pane, the Notarization status is described with one of the following:
|Granted||The app or component was submitted to Apple's notarization service and approved for distribution.|
|None detected||The app or component does not appear to be notarized. This might be caused by an inability to connect to Apple's servers. However, a network connection is required only the first time that macOS checks for notarization of a given app, and then only if the notarization is not “stapled” to the downloaded copy. So even in the absence of Internet connectivity, it is likely the app is not actually notarized.|
|Not applicable||The app or component is signed by Apple directly, and therefore is not required nor expected to be notarized. This typically applies to apps installed with macOS, downloaded from the Apple web site, or installed from the Mac App Store.|
|Verifying signature||Apparency is still verifying the signature on the app or component, and can't evaluate the notarization status until this is complete.|
|Multiple values||Multiple apps or components are selected in the browser, and these have different notarization statuses. Select a single component to see its notarization status.|
What do the different Gatekeeper statuses mean?
In the info pane, the Gatekeeper status is described with one of the following:
|Apple System||The app or component was signed by Apple, and is always allowed to run. This applies to apps pre-installed with macOS and to some software downloaded from the Apple website — including most developer tools.|
|Mac App Store||The app or component was signed by Apple for distribution via the Mac App Store, and is always allowed to run.|
|Notarized Developer ID||The app or component was signed with an Apple-issued Developer ID certificate, and subsequently
approved for distribution by Apple's notarization service. The code will be allowed to
run by default, unless disabled via System Preferences, under
Security & Privacy > General > Allow apps downloaded from
(where “identified developers” refers to Developer ID certificates), or
via system policy changes made through the |
|Developer ID||The app or component was signed with an Apple-issued Developer ID certificate, but does not appear to be notarized. However, since the developer began distributing apps under this Developer ID prior to the release of macOS 10.14.5 (April 8, 2019), macOS will allow this code to run without notarization.|
|Can't evaluate||Apparency can't evaluate the Gatekeeper status because the signature itself is not valid, as shown by the Signed By identity (and documented below). Since the identity of the signing certificate can't be relied upon, it doesn't make sense to evaluate that identity against any Gatekeeper policy.|
|Not evaluated||Apparency isn't able to evaluate the app or component against the Gatekeeper policies. Currently, this should only be the case for kernel extensions, which have special requirements that go beyond those for normal apps. (In particular, the Apple-issued Developer ID certificate must be explicitly approved for signing of kernel extensions, so an additional level of Apple review is involved.)|
|Rejected||The app or component was signed with a certificate that is not trusted by Gatekeeper (or perhaps not even by macOS; see below). This might be case the if the component was signed with a third-party certificate (which would be uncommon) or perhaps with an Apple-issued certificate that is not of the Developer ID variety (such as an App Store distribution certificate, which is only supposed to be used for submission to Apple, but is sometimes mistakenly used elsewhere).|
|Unnotarized Developer ID||The app or component was signed with an Apple-issued Developer ID certificate, but does not appear to be notarized. Because the developer began distributing apps under this Developer ID after the release of macOS 10.14.5 (April 8, 2019), macOS will not allow this code to run without notarization.|
|Verifying signature||Apparency is still verifying the signature on the app or component, and can't evaluate the Gatekeeper status until this is complete.|
|Multiple values||Multiple apps or components are selected in the browser, and these have different Gatekeeper statuses. Select a single component to see its Gatekeeper status.|
What do the different Signed By identities mean?
In the info pane, the Signed By identity will resemble one of the following:
|Software Signing||The app or component was signed by Apple. This Apple certificate is used to sign the components of macOS itself (including those delivered through Software Update), as well as some software distributed through the Apple website, including most developer tools.|
|Apple Mac OS Application Signing||The app or component was signed by Apple, prior to making it available on the Mac App Store. This applies to all apps from the store, whether made by Apple or by other developers. (All apps submitted to the Mac App Store are re-signed with this certificate before being made available for sale.)|
|Johnny Appleseed (123DE678IJ)||The app or component was signed with the named certificate. The exact format varies with the type of certificate and the issuer. If it's an Apple-issued Developer ID certificate, there will usually be a parenthesized string of numbers and letters at the end, as in this example: this is the team identifier that Apple assigned to that developer's account. Click Show Code Signature to see details about the signing certificate.|
|No signature||The app or component was not signed at all. This is often the case with older apps, or with developers who aren't particularly excited about paying Apple US$99 per year for the privilege of shipping software for macOS.|
|Ad-hoc signature||The app or component was signed without using a certificate. This now-uncommon scheme allows certain code-signing features (such as entitlements) to be used with effectively unsigned code. But ad-hoc signatures don't tell you anything about the developer's identity.|
|Untrusted certificate||The app or component was signed with a certificate that is not trusted by macOS. That is, the certificate was not issued by a certificate authority that macOS trusts. (For comparison, a Developer ID certificate is issued, ultimately, by the Apple Root Certificate Authority.) This is uncommon for modern apps, although in the olden days, self-signed certificates were used to establish that different versions of an app came from the same developer, and should have access to the same keychain items (even if the identity of that developer was otherwise unverified).|
|Can't verify signature||The app or component appears to have been corrupted or tampered with since being signed. As such, the identity implied by the signing certificate is not reliable. This could be a result of the app being compromised at the point of download. Or it could simply be the result of errors occurring during signing, or in a software update process — the latter is depressingly common, even and especially for built-in macOS apps.|
|Skipped verification due to size||The app or component is so large that Apparency suspects it would take an unusually long time to verify, and so did not try to do so automatically: see more on this below.|
|Failed to read signature||A low-level error occurred in the macOS security subsystem while attempting to read the signature. If this occurs, it probably indicates corruption of the app that fundamentally damaged the signature, and is unlikely to be recoverable.|
|Verifying signature||Apparency is still verifying the signature on the app or component, and can't report the signing identity until this is complete.|
|Multiple values||Multiple apps or components are selected in the browser, and these have different signing identities. Select a single component to see its signing identity.|
Why does Apparency sometimes say that it skipped verification of the signature?
In order to verify the signature of an app or component, every file that makes up that component has to be read in its entirety, creating a cryptographic digest (or hash) of the complete component. This digest is then compared against the one that was produced when the component was signed by the developer. Any changes that are made to any file of the component are thus detected, because it will result in a different digest and invalidate the signature. (This is a bit of an oversimplification, but conceptually accurate anyway.)
In most cases, creating the digest takes a few seconds at most, and the signature is verified quickly. However, for extremely large apps, verification can start to take real time. For example, Xcode — weighing in at over 10 GB in size — can take several minutes to verify. (Anyone who has ever installed Xcode has surely noticed the long delay upon first launch!) You might want Apparency to do the verification anyway, if the signature is the information that you're interested in inspecting, but otherwise, it is just an annoying use of your CPU.
Apparency tries to guess when an app or component is so large that the verification will take an unusually long time. Where it believes this to be the case, Apparency will not automatically verify that component. Instead, it shows the Signed By identity as Skipped verification due to size. When this occurs:
- If you don't care about the signature of the component, you can ignore this entirely.
- If you would like to proceed with verification of the signature for just this single component, select it, click the Signature toolbar button (or use Cmd-Shift-S), and then choose Verify Signature.
- If you would to proceed with verification of the signatures for all components in this app, choose File > Verify All Signatures.
- If you would like Apparency to always verify all signatures, even where it believes that this make take a long time, go to Apparency > Preferences > General and uncheck Skip automatic signature verification for large code.