When the Info window of Finder is used to associate files of a particular type with an application:

  • the preference is effective immediately.

When Terminal is used to make a comparable addition to ~/Library/Preferences/com.apple.LaunchServices.plist

  • the preference is not effective immediately.


Why does Launch Services not immediately respect a write to the user's com.apple.LaunchServices.plist?

An ideal answer might be a reference to a page in the Apple Developer area.

Answers need not involve running a command.


Agent or daemon?

Wondering whether a daemon or agent makes changes to that .plist effective, I ran:

sudo launchctl list

In the list, under the label heading, I see nothing that might relate to Launch Services.


An answer to Stack Overflow question How to set default application for specific file types in Mac OS X? suggests:

… to be reloaded. You can logout, wait a few minutes or force launchservices to restart …

In my case:

The accepted answer to Super User question Is there a faster way to change default apps associated with file types on OS X? suggests:

… restarting the OS to apply changes (logging out and back in isn't enough) …

— if a restart suffices, that's probably less time consuming than killing then seeding the Launch Services database.

  • 2
    lsregister -kill -seed doesn't take that long (a few seconds on my Air), but it makes OS X show the warnings about opening applications for the first time again. That's why restarting is generally a less annoying way to apply the changes.
    – Lri
    Apr 30, 2012 at 12:16

1 Answer 1


From Apple’s Launch Services Programming Guide (all emphasis mine):

All applications available on the user’s system must be registered to make them known to Launch Services and copy their document binding and other information into its database. It isn’t ordinarily necessary to perform this task explicitly, since a variety of utilities and services built into the Mac OS X system software take care of it automatically:

  • A built-in background tool, run whenever the system is booted or a new user logs in, automatically searches the Applications folders in the system, network, local, and user domains and registers any new applications it finds there. (This operation is analogous to “rebuilding the desktop” in earlier versions of Mac OS.)
  • The Finder automatically registers all applications as it becomes aware of them, such as when they are dragged onto the user’s disk or when the user navigates to a folder containing them.
  • When the user attempts to open a document for which no preferred application can be found in the Launch Services database, the Finder presents a dialog asking the user to select an application with which to open the document. It then registers that application before launching it.

In spite of these automatic registration utilities, it may sometimes be necessary to register an application explicitly with Launch Services. For example, although developers are encouraged to package their applications so that they can be installed by simply dragging them onto the user’s disk, some applications may require more elaborate custom installer software. In such cases, the installer should call one of the Launch Services registration functions LSRegisterFSRef or LSRegisterURL to register the application explicitly.

Note the API calls needed by the only named manual registration procedure (source not available on opensource.apple.com, I’m afraid).

While working around a bug in processing of Launch Services on Leopard with FileVault enabled, I noticed that ~/Library/Preferences/com.apple.LaunchServices.plist is:

  • processed only on login after boot, as input data to the buildup of the Launch Services database proper (FileVault-enabled Leopard often failed to do this step, resulting in seemingly lost user settings); and

  • cached as long as the machine is not rebooted.

Simply put, it’s the user domain persistence layer of Launch Services, and modifications to that persistence layer are only acknowledged on next processing – reboot or reseed.

  • 2
    @GrahamPerrin: BTW, if you ned a way to add entries to the Launch Services database without the hassle of writing to com.apple.LaunchServices.plist and rebooting, check out duti – it’s what I used to sidestep that exact same issue in GoodCompany.
    – kopischke
    May 16, 2012 at 18:22
  • Where duti is an accepted answer, there's a bulleted note that reboot/restart is required. Maybe requirements differ where FileVault 1 is not used? Just a guess. I'd like to discuss this in Ask Different Chat, at your leisure, address me and @bmike if you like. Thanks. (My comments relating to this are spread across multiple questions in multiple stacks – not necessarily a bad thing, but I'd love a single place for discussion.) May 17, 2012 at 6:45
  • 1
    @GrahamPerrin: I’ll try to be in chat whenever possible, but I can already report that a reboot was not needed to change the default handler for a txt extension using duti on my (Lion, non-FileVault) system.
    – kopischke
    May 17, 2012 at 22:48
  • 1
    @GrahamPerrin I meant that my own script (not duti) required restarting.
    – Lri
    May 18, 2012 at 5:27
  • 1
    @GrahamPerrin: duti is basically a CLI wrapper around the LSSetDefaultRoleHandlerForContentType and LSSetDefaultHandlerForURLScheme functions, which are both declared in Application.halong with the LSRegister* functions – meaning it interfaces with Launch Services at the API level Apple provides, not via the persistence layer (see the duti source, specifically handler.c).
    – kopischke
    May 18, 2012 at 8:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .