Thanks for the suggestion. Considering that my application is using launch ctl to manage the agents originally, how would we reconcile that with migrating to the new format with SMAppService? I'm trying to understand the safe way to migrate users on "Build N" away from the install scripts managing the agents on customer installed builds to the UI managing them on "Build N+1" on onwards. Or at least getting my application in a resettable state so that only SMAppService needs to manage the Agents.

Thanks for the quick reply. If I stick with the traditional installation path, how would you suggest managing from the sandboxed app? Some kind of privileged helper? The simpler solution the better. For the other approach, I'll try registering the launch agents strictly from the UI, make sure they are booted out and the UI controls registering, unregistering. Should I "Code Sign on Copy" the plist files that represent the launch agent configuration?

It is still not clear for me as well, I'm not sure the behavior of processes managed by launchd (Agents) are not returning the ssid information. I'm seeing console logs like:{"msg":"#registration Found client identity match! Associating...", "registrationClientUUID":"3581B42E-9B35-4BE0-9AE8-41D878651996", "daemonClientUUID":"3581B42E-9B35-4BE0-9AE8-41D878651996", "prevDaemonClientName":"com.amazon.persist"}

thanks for the response, @eskimo . The agent is associated with a standard GUI app, they share the same keychain group, for example. So the steps would be to enable resource access by adding com.apple.security.personal-information.location to the entitlements file associated with the application, then following the CLLocation mechanism so that the prompt is accepted before accessing the resource?

The application is started by launchd, it is a LaunchAgent.