Registering login item with new SMAppService API

I'm trying to use -[SMAppService loginItemServiceWithIdentifier:] API, and after creating the SMAppServiceInstance, its status is SMAppServiceStatusNotFound. That means it didn't find the helper app?

The documentation is a little mixed up. It says that the parameter is "The bundle identifier of the helper application", but also says "The property list name must correspond to a property list in the calling app’s Contents/Library/LoginItems directory". So which is it, a property list name or a bundle identifier? And it the thing in the LoginItems directory a helper application or a property list?

What I have is an app bundle inside the Contents/Library/LoginItems of the app that's calling the SMAppService API. Or in other words, the given bundle identifier parameter is the CFBundleIdentifier value in Caller.app/Contents/Library/LoginItems/Helper.app/Contents/Info.plist. Is that not the right way to do it?

Answered by DTS Engineer in 736080022

That means it didn't find the helper app?

No.

Well, not necessarily (-: You can see a differencen if you supply a completely bogus bundle ID. For example:

let service = SMAppService.loginItem(identifier: "com.example.apple-samplecode.LoginItem")
print(service.status.rawValue)
let serviceBogus = SMAppService.loginItem(identifier: "com.example.apple-samplecode.LoginItemBogus")
print(serviceBogus.status.rawValue)

prints this:

3
2022-11-14 09:03:30.562065+0000 LoginItemContainer[64163:5161882] [all] Unable to find service status (LoginItemService(com.example.apple-samplecode.LoginItemxxx)) error: 22
3

The status value is the same in both cases (3 corresponds to .notFound) but in the bogus case you also get a grumpy log message.

From what I can tell, the .notFound status means that the system has never seen your service, and thus can’t give you any info about it. If you register and then unregister the service, the status goes to the more expected .notRegistered.


The documentation is a little mixed up.

Yes. In this case the doc comments in the header are correct:

/*!
 * @method loginItemServiceWithIdentifier
 *
 * @abstract
 * Initializes a SMAppService for a LoginItem corresponding to the bundle with the specified identifier.
 *
 * @param identifier
 * The bundle identifier of the helper application
 *
 * @discussion
 * The identifier must correspond to the bundle identifier for a LoginItem that lives in the calling app's
 * Contents/Library/LoginItems directory
 */

It looks like something has gone wrong with getting that info into the standard docs. I’d appreciate you filing a bug about that. Please post your bug number, just for the record.

So which is it, a property list name or a bundle identifier?

For a login item service, it’s the login item’s bundle ID. For launchd agent and launchd daemon services, it’s the name of a property list in Contents/Library/LaunchAgents or Contents/Library/LaunchDaemons, respectively.

And it the thing in the LoginItems directory a helper application or a property list?

For a login item service, it’s the login item app itself. For launchd agent and launchd daemon services, it’s a property list.

I think you can infer the origin of the doc bug (-:

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Accepted Answer

That means it didn't find the helper app?

No.

Well, not necessarily (-: You can see a differencen if you supply a completely bogus bundle ID. For example:

let service = SMAppService.loginItem(identifier: "com.example.apple-samplecode.LoginItem")
print(service.status.rawValue)
let serviceBogus = SMAppService.loginItem(identifier: "com.example.apple-samplecode.LoginItemBogus")
print(serviceBogus.status.rawValue)

prints this:

3
2022-11-14 09:03:30.562065+0000 LoginItemContainer[64163:5161882] [all] Unable to find service status (LoginItemService(com.example.apple-samplecode.LoginItemxxx)) error: 22
3

The status value is the same in both cases (3 corresponds to .notFound) but in the bogus case you also get a grumpy log message.

From what I can tell, the .notFound status means that the system has never seen your service, and thus can’t give you any info about it. If you register and then unregister the service, the status goes to the more expected .notRegistered.


The documentation is a little mixed up.

Yes. In this case the doc comments in the header are correct:

/*!
 * @method loginItemServiceWithIdentifier
 *
 * @abstract
 * Initializes a SMAppService for a LoginItem corresponding to the bundle with the specified identifier.
 *
 * @param identifier
 * The bundle identifier of the helper application
 *
 * @discussion
 * The identifier must correspond to the bundle identifier for a LoginItem that lives in the calling app's
 * Contents/Library/LoginItems directory
 */

It looks like something has gone wrong with getting that info into the standard docs. I’d appreciate you filing a bug about that. Please post your bug number, just for the record.

So which is it, a property list name or a bundle identifier?

For a login item service, it’s the login item’s bundle ID. For launchd agent and launchd daemon services, it’s the name of a property list in Contents/Library/LaunchAgents or Contents/Library/LaunchDaemons, respectively.

And it the thing in the LoginItems directory a helper application or a property list?

For a login item service, it’s the login item app itself. For launchd agent and launchd daemon services, it’s a property list.

I think you can infer the origin of the doc bug (-:

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks! I filed a documentation bug, FB11786569.

I have the same trouble. Sometimes I get SMAppServiceStatusNotFound status. I noticed that my macOS app is not in the System Preferences/Login Items/Allow Background apps list. So I did run a terminal command

sudo sfltool resetbtm

I rebooted, and my app was in that list. I had to turn back off all the apps in the Allow Background list, which turned on since the Terminal command.

You would agree with me, this is not the way to distribute the app to the customers. I can't ask my customers to run the Terminal command, reboot then turn off all the unwanted apps from the "Allow Background" list.

I guess I miss something. Any idea? How to get my app in that list just after I copied the app within the /Applications folder?

Registering login item with new SMAppService API
 
 
Q