macOS 13 introduced a new mechanism for users to control background items on their Mac. These items now show up in a list under System Settings > General > Login Items > Allow in the Background. The name in that list should be the name of the app responsible for the background item. If it’s not, there are two possible reasons:
-
Your product is built incorrectly.
-
There’s a bug in macOS.
It’s important to distinguish between those two cases, and the best way to do that is to test your product on a fresh machine:
-
Set up a new machine that’s never seen your product before. I generally use a VM for this, restoring from a snapshot between each test.
-
Install your app as the user would.
-
Check what you see in System Settings.
If you see the right name, it’s likely that your product is built correctly. If that same product shows the wrong name in other environments, it’s reasonable to assume that this is a bug in macOS.
Note Such bugs are very common on development machines. The code that gets the name of your product relies on the Launch Services database, and it’s not uncommon for the building and rebuilding you do on your development machine to thoroughly scramble that database. That’s why testing on a fresh machine is so important.
OTOH, if this test shows the wrong value you need to start looking at your code. There are three common cases here:
-
Your product is an app that calls
SMAppServiceto install its background items. -
Your product includes an app but installs its background items by writing
launchdproperty list file to/Library/LaunchDaemons,/Library/LaunchAgents, or~/Library/LaunchAgents. -
Your product does not include an app.
If you use SMAppService and the wrong name shows up, that’s strong evidence that you’re dealing with a bug in macOS. SMAppService should provide the system the information it needs to understand that your app is responsible for your service.
If you work with launchd property list files directly, make sure to add an AssociatedBundleIdentifiers property that lists your app’s bundle ID. Again, that lets the system know that your app is responsible for these launchd jobs.
If your product doesn’t include an app then there’s a limit to how well the system can do here. You might want to consider creating and installing some sort of management app, one that exists solely to become the responsible code for your launchd jobs.
If you’ve concluded that your product is built correctly and you’re able to consistently reproduce the problem on a fresh machine, that’s definitely worth filing a bug about it. Such a bug should be actionable.
Even if you can’t reproduce the problem, you might still want to file a bug about it, with the understanding that it’s significantly harder to fix such bugs.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
