A few days ago, Howard Oakley wrote an article LaunchServices problems in Sonoma 14.0, I wrote a comment on the article, and today Howard wrote a follow-up article LaunchServices problems and Ventura. This article is a follow-up to Howard's follow-up. You should read Howard's articles before mine, otherwise mine might not make much sense, and I don't want to repeat everything here that's already been said.
macOS has a built-in command-line tool for manipulating the LaunchServices database:
/System/In my .zshrc file, I have an alias lsregister for that path. Enter the command with no arguments to see usage information. To unregister an app or apps from the LaunchServices database, use the following arguments, followed by the path of the app or apps:
The argument -R is "Recursive directory scan, descending into packages and invisible directories", -f is "force-update registration even if mod date is unchanged", -u is "unregister instead of register", and -v is "Display progress information" (in other words, verbose).
Unfortunately, the verbose option has been broken since Monterey. I filed feedback with Apple, FB9986535 "lsregister -v verbose option no longer works on Monterey", in April 2022.
I have a very specific workflow for unregistering apps with LaunchServices. Again, I have a .zshrc alias for this:
The reason for this workflow is an Xcode bug: FB10829413 "Organizer window registers Archives with LaunchServices", which I filed in July 2022. Whenever I open the Xcode Organizer window, which shows archives of my App Store apps, crash reports, and other information, every archived copy of my App Store apps gets registered with LaunchServices. As a result, the Open With contextual menu in Finder looks like this:
You can see multiple versions of my app Link Unshortener with its newer (pretty) and older (ugly) icons. To clean up the contextual menu, I have to run my archives command, and then it likes look this:
On Ventura, lsregister started to return an error "failed to scan" with the error code -10814. However, this error appears to be harmless, and that's what I wrote in my comment to Howard's original article.
In the follow-up article, Howard wrote:
And, in both Ventura and Sonoma, as Jeff reports, the command does what it should regardless of the error message. However, removal is transient, and depends on there being no copy of that app on any local volume. Unless you compress the app or otherwise render it inaccessible, even force restarting the Finder will restore it to the Open With menu.
As a side note, here's an ancient but still effective trick to add a Quit menu item to Finder:
defaults write com.apple.finder QuitMenuItem -bool YES(Logout and login for the change to take effect.)
Back to the gist of Howard's response, his experience with lsregister was not the same as my experience. For me, my old archived apps remain absent from the Open With contextual menu even after quitting Finder (until the next time I open the Xcode Organizer window, sigh). What accounts for this difference? The reason, it turns out, is that I excluded the Xcode Archives folder in Spotlight's Privacy System Settings. This means my old archived apps never appear in Spotlight searches, even when they do appear in the Open With contextual menu. In contrast, when Spotlight can find an app, it registers the app with LaunchServices. That's why unregistering with lsregister appears to be a futile endeavor for apps that are located in folders and volumes indexed by Spotlight.
Howard writes:
Maybe I haven’t been paying attention, but LaunchServices now searches all mounted local volumes, probably using Spotlight, to discover apps to include in its database.
At least as far as mounted boot volumes are concerned, this has been a longstanding problem with Spotlight. For the purpose of testing, I have a Mac mini with four different macOS versions installed on four separate APFS volumes. The same problem with multiple app versions appearing in the Open With contextual menu occurs in each of these four macOS versions, from Sonoma to Big Sur (and has occurred in the past with previous macOS versions).
Spotlight has never handled multiple boot volumes well, unfortunately. Apple likes to pretend that nobody ever uses this configuration. It doesn't even help to exclude volumes from Spotlight Privacy System Settings, because the exclusion seems to be stored by the excluded volume rather than by the excluding volume. The sad result is that if you exclude the Ventura volume from Spotlight while running Sonoma, the Ventura volume will also be excluded from Spotlight while running Ventura!
Way back in 2009, I filed FB5666683 (originally Radar 6939726) "Spotlight: no way to set separate Privacy prefs for multiple OS X partitions". That bug report was closed as a duplicate; I don't have any further tracking information. And in 2008, I filed FB5950134 (originally Radar 6338139) "Spotlight: preference to not index external drives". That was also closed as a duplicate.
Howard suggested in his original article that there has been a change of behavior on Sonoma:
After upgrading to Sonoma, one difference that you may notice is that the lists of apps capable of opening some types of document have expanded to include copies of apps not located in any of the conventional Applications folders. In my case, where I keep old versions of my own apps on an external SSD, every one of those now appears in the popup menu to Open With.
This may be true, though I haven't attempted to test it specifically. If there has been a change in Sonoma, it would involve a change in the list of folders indexed by Spotlight. My theory is that any addition of apps to the Open With contextual menu in Sonoma would coincide with the addition of those same apps to the Spotlight search results.