Many apps can’t do their job without helpers. Some provide services that need to run in the background so that you don’t have to open the app manually whenever they need to run. Others need to perform privileged operations, which require a privileged helper. This article reviews briefly how those currently work, and how they’re changing in Ventura.
There are three different ways that helper apps are normally run: as Login Items, Launch Agents, and Launch Daemons. Although they overlap in how they work and what each does, Apple differentiates them as:
- Launch Daemons are standalone background processes managed by
launchd
, running as root before the user logs in, and communicating indirectly with user processes, normally by XPC. They’re not allowed to connect to WindowServer. - Launch Agents are also managed by
launchd
, but normally run on the user’s behalf, communicating with other processes and daemons. Although they can have GUI interfaces, they’re normally minimal. - Login Items are usually small apps started when the user logs in, which continue to run until they log out or quit them. These are often used to launch other helpers automatically, but may simply provide convenient access to app features, such as through a menu bar tool.
LaunchDaemons and LaunchAgents
Before you have logged in, launchd
runs services and other components which are specified in Property List files in the LaunchAgents and LaunchDaemons folders in /System/Library, and in /Library. Those in /System/Library are all part of macOS, owned by Apple, and locked away on the SSV, but those in /Library include many installed by third party products. As they’re run before the user logs in, those work for all users, so are global services.
Once you have logged in, launchd
runs any services and other components specified in any LaunchAgents folder in ~/Library. Those are user-specific.
These Property List files contain keyed settings which determine what launchd
does with what. Although they can contain many other key-value pairs, two most important ones are ProgramArguments (or Program), which tells launchd
what to run, and RunAtLoad, which determines whether launchd
should run the service or app whenever your Mac starts up and it loads those agents and services.
Other keys determine whether the agent/service should be kept running at all times; if that is set, if it crashes or is otherwise terminated, launchd
will automatically start it up again. That’s important for background services which apps rely on to function.
LoginItems
As the name makes clear, Login Items are run later, after the user logs in. You can set any app, service, or other executable code to run by adding it to the list of Login Items in the Users & Groups pane in System Preferences.
Once added, LaunchServices puts them into its list of apps to launch at startup, which is also kept in a Property List file. In Sierra and earlier, that’s located in ~/Library/Preferences/com.apple.loginitems.plist, but High Sierra has moved that, changed its extension and its file structure, to ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm The older Property List isn’t intended to be maintained directly by the user. For each Login Item, it gives an ‘alias’ which isn’t a normal macOS Bookmark, and some CustomItemProperties, which are also Base-64 encoded opaque data. The new format in High Sierra and later is even more opaque: although a Property List, it’s now a keyed archive containing objects which are referenced by UUID, and unsuitable for manual editing.
There’s an easy way to add apps which are already in the Dock to the Login Items list: click and hold on their icon in the Dock until its menu pops up. In that, select Options, then the Open at Login command.
You can add and remove Login Items using a scripting language; for example, in AppleScript
tell application "System Events" to make login item at end with properties {path:"/Applications/MyApp.app", hidden:false}
adds MyApp.app as a Login Item,
tell application "System Events" to get the name of every login item
lists all Login Items, and
tell application "System Events" to delete login item "name"
removes the named Login Item from the current list.
Login Items are better suited to apps of any size which have significant user interfaces, and anything which a user wants to control easily. Many apps, such as menu bar or ‘Status Bar’ apps, offer the user the option of installing them as a Login Item. Unfortunately, particularly when this is done for an app provided through the App Store, this turns out to be a complex development task which requires a helper app.
Changes in Ventura
Helpers and services are a difficult area for users. It has been all too easy for apps to install annoyances which the user then has difficulty removing. Some apps have pushed their luck in abusing these powers, and unwanted or malicious software has also used them to persist. Rather than apps installing their own helpers and property lists, macOS 13 introduces a new scheme in which those are provided within the app, in the bundle’s Resources and Library folders, rather than having to be installed by the app elsewhere.
Users are then properly informed about these helpers, and given control over them in a single unified panel in System Settings, for Login Items. This controls all apps and other items that run at startup or login, except those in macOS itself. As this could get fiddly, Ventura applies rules to simplify this:
- If an app includes one or more Launch Daemons, those must be authorised by the user first. If the user agrees, then all other helpers are approved, including any Launch Agents and Login Items.
- If an app doesn’t include a Launch Daemon, individual Launch Agents and Login Items are notified to the user as they’re added by macOS.
- The user then controls those helpers in System Settings.
- Apps are provided with easy access to check whether their helpers are currently authorised, so can act accordingly in the services they use.
As these are new features for Ventura, they will only be available to apps developed for macOS 13 and later, which will limit their usefulness at first until developers update their apps to use them.
References
Service Management in Apple’s developer documentation