A User Guide
Opening an App in Apparency
There are several ways to open an app using Apparency:
- In Apparency, choose File > Open, locate the app and click Open.
- In the Finder, locate the app and do one of the following:
- Drag the app icon onto the Apparency icon, either in your Dock or in your Applications folder.
- Select the app icon and choose Finder > Services > Open With Apparency (under the Development group).
- Control-click the app icon and choose Open With Apparency, near the bottom of the context menu.
- If the app is in your Dock, control-click on its icon there, and choose Options > Show In Finder. Then continue in the Finder as above.
If you don't see the Open With Apparency item in the Services menu or in the Finder context menu, choose Finder > Services > Services Preferences, scroll down to the Development group, and make sure that Open With Apparency is checked. You can also add a keyboard shortcut here, if you wish, but that's not necessary to make the menu item appear.
Whichever method you choose, Apparency opens a new window, showing the app itself, along with any components inside it:
You can actually open any macOS bundle with Apparency, including an app plug-in or a system framework. You can also open a “bare” executable file, such as one found in /usr/local/bin. A bare executable can have many of the same attributes as a bundle, and can even have an embedded Info.plist.
Examining the App Structure
The browser, on the left side of the main Apparency window, shows the basic structure of the app:
At the top of this view is the app itself. Most apps also contain other components inside them — frameworks, plug-ins, app extensions, Spotlight importers and so on. These components are shown underneath the main app, using a hierarchical view similar to the Finder's List view. If any of the components contain sub-components, use the disclosure button to expand these further.
Apparency doesn't show all of the individual files inside the app bundle. The Finder is a better tool for navigating files: control-click the app icon and choose Show Package Contents.
Rather, Apparency shows bundles — and bare executables — that are found in defined places within the app, as defined by macOS. For example, macOS requires app extensions to be placed in Contents/PlugIns, so that is one place that Apparency looks. The point is to show components that add to system functionality (as is the case with app extensions, for example), as well as those that are simply part of the app's internal organization (such as frameworks).
The columns of the browser show some basic information about the app, and any components:
- The Kind column shows the type of component, akin to what the Finder would show for this bundle (although for certain types, such as app extensions, Apparency tries to provide a more detailed kind).
- The Version columns shows the full version information, such as you'd see in a standard app About window.
- The Signature column gives a summary of the code signature information for the component, which is discussed at much length below.
Click on the Name, Kind or Version column title to re-order the components accordingly. This can be useful for an app with a large number of components.
Getting Information About a Component
The info pane, on the right side of the main Apparency window, shows information about the app or other component that is currently selected in the browser:
In the top part of the info pane, Apparency shows general information about the app or component:
- Kind is akin to the Kind shown by the Finder. You can click on this text to cycle between the kind description and the underlying Uniform Type Identifier (UTI) that macOS defines for this kind (e.g. “com.apple.application-bundle”).
- Kind Detail is shown only for certain kinds of component. For example, for an “Application and System Extension,” Apparency shows the specific type of extension, such as “Photo Editing Extension” or “Share Extension.” You can click on this text to cycle between the the detail description and the underlying identifier (e.g. “com.apple.share-services”).
- Where shows the location of the component. Except for the app itself, the location is given relative to the app or other immediate containing component. If you want to go to that location, you can choose Component > Show Component In Finder (Cmd-Shift-R).
- Identifier shows the bundle identifier of the component. This is the name by which macOS knows the app or component, and you'll sometimes see these identifiers used elsewhere, such as in the name of preferences files or in Console logs.
- Version shows the full version information, such as you'd see in a standard app About window: the first number is the “short version” and the one in parentheses is the “bundle version,” which are both significant parts of Apple's standard versioning scheme.
- Copyright shows the copyright information associated with the bundle. If this ends with an ellipsis (…) character, Apparency truncated long copyright text, but you can hold the pointer over it to show the full text.
Document Types and Other Info.plist Properties
In the middle part of the info pane, Apparency shows a summary of the file and other types that the app provides to macOS, via its Info.plist file:
- Document Types tell macOS what kind of files the app can open, such as through the File > Open dialog, or via drag-and-drop. These can include standard types (like text or JPEG files) and/or app-specific types (like a Keynote presentation).
- Uniform Type Identifiers (or UTIs) define new types of files that are not standard to macOS. These typically work together with the Document Types, but are not necessarily the same lists — an app doesn't need to re-define standard types, but it may define types for files that are not documents per se (such as a plug-in or the like).
- URL Schemes tell macOS what kind of URLs the app can handle. Sometimes, these
are common URL schemes; for example, an FTP client might declare that it handles
ftp:URLs, while Apple Mail handles
mailto:URLs. More often, these are new schemes that are custom to the app, and begin with an
x-prefix by convention. Custom schemes are typically used for lightweight inter-app linking, such a URL in a purchase receipt e-mail, which when clicked, opens the app and pre-populates the registration dialog.
- Services define new items that the app would like to add to the Services menu in the Finder and/or other apps. Services act on a selected item — such as a file, some text or an image — and do something with it, depending on the app. In fact, this is how Apparency adds the Open With Apparency item to the Finder: in this case, the something that Apparency does is simply to the open the selected app. Note that services provided by apps can be enabled or disabled, so that you don't wind up with a Services menu cluttered with garbage you never use: open System Preferences and go to Keyboard > Shortcuts > Services.
For each of these, Apparency simply shows how many of each type is found (because it is difficult to summarize the contents in any succinct way). To see the actual definitions, click the button in front of the number: this will show the Info.plist, with the appropriate property selected and expanded.
Code Signature, Sandbox and Gatekeeper Info
In the lower part of the info pane, Apparency shows the status of the code signature and other security features:
- App Sandbox shows if the app is sandboxed, which is Apple's scheme for limiting the capabilities of an app (something like the restrictions on all apps in iOS). Apps distributed through the Mac App Store are required to use the App Sandbox, but other apps may also do so.
- Hardening shows if additional runtime protections have been enabled. This feature was introduced in macOS 10.14 (Mojave), and is intended to limit the damage that a compromised app can do, by turning off capabilities that it doesn't normally require. Hardening generally covers a different set of capabilities than — and is less restrictive than — the App Sandbox, so an app might use both.
- Notarization shows if the app was submitted to Apple's notarization service, which checks for certain security features (such as hardening) and does some sort of malware scan. If these automated checks pass, Apple grants a notarized status to the app. A description of each possible notarization status is available here — or move the pointer over the status and click the help button that appears.
- Entitlements are assigned to the app when it is signed by the developer. An entitlement is an Apple-defined property that grants some capability to the app, as described below. Click the Show Entitlements button to show these properties.
- Gatekeeper shows how the Gatekeeper feature of macOS would handle the app when you open it after download, at least by default. Gatekeeper checks the code signature and notarization status, among other things, to determine an applicable “policy.” A description of each possible Gatekeeper status is available here — or move the pointer over the status and click the help button that appears.
- Signed By shows the name of the certificate that was used to sign the app. Typically, this is either an Apple certificate — for apps that come with macOS, or that are downloaded from the Mac App Store — or an Apple-issued Developer ID certificate, in which case the name of the developer is shown. Descriptions of possible Signed By identities are available here — or move the pointer over the identity and click the help button that appears.
Getting Details About a Component
While the info pane gives you a summary of the selected app or component, there are buttons in the toolbar that allow you to see more details. (Some of these are also available through buttons in the info pane itself; use whichever one is more convenient.)
Show the Code Signature
If the selected app or component was signed, click the Signature toolbar button (or use Cmd-Shift-S) to see the actual signing certificate and other details about the verification of the signature (including the applicable Gatekeeper policy, as discussed above).
Click the Show Certificate button to examine the certificate that created the signature, and the entire chain up to the (hopefully) trusted Certificate Authority, which is typically the Apple Root CA.
Show the Info Property List
The information property list — or simply, the Info.plist — contains a number of Apple-defined properties. These tell macOS how the app or component works, what it can do, what icon to show, what documents it can handle, and many other things. Apparency extracts a few interesting bits of the Info.plist to show in its info pane — such as the version information, the bundle identifier, and so on — but you may still want to examine the Info.plist in its entirety.
Click the Property List toolbar button (or use Cmd-Shift-I) to view the Info.plist file for the selected app or component:
Most of the Info.plist keys have some sort of documentation on Apple's Developer site: to jump directly to that documentation, select a row and click Open Apple Documentation for Key. (If this button is disabled, Apparency doesn't have a direct link for that key, either because the key isn't documented or because we didn't find the documentation to index it.) Alternatively, when you move the pointer over a key name, if a link button appears on the right side, clicking this will also take you to the documentation for that property.
If you're looking for a particular key or value, click in the search field (or use Cmd-F) and type the text you want to find. Apparency will show only the rows that match, or for arrays or dictionaries, the rows that contain matches. Click the search options button to choose between searching keys and values, or to restrict the way that text matches. Click the cancel button to return to viewing the unfiltered Info.plist.
Show the Entitlements
The entitlements of an app or component represent specific capabilities that the component requires to do its work. macOS grants (or denies) these capabilities to the app or component, based on the entitlements and (sometimes) other restrictions. Entitlements take several forms:
- If the App Sandbox is enabled, macOS denies many capabilities by default (for example, the ability
to read or write user files, or to make or receive network connections). The required capabilities
are then granted by macOS if the appropriate entitlement is present; for example, setting
YESallows outgoing network connections. (This ability is limited to the entitlements that are defined by Apple, and for apps distributed through the Mac App Store, they are subject to rejection by App Review.)
- If Hardening is enabled, the scheme is similar: macOS defaults to denying a number of less commonly
needed capabilities — especially ones that Apple deems subject to exploitation if the app is compromised.
If the app actually requires any of those capabilities to function properly, the appropriate entitlements will
cause macOS to grant them. For example, setting
YESallows the app to request location information.
- Outside of App Sandbox or Hardening, many macOS capabilities and Apple services are available only to apps or components having the appropriate entitlements. For example, the ability to receive push notifications, or the ability to use iCloud services, are controlled by entitlements. (Again, these may be subject to App Review if the app is distributed through the Mac App Store.)
- A few entitlements relate to the sharing of data between different apps from the same
developer. For example,
com.apple.security.application-groupsestablishes shared folders (under your Library/Group Containers folder) which multiple apps can use to store or exchange data (this is particularly relevant if the apps are otherwise sandboxed).
- Finally, there are a vast number of private-to-Apple entitlements, which control access to macOS
services that Apple deems as off-limits to third party apps entirely. The ability to
access Internet Accounts information, or to talk to the App Store, are two examples, but there are
many, and they are undocumented, for obvious reasons. Typically, these entitlements start with a
com.apple.privateprefix (but some that don't are probably still considered private). Note that macOS typically refuses to grant capabilities for private entitlements unless the app or component was signed by Apple itself.
Click the Entitlements toolbar button (or use Cmd-Shift-E) to view the entitlements for the selected app or component:
As described above for the Info.plist, documentation links to Apple's Developer site is available for some entitlement keys.
Likewise, you can use the search field to filter entitlements on specific key or value text.
Show Executable Information
Apparency can show details about the actual executable file associated with an app or component. Click the Executable toolbar button (or use Cmd-Shift-X) to view this information for the selected component. (If the button is disabled, the component doesn't contain an executable at all, which can be the case for certain types of components, like plug-ins.)
The information shown for an executable is mostly of the sort you would otherwise need the
objdump(1) tools to access:
- The Location shows the path to the executable file, relative to the component itself. Click the adjacent Show in Finder button to reveal the executable.
- The Type shows the Mach-O binary type of the executable, which generally follows from the kind of component — a dynamic library for a framework, a bundle for a plug-in, an executable for an app extension, and so on.
- The macOS Deployment Version shows the earliest supported version of macOS that was specified by the developer when building the executable. This information is generally also encoded in the Info.plist of the component, but not all components have an Info.plist, and this is a more direct record of the configuration specified when the executable was linked.
- Likewise, the macOS SDK Version shows the newest version of macOS from which the executable uses system APIs. That doesn't mean it won't run on newer versions of macOS, just that it doesn't use any APIs that were introduced on newer versions. In practice, this pretty much corresponds to the version of Xcode that was used to build the executable, since Apple no longer provide multiple SDK versions within a single version of Xcode.
- The Dynamic Library Install Name (applicable only for the Mach-O dynamic library type)
shows the internal install path for this library. This is saved at app build time, so that the library can be
found again when the app is eventually run. For most dynamic libraries packaged inside of an app, this will start with the
@executable_pathvariable, which locates the library relative to the component that is using it, no matter where the app itself is installed. See the
dyld(1)man page for more information about these special values.
- Dynamically Linked Libraries shows all of the dynamic libraries that are used (directly) by this
executable. This is typically a mixture of macOS system libraries and (perhaps) frameworks or dynamic libraries
bundled with the app. The Where column shows where each library is expected to be found; this comes
from the library's Dynamic Library Install Name (see above), and might use a special value like
@rpath. The libraries are initially sorted by the specified link order, but you can click the column headings to re-order them; sorting on the Where column is a handy way to group system libraries and bundled ones. The last two columns show if any of the libraries are weakly-linked (🔗) or are being re-exported as part of an umbrella framework (☂️).
- Runtime Search Paths shows any locations that will be searched to find Dynamically Linked Libraries
which have a Where starting with
@rpath. In other words, these are the paths that are substituted for
@rpathby the linker at runtime, in order to find the library. If these are used, they will generally be relative to one of the other special variables,
@executable_path. Again, see the
dyld(1)man page for more information.
- DYLD Environment shows any equivalent environment variables that the dynamic linker should assume
are set when loading this executable or library. This is unusual, but can be used to influence which
Dynamically Linked Libraries are found; for example, Safari sets
DYLD_VERSIONED_FRAMEWORK_PATHto find a possibly newer version of WebKit than is used by other apps on the system. The
dyld(1)man page documents these environment variables.
Examining Components in Other Apps
Occasionally, you may want to see a specific component in the Finder; for example, to look at the individual files that it contains. You can do this easily from Apparency: select the component in the browser, and click the Show in Finder toolbar button (or use Cmd-Shift-R).
Alternatively, if you want to examine a component in the Terminal, you can select it and choose Edit > Copy Path for Component (Cmd-Shift-C). Then you can paste that path into the Terminal, or wherever.
If you want to show — or copy the path to — the executable, instead of the component itself, hold down Option while doing the above.
Using From Quick Look
Apparency provides a Quick Look Preview extension for macOS 10.15 (Catalina), which adds a bit more information to the standard macOS preview for apps.
The Apparency preview works in any normal Quick Look context. For example, if you open a Finder window to your Applications folder and choose View > as Gallery, you'll get an enhanced preview for the selected app:
Note that the information in the Quick Look preview is only for the top-level app that you select; it doesn't consider any components within it. Click the Open With Apparency button to easily open the app in Apparency, where you can see all the details.
Unfortunately, the Quick Look preview isn't available on macOS 10.14 (Mojave).