Show application locations matching Finder's behaviour - #3128
Open
danielcompton wants to merge 4 commits into
Open
Show application locations matching Finder's behaviour#3128danielcompton wants to merge 4 commits into
danielcompton wants to merge 4 commits into
Conversation
danielcompton
force-pushed
the
claude/gifted-haslett-5d6265
branch
from
August 20, 2026 04:11
ab3007d to
f86b306
Compare
skurfer
reviewed
Aug 20, 2026
skurfer
left a comment
skurfer
left a comment
Member
There was a problem hiding this comment.
Looks good, but I had a couple of questions.
macOS ships some system apps (Safari, and previously others) in a cryptex that is grafted into the file system, so the same file is reachable both through its user-visible path (/Applications/Safari.app, a symlink) and its backing location (/System/Cryptexes/App/... or the resolved /System/Volumes/Preboot/Cryptexes/App/... form that directory enumerators report). Finder also presents the system domain Applications directories merged into the local /Applications folder, which is where users know apps like Find My and Music. There is no direct API for either mapping (see https://developer.apple.com/forums/thread/745673, which also notes Spotlight paths for these files are unstable across index states), so derive it from NSSearchPathForDirectoriesInDomains(NSApplicationDirectory, NSSystemDomainMask), which reports both /System/Applications and the App cryptex directory: - URLByMappingSystemApplicationsToLocalDomain maps a path inside a system Applications directory (any form) to the local /Applications equivalent: the Finder-displayed location, which may not exist on disk. Paths inside bundles are left unmapped, as in Finder. - URLByResolvingToUserVisiblePath additionally requires the mapped path to exist and be the same file (NSURLFileResourceIdentifierKey, the identity check recommended by Apple DTS), so it always returns a path that exists. The mapping is gated on a string prefix comparison, so paths outside the system Applications directories cost no filesystem access. Part of quicksilver#3125
Launch Services and directory scans through /System/Cryptexes report cryptex-shipped apps (e.g. Safari) at their backing location, so the catalog showed Safari at /System/Volumes/Preboot/Cryptexes/App/System/Applications/Safari.app instead of /Applications/Safari.app. The different sources (Applications preset, Additional Applications preset, and Find All Applications) could also each produce a distinct object for the same app because their paths differed. Resolve application URLs to their user-visible path in the two catalog sources that see backing paths: the Launch Services app list (allApplicationsURLs) and QSDirectoryParser (for application bundles only), so every source yields the same object at the path users see in the Finder. Part of quicksilver#3125
Apps like Find My and Music were displayed with /System/Applications, and symlinks to the App cryptex (like /Applications/Safari.app) with their fully-resolved backing path under /System/Volumes/Preboot, instead of the /Applications location the Finder shows them in. Map the details string through URLByMappingSystemApplicationsToLocalDomain. The mapping is a string prefix comparison against the system Applications directories, so details for ordinary files still touch no filesystem. Fixes quicksilver#3125
With apps canonicalized to their user-visible path at catalog time, the cryptex scan yields the same object as the Applications preset for any app that also has an /Applications symlink (today, all of them). Keep the preset as coverage for a future cryptex app shipped without a symlink -- the failure mode of quicksilver#2932 -- and note that in the plist. Also scan it at depth 3 to match the other Applications presets, in case apps are ever nested there.
danielcompton
force-pushed
the
claude/gifted-haslett-5d6265
branch
from
August 22, 2026 02:50
f86b306 to
b86cd69
Compare
Member
|
I tested this out locally and pulled up Safari. The details look correct, but the Get Path action doesn’t actually grab the user-friendly path. Does that work on your end? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
macOS shows applications in the /Applications folder that may not actually exist there on disk.
There are two cases:
E.g.
This PR fixes both of these issues. It merges applications found at multiple locations, e.g. the symlinked /Applications/Safari.app + Cryptex Safari.app if they both resolve to the same user visible location.
See https://developer.apple.com/forums/thread/745673 for more discussion on cryptexes.
Changes
Fixes #3125
I checked how Alfred handles this and it appears to just use hardcoded string comparisons to replace certain applications with the user visible path. I think these changes are more principled and correct.