As its name suggests, LaunchServices is responsible for key features integrating the launch of apps and document types. Together with the more recent RunningBoard subsystem, it handles much of the work involved in launching apps, as I explored yesterday for Sequoia. This article looks in more detail at LaunchServices and what you can do to address problems, such as ensuring that only the apps you want are listed in the Finder’s Open With… contextual command.

RunningBoard is concerned with the control of resources such as memory, GPU access, CPU limits and the process lifecycle. Events are handled as assertions, and for apps that it manages those can result in reallocations and changes of state. Each running app has a lengthy and detailed job description created during launch but that doesn’t persist once an app has shut down.

In contrast, LaunchServices compiles a large registry database of apps and their associations with and capabilities for handling different document types. Its records determine which app opens a document when you double-click on its icon in the Finder, and most prominently which are listed when you open the Open With… item in the Finder’s contextual menu. Apps are registered there automatically, and their details are updated each time they’re run. Although the user can’t interact directly with LaunchServices, there is a command tool that offers control over it, lsregister, although it’s buried deep in the system frameworks, doesn’t have a man page, and now works differently.

lsregister

This command tool can be found at /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister, and typing that in with the -h option will show its usage information, as the closest you’ll come to documentation. If you’re going to use it much, you’ll want to create an alias for it, or add it to your PATH with
PATH=/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support:"$PATH"
to use the command as lsregister, as I’ll do here.

Useful lsregister commands follow one of two forms:
lsregister [options] [path]
to register or unregister an item (usually an app) specified by the path, and
lsregister [options] [-apps domainlist] [-libs domainlist] [-all domainlist]
to 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.

Registration

In the past, apps used to populate the LaunchServices registry were those located in the traditional Applications folders, but recent versions of macOS have extended that to cover almost any accessible folder. This has been explored by Jeff Johnson, who has shown that excluding folders and volumes from Spotlight indexing, by adding them to the list in Search Privacy… in Spotlight settings, will exclude those apps from LaunchServices’ list. Alternatively, you can hide the folder they’re in by adding a dot to the start of its name. However, that can still fail at times, for example if you open that excluded location in the Finder, resulting in those hidden apps being added back into that list.

You can try to remove an app from the LaunchServices registry using the command
lsregister -R -f -u pathname
where pathname is the path and name of the app. In Sequoia, that invariably returns an error that lsregister “failed to scan [path]: -10814 from spotlight,” where the path given is that to the app. That error code comes from LaunchServices, and its name reveals the cause: kLSApplicationNotFoundErr, even when the pathname given to lsregister is correct. Despite that error, if that app is hidden from Spotlight search, this should prove effective until something undoes it again.

This over-enthusiasm to register apps can be even more than a nuisance when running a lightweight macOS Virtual Machine on Apple silicon. If you make the host’s Applications folder a shared folder with the VM, then open that shared folder within the VM, all the apps within it are promptly added to the Open With… list in the guest, a behaviour likely to be unwanted.

Given the current state of LaunchServices discovery, you’re unlikely to want to add an app to the database, as it’s most probably already there, whether wanted or not.

Resetting the registry

In the past, one last-ditch method of addressing LaunchServices problems has been to reset its registry. You can perform that using either
lsregister -kill -r -v -apps u
to affect just the user domain, or
lsregister -kill -r -v -apps u,s,l
to widen its coverage to other domains.

Running either of those in recent versions of macOS including Sequoia is likely to wreak havoc, though. While this appears to be effective with the Open With… list, its effects on System Settings can be catastrophic. This can remove its entire contents, and even blow the wallpaper away. Normal function should start to return after restarting the Mac, but even then problems can persist.

Dumping the registry

Even on a minimal Mac, LaunchServices’ registry is very large. If you want to inspect its contents, use a command like
lsregister -dump > ~/Documents/lsregisterDump.text
to write its contents to the file lsregisterDump.text. Browsing that should keep you occupied for many hours or days.

Summary

• LaunchServices is responsible for making associations between apps and documents, and maintains a large registry of all apps and document types.
• Its registry is used to populate the list for the Open With… item in the Finder’s contextual menu.
• LaunchServices now tries to include all apps in accessible volumes and folders.
• You can control (to a limited degree) its registry using the hidden lsregister command tool.
• You can exclude apps only if their location is excluded from Spotlight search by adding it to Search Privacy… in Spotlight settings.
• LaunchServices in a VM will also try to include all apps in shared folders on the host.
• Resetting the registry using lsregistry -kill can wreak havoc with System Settings and should be avoided.
• Dump the registry to text using lsregister -dump if you enjoy a long read.

Each new version of macOS has increased the complexity of launching apps, from the basics of launchd, the addition of LaunchServices, to security checks on notarization and XProtect. This article steps through the major landmarks seen when launching a notarized app that has already passed its first-run checks and is known to macOS Sequoia 15.3, on an Apple silicon Mac.

Rather than trying to provide a blow-by-blow account of what’s written in the log over the course of thousands of entries, I’ve extracted landmarks that demonstrate when each subsystem gets involved and its salient actions. These have been gleaned from several similar app launches, and are ultimately timed and taken from one complete record of one of my simpler notarized apps that has no entitlements and uses only basic AppKit features. The app hadn’t been through quarantine as it had been built and notarized on the same Mac, and had been run previously but not in that session since the previous boot. It had thus been previously registered with LaunchServices and other subsystems. The host was a Mac mini M4 Pro, so timings should be briefer than on many other Macs, it was run from the main Applications folder on the internal SSD, and AI was enabled.

LaunchServices and RunningBoard

LaunchServices has been around for many years, and handles many of the tasks exposed in the Finder, including mapping of document types to app capabilities, Recent Items and Open Recent lists, making it the backbone of app launching. RunningBoard was introduced in Catalina and has steadily assumed responsibility for managing resources used by apps, including memory and access to the GPU. Although the test app doesn’t have any of its resources managed by RunningBoard, LaunchServices launched it through RunningBoard.

RunningBoard’s first task is to create a job description, which it helpfully writes to the log as a dictionary. This is a mine of useful information, and has replaced the copious information compiled by LaunchServices in the past. This includes:

• a dictionary of Mach services
• whether Pressured Exit is enabled
• a full listing of environment variables, such as TMPDIR, SHELL, PATH
• RunningBoard properties including another TMPDIR
• whether to materialise dataless files.

Once that job description has been constructed for the app, RunningBoard tracks the app and its assertions, providing a detailed running commentary through the rest of the app’s life. LaunchServices still performs its traditional tasks, including creating an LSApplication object and sending an oapp AppleEvent to mark the opening of the app, and launchd still reports that it’s uncorking exec source upfront.

When the app is running, its preferences are loaded from the user CFPrefsD, and its pasteboard is created. Almost 0.1 second later (0.3 seconds after the start of launch) there’s a sustained flurry of log entries concerning Biome, and signs of AI involvement (Apple silicon only). The latter include a check for the availability of generative models and WritingTools. There are also entries referring to the loading of synapse observers.

LaunchServices log entries are readily accessed through its subsystem com.apple.launchservices, and RunningBoard through com.apple.runningboard.

Security and privacy

The first serious engagement in security is the verification of the app’s signature and its evaluation by Apple Mobile File Integrity (AMFI, using amfid). Shortly after that comes the standard Gatekeeper (GK) assessment, with its XProtect scan, starting less than 0.1 second after the start of launch. Immediately after the start of that scan, XProtect should report which set of data files it’s using. In Sequoia those should be at /var/protected/xprotect/XProtect.bundle/Contents/Resources/XProtect.yara. That scan took just over 0.1 second.

While XProtect is busy, syspolicyd checks the app’s notarization ticket online, through a CloudKit connection with the CKTicketStore. That’s obvious from log entries recording the network connections involved, and the complete check takes around 0.05 second. Once that and the XProtect scan are complete, syspolicyd reports the GK scan is complete, and evaluates its result.

At about the same time that the Gatekeeper checks are completing, privacy management by TCC (Transparency Consent and Control, in tccd) is starting up. Its initialisation includes establishing the Attribution Chain for any Mach-O binaries run by the app, so that TCC knows where to look for any required entitlements. Following that, TCC writes bursts of entries as different components such as the Open and Save Panel service are set up for the app.

The final phases of security initialisation come in provenance tracking, which first appeared in macOS Ventura. This may be associated with presence of the extended attribute com.apple.provenance, but details are currently sketchy.

Following syspolicy in the log is best through its subsystem com.apple.syspolicy, you can watch XProtect using com.apple.xprotect, and TCC is com.apple.TCC.

Overall

Downloadable PDF: applaunch153

Main landmarks with elapsed time in seconds:

• 0.000 Finder sendAction
• 0.023 LaunchServices, launch through RunningBoard
• 0.029 RunningBoard launch request
• 0.043 AMFI evaluate
• 0.066 Gatekeeper assessment
• 0.080 XProtect scan
• 0.085 check notarization ticket
• 0.187 TCC checks
• 0.204 launched

Previous article

Launching apps in Sonoma 14.6.1: Conclusions