It has been many years since OS X just ‘ran’ apps the user launched. These days, each app is handed over to a list of managers, services that control its access to just about everything. This article explains some of the more important.

launchd

It wasn’t until Mac OS X 10.4 Tiger that Dave Zarzycki’s master launcher launchd was introduced. Ever since then, one of the early tasks of the kernel after it has been booted is to load launchd, which is then awarded the distinctive process ID of 1. As the master launcher, it’s responsible for launching everything else in macOS. It also serves as a replacement for the standard Unix schedular cron.

Although an essential part of the launch process, these days it’s also the simplest, and generates few entries in the log.

LaunchServices

For apps launched through the GUI, notably Finder and its accessories like the Dock, LaunchServices is the linchpin. Also known through its daemons, the quaintly named lsd and launchservicesd, and sometimes abbreviated to LS, LaunchServices is first to be told by the Finder when an app is to be launched, and reports this first. It maintains databases and lists of known apps, recent items, and recent files opened in each app. It’s also responsible for discovering additional items inside an app bundle, like plugins and extensions, and for handling them.

Look for its com.apple.launchservices subsystem in log entries, and its associated com.apple.appinstallation or MobileInstallation that handles the first run of new apps.

RunningBoard

A relative newcomer to Apple’s operating systems, RunningBoard first appeared in macOS 10.15 and iOS 13. Shown in the log as the subsystem com.apple.runningboard, it makes copious entries detailing how it acquires assertions, and considers how it should manage the major resources of each app, including

• memory,
• lifecycle, in terms of suspend and AppNap,
• GPU use,
• CPU limits.

Although these seem of momentous importance, at present there are few types of app whose lifecycle it actually manages. Unless it’s a Catalyst app, much of the time RunningBoard records those, as it doesn’t manage those resources for that app, it won’t actually do anything. The implication is that in the future RunningBoard will play a major part in managing access to those resources for more apps in macOS, as it does now in iOS.

TCC

Transparency, Consent and Control (TCC) is all about privacy and controlling access to locations such as the address book, removable storage, and computer resources like the camera and microphone. These form the bulk of the controls in Privacy & Security settings. Before an app can access any of those controlled resources, TCC has to approve that, for which it examines the app’s entitlements, and the controls in place on that resource. These are assessed through an attribution chain, allowing a command tool being run in Terminal the same access granted to other tools in Terminal, for instance.

Its copious log entries have the subsystem com.apple.TCC or the background process tccd.

Although we might like to think that TCC is recent, it first appeared in OS X 10.8 Mountain Lion, when it covered Contacts, Calendars and Reminders, social media including Twitter and Facebook, Accessibility, and Diagnostics and Usage. While location data have also been included, they’re not controlled by TCC but by Location Services and its daemon locationd.

TCC became far more complex in macOS 10.14 Mojave, when it gained extensive control over access to protected folders and hardware resources including the camera and microphone. With complexity has come unexpected behaviour, bugs, and vulnerabilities that have attracted the attention of security researchers. As a consequence it writes extensive entries in the log.

CFPrefsd

Often forgotten, but ignored at your peril, is the Core Foundation preferences daemon cfprefsd, also known as the Defaults Server, responsible for accessing and managing an app’s preferences property list. This isn’t mandatory, and apps are free to manage their own, but as part of Core Foundation, the great majority of apps use it. While its log entries may be few and far between, it has important consequences for apps, in keeping their preference settings in sync with the file in ~/Library/Preferences or its container equivalent, and preventing users from messing with them directly.

Others

There are many other more specialist managers and services used by apps, now including Biome (com.apple.Biome), and window management for Stage Manager and other purposes using the com.apple.windowmanagement subsystem, and com.apple.AppKit. There’s never a dull moment in the log.

If you encounter what seems to be new and you don’t recognise its name, look it up in Michael Roitzsch’s superb Apple Internals index.