When you double-click on a document to open it, your Mac relies on a chain of information to work out which app to launch to open that document. If something goes wrong anywhere in that chain, you’ll end up with the wrong app trying to do the job. This article explains how to ensure the right app opens every time.

Steps in the chain are:

1. LaunchServices checks whether there’s a custom setting for that document; if there is, then it opens the app specified in the document’s com.apple.LaunchServices.OpenWith extended attribute.
2. If no custom setting is in force, LaunchServices checks the UTI (Uniform Type Identifier) of the document.
3. LaunchServices checks its database to determine the default app and its location, set for that type of document.
4. LaunchServices launches the default app and sends it an AppleEvent to open the document.

Custom setting

This is controlled in the Finder’s Get Info dialog. When a document is set to be opened by an app other than the default for its UTI, a com.apple.LaunchServices.OpenWith extended attribute is added, containing a property list specifying:

• bundleidentifier, e.g. co.eclecticlight.DelightEd
• path, e.g. /Applications/DelightEd.app
• version, e.g. 0 to allow any version.

If you use the Get Info dialog to set that back to the default app, that extended attribute may be retained, but then will contain details of the default app instead. You can also manually reset it by deleting the extended attribute, so that its behaviour reverts to the default.

Document UTI

In the great majority of cases, this is determined by the filename extension of the document. Change it from rtf to pdf and you’ll see the importance of using the correct extension. Reference material on UTIs is available in my free app UTIutility.

LaunchServices database

When an app is first run from the Finder and GUI, information about it is extracted from its Info.plist file and added to LaunchServices’ database. This includes custom document types specified by the app and its abilities to open and edit different types of document. These are then used to match document UTIs against the apps that can open them. Unless you’ve set any different, LaunchServices should normally open the most recent version of the specified app in your Applications folder, which usually coincides with that in the Dock if it’s installed there.

When the wrong app is opened, it’s simple to fix. Select the document, Get Info, and change the Open with: setting to the app that you want. If you want this to apply to all docs of that UTI, then click on the Change All… button.

When LaunchServices keeps opening the wrong version or copy of the right app, rather than the one that’s installed in your Dock and your Applications folder, it’s a bit more complicated to fix. It usually helps to discover which copy of the app LaunchServices is opening. Double-click on one of its documents, and Control-click on the app’s icon in the Dock. Towards the bottom of the menu, you’ll see the item Options, in which you can Show in Finder.

This opens a Finder window on the copy of the app which LaunchServices currently uses to open documents with this UTI. That may come as a surprise, as the copy it’s opening may be one you didn’t know about. Rather than removing those unwanted copies of an app until finally LaunchServices opens the right one, there’s a better way to fix that.

Before going any further, check that the version installed in your main Applications folder (or wherever it should be) is the one that you want LaunchServices to open, and, if it’s installed there, the app in the Dock is one and the same. Then return to the Finder’s Get Info dialog, and open the list of apps which could open that document in the Open with: item.

If there are multiple versions of the same app, go to the foot of that menu, and select Other… to bring up an Open File dialog, where you select the copy of the app which you want to open those documents with.

Click on Open and verify that this is the right copy, via the Dock.

Now that is set, click on the Change All… button in the Get Info dialog’s Open with: section. Now you should find LaunchServices opening double-clicked documents using the right app, the right version, and the right copy at last.

Advanced commands

There are two command tools that can be valuable for tackling harder problems: lsappinfo for getting information from LaunchServices’ database, and lsregister for changing it.

lsappinfo is documented in its man page, which is extensive and fairly accurate, and by usage info in response to the command
lsappinfo -h

The starting point for exploring this command is
lsappinfo list
which is probably best piped into a text file for easy browsing. This lists all running apps and processes known to LaunchServices, and gives a brief summary of what it knows about them. If you want full details on everything running, then pipe
lsappinfo -all list
to a text file, as that tells you pretty well everything LaunchServices knows about apps and processes.

When you’ve got over having so much information in front of you, this tool is most useful for giving information about just one running app or process. To do that, use
lsappinfo -all info "TextEdit"
to show all the information about TextEdit. You can specify the app using its ASN if you prefer, such as in
lsappinfo info ASN:0x0-0x34034:
or give its bundle ID:
lsappinfo info "com.adobe.AdobeResourceSynchronizer"

In addition to getting information, there are four other valuable verbs:

• listen, which reports LaunchServices events such as apps being started or brought to the front;
• launch, which launches an app or process specified by path;
• restart, which will restart the launchservicesd service at the heart of LaunchServices, and requires elevated privileges using sudo;
• log, which sets LaunchServices to write more or less entries in the unified log.

lsregister is buried away in the path /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister Assuming that you’ve aliased it to somewhere readily accessible, the only way to discover its functions is from its usage info
lsregister -h

Useful lsregister commands follow one of two forms:
lsregister [options] [path]
which register and unregister the item (app, usually) specified by the path, and
lsregister [options] [-apps domainlist] [-libs domainlist] [-all domainlist]
which act on the LaunchServices database for the given types (apps, libs, all) and domains. Domains are usually specified as a list of letters:
u,s,l,n
is the complete set, covering user (your Home folder), system, local and network.

In recent versions of macOS, a new option -gc has been added to get LaunchServices to rescan different domains for app info and garbage collect its database. For example,
lsregister -gc -R -v -apps u
checks relevant folders in your Home folder, including ~/Applications, for apps which it needs to add to its database. You can widen this to a full scan of apps using
lsregister -gc -R -v -apps u,s,l

Reset the LaunchServices database using a utility such as OnyX, or
lsregister -kill -r -v -apps u
to affect just the user domain. For more extensive rebuilds, widen its domains, for example with
lsregister -kill -r -v -apps u,s,l
or
lsregister -kill -r -v -all u,s,l
using -seed to scan default locations to seed the new database if you wish.

You shouldn’t ever have to do this, but you should be able to register an app with a command such as
lsregister -R -f pathname
where pathname is the path and name of the app.

To remove an existing database entry for an app, such as a version that you don’t want to launch, try
lsregister -R -f -u pathname
where pathname is the path and name of the app.