Global LaunchAgent/LoginItem with SMAppService?

So what is the equivalent of the global launch agent using SMAppService?

There is not one )-:

I’d appreciate you filing an enhancement request for this. It’s something I’ve raised internally, but it helps to have a bug from a developer with a concrete use case.

Please post your bug number, just for the record.

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

Sounds good thanks The Eskimo!

FYI one of the use cases I can definitely think of is - some organizations may have SOE images with a user 501 like "soe_admin", who is responsible of pre-installing all software required. For our software, the installer can trivially register a login item or launch agent bound to the current user (501) using SMAppService via a postinstall script. However the actual device users will not be 501 so the login item or launch agent will not load properly for them unless they manually intervene (which we don't want because our software is largely silent/background).

Our software also has a launch daemon, which is loaded cross-user properly. I thought of using the daemon helper to ensure the login item/launch agent is registered properly across different gui sessions - but alas the daemon runs under the system domain, so it cannot read or write the user/gui domain (from SMAppService's header file I understand this is by design). So unless we have the proper support of global login item/launch agent I think we'll be forced to detour.

Feedback# is FB13137999, I've included the use case above in it as well.

Hi @eskimo a follow-up question here..

I fully understand that Apple doesn't want to divulge whether an enhancement request has been prioritized, or when it can be available. For now if our product decides that the capability of registering a global launch agent is important to us, that we'd like to keep doing the "launchctl" way, is that still accepted by Apple?

I did notice a line on this page that says "In apps that target macOS 13 and later, your app needs to only use the property list locations outlined above" and my own interpretation was that if our app's minimum deployment target was marked as 13.0, then we absolutely had to switch over to the SMAppService interface. Did I misinterpret that? On the other hand, can we lower our app's minimum deployment target to macOS 12.0 to circumvent that restriction?

For now if our product decides that the capability of registering a global launch agent is important to us, that we'd like to keep doing the launchctl way, is that still accepted by Apple?

I can’t really answer questions about what’s acceptable to Apple. Apple is a large corporate entitlement with many different aspects to it. When folks ask me questions like this they’re using referring to App Review. I don’t work for App Review, and can’t speak on their behalf, but I don’t think that matters here because App Review apps can’t install global launchd agents.

From a DTS perspective, installing a global launchd agent by laying down a file into /Library/LaunchAgents is still supported. Moreover, it’s the only way to achieve some goals.

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