There was a time when the great majority of apps consisted of just an app bundle, created their own settings file in ~/Library/Preferences, and that was that. For various reasons, this became steadily more complicated, with some apps assembling arrays of files and folders in /Library/Application Support, and in recent years many apps have required helpers too. One common reason for this is that they need to perform certain functions with elevated privileges, such as root. To do that, they have become even more elaborate, with Login Items, property lists installed in folders like /Library/LaunchAgents, and more. This article explains how Ventura is trying to make things simpler again.
Before Ventura, a modern app using a Login Item and privileged helper might have several additions to its bundle, and the main /Library folder. For an example app named MyApp, these could include
- a Login Item, a lightweight app providing a menu bar dashboard, at MyApp.app/Contents/Library/LoginItems/AppDashboard.app
- a privileged helper in a Mach-O binary, provided at MyApp.app/Contents/Library/LaunchServices/com.developer.apphelper, then installed to /Library/PrivilegedHelperTools/com.developer.apphelper
- a property list for
launchdto run the helper, installed in /Library/LaunchDaemons/com.developer.apphelper.plist.
Originally, the privileged helper and its property list might have been installed using an Installer package for the whole app, but there are neater ways to do this now, which ‘bless’ it by Service Management, and the Login Item needs to be properly registered and enabled with Service Management too. The property list is usually embedded in the helper binary, so the whole installation process is normally handled by the app running in its own bundle.
When the app does this, it can be smarter than any installer, and check the Login Item and privileged helper are both correctly installed and available each time it opens. If any component is missing, it can then reinstall them, and that’s why deleting property lists for LaunchAgents and LaunchDaemons can’t solve problems with Background Items: the next time you run that app, it merely reinstalls them, and you’re back to square one.
Just like any installer, apps that install Login and Background Items should also support uninstalling them. Otherwise, if you were to remove that app, the helper and its property list would be left behind. Not all apps offer that, and many users aren’t aware of the need to uninstall before removing that app.
macOS Ventura introduces a new scheme for Login Items, helpers, and their property lists, that should solve those problems. Helpers and the property lists for LaunchAgents and LaunchDaemons are now kept within the app bundle:
- Login Items should remain in /Contents/Library/LoginItems
- executable code for helpers can be installed in various folders, but Apple suggests that /Contents/Resources might be most appropriate;
- LaunchAgent property lists go into /Contents/Library/LaunchAgents;
- LaunchDaemons property lists go into /Contents/Library/LaunchDaemons.
When placed there, Ventura will automatically make their association correctly, so no further installation or action is necessary. If those locations aren’t possible, then others can be associated with that app, although that becomes more complicated.
Because the user can now disable Login and Background Items in the Login Items settings, apps running Ventura can check the status of the Login and Background Items and warn the user of the effects of those settings on the app and its features. The app can also open the Login Items section in System Settings to help the user make any necessary changes.
LaunchDaemons and LaunchAgents need to be registered, which will normally be requested from the user. LaunchDaemons are system-level processes, so the user needs to authenticate to authorise them; however, that’s actually a benefit, as it results in the approval of other helpers, and fewer authorisations on the part of the user.
Better apps should still provide the user with the means to unregister these app components, for example when the user is going to remove that app. However, this new scheme should address this automatically, as simply removing the app should call Service Management to clean up when it next performs its routine housekeeping, normally the following night.
This new scheme has a significant security advantage as property lists for
launchd are all retained in the app bundle, where they are protected by its code signature. Because of that, third parties can’t modify them, although that may not be to the liking of some advanced users, who also can’t tinker with them.
This new scheme only operates in Ventura. Apps which only run in Ventura and later can use it already, but existing apps and all that need to be compatible with previous versions of macOS need to offer the traditional system for compatibility. Some may support both schemes, but that makes an already complex issue even more challenging to get right. So for the time being, I’d only expect apps that can’t run in Monterey or earlier to use the new scheme.
The requirement to support both old and new schemes may be responsible for the problems that some are experiencing in managing Background Items in Ventura.
While Ventura has to support both old and new schemes, I expect that Apple will drop support for the old scheme as soon as it thinks that’s feasible. I think one of the ultimate intentions is for macOS to lock down LaunchAgents and LaunchDaemons folders in the main library, a big step forward in preventing malicious software from becoming persistent. We have yet to see how Apple will allow advanced users to install their own property lists for
- Prior to Ventura, apps installed helpers and their property lists in folders in /Library.
- New to Ventura is a scheme in which those are kept within the main app bundle.
- Ventura thus has to cope with both schemes, which may account for some of the problems experienced with Background Items.
- Apple may intend to further limit access to /Library/LaunchAgents and LaunchDaemons folders in future macOS to help prevent malware persistence.
Apple’s traditional approach (2016)
Ventura’s new Service Management scheme.