Apparency for Mac

New

• Enhanced Apparency's Quick Look Preview to analyze the relevant sub-components when determining signature-related attributes, such as Gatekeeper and App Sandbox. This provides a summary of what's going on beneath the top-level app. You might see a status of Multiple values where sub-components differ from the top-level (or from each other). You can also switch between top-level and combined views. [Read More]
• Also in the Quick Look Preview, if the top-level app has a status of Skipped verification due to size, you can move your pointer over that status and click the arrow button Quick Look signature details navigate button to open the Apparency app, which will either directly verify the signature — the Quick Look Preview extension has a lower size limit for automatic verification than the Apparency app does — or at least will offer a way to do so, e.g. via Component > Show Code Signature.
• Added support for the new arm64e.x1 processor architecture, which is displayed by Apparency as Apple Silicon — 64-bit, E.X1.
• Apple doesn't establish proper user-facing names for architecture types — processors are either a specific chip, like “Apple M6” or the more generic “Apple Silicon” — but we show the E.X1 suffix here to distinguish it from the Extended variant (arm64e). You can click on the architecture names in the info pane — or hold down Option in menus — to show the underlying symbolic names.
• At release time, the Hopper Disassembler didn't support this new architecture, so we don't know how to automate the analysis; as such, the Component > Analyze Executable Using Hopper Disassembler command may pause at architecture selection.
• We don't have an M6 Mac, so haven't been able to test this all properly. If you have such a machine and find a problem, let us know.
• If you're interested in the details of this new architecture type, this blog post is quite helpful.
• Resolved a performance problem that could occur after selecting a large number of components (or just doing Edit > Select All) on a complex app or folder, if the code signatures are still being verified. Apparency should no longer stall or SPOD in such cases.
• Apparency is now more consistent in its handling of sub-components that are unsigned but that live in a protected place in the containing component, such that its contents are “sealed” by that component's code signature. These are shown with a Signed By of Resource in containing bundle, whether they're found in a de facto place (like Resources) or in a more conventional place (like SharedSupport). Only sub-components in true “code places” (like PlugIns) are excluded from the containing component's resource protections.
• Refined the way that components with ad-hoc signatures are shown, when verification detects code or resources were modified. Depending on where the app originates, the difference between a valid and invalid ad-hoc signature might not matter much — even a valid one provides no developer identity, and won't pass Gatekeeper without an explicit override. But if it's something you trust — perhaps you built it yourself? — you might still want to know when and if it's modified. Also, any such modifications might prevent macOS from launching it in the future. If Apparency finds any such problems, the Signed By will now be either Can't verify ad-hoc signature or Bundle resources modified (ad-hoc). This can also happen with linker-applied ad-hoc signatures (on Apple Silicon), so you might also get Can't verify linker (ad-hoc) signature. In these cases, use Component > Show Code Signature for more info.
• Added a new rule for the Edit > Search Components command: is system plug-in is a simple Boolean test, which matches all components that are known to be plug-ins or extensions to macOS itself. This includes all manner of app extensions (such as sharing extensions, app intents and Quick Look Preview extensions) and system extensions (such as Endpoint Security extensions), as well as older types of plug-ins, like Spotlight importers and Dock tile plug-ins. The point is to find sub-components of an app that have an impact on the system overall. Note that the newer types of extensions usually run in their own process, and are usually required to use the App Sandbox; older types are typically bundles loaded into some other process, which is probably sandboxed in its own way (not necessarily via the App Sandbox mechanism).
• Reduced Apparency's insistence on re-applying search terms from previous rule-based searches, when opening the Info.plist, entitlements and other inspectors: this was supposed to be helpful, but in our experience, was mostly just annoying. Now you can selectively re-apply a recent search term by using Edit > Use Recent Search Term for Find (Cmd-E) after opening an inspector.
• Apparency now shows Dock tile plug-in components as the kind they are: these were always shown as sub-components, but were previously given a kind of Folder, because macOS doesn't define a UTI for them. Now they get an extended UTI within Apparency, and will conform to com.apple.plugin or com.apple.bundle, such as in a uniform type ID conforms to search rule.
• Added Edit > Select Components Relevant To submenu: similar to navigating from the Quick Look Preview, this allows you to quickly select all of the components relevant to a specific signature attribute (e.g. App Sandbox), and see what they have in common and what is unselected.
• Improved handing of certain macOS system frameworks where the Mach-O executable is standalone on the OS cryptex instead of being in the DYLD shared cache: Apparency can now properly open these and find both the Info.plist and the executable info.
• Added support for the dark, clear and tinted app icon styles on macOS 26 and later.
• Added new preference pane for Quick Look.