Privileged daemon using SMAppService in macOS Sequoia

15.0 Beta (24A5264n), the app doesn't show up in the Login Item list.

But does your daemon actually run?

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

I didn't think to check, but yes, it's running. What's the methodology for applying privilege to a daemon in Sequoia? Would we need to conditionally open the Login Items pane depending on the OS version?

Hmmm, something weird is going on here. Here’s what I just did:

1. I built a test app that installs a daemon using SMAppService.

2. I copied it to the Applications folder on a ‘clean’ VM, one that’s never seen my app before. This is running macOS 15.0b1.

3. I ran the app and registered the daemon. The system displayed the ‘run in the background’ notification.

4. I opened System Settings > General > Login Items & Extensions.

5. In the Allow in the Background list, I see my app with the switched turned off.

This seems correct to me, and matches what I’d expect from macOS 14.

It sounds like you’re seeing very different behaviour. Before I send you off to file a bug, I wanna check whether your test is (roughly) equivalent to my test. Specifically, my concern is step 2. Did you start on a clean machine? Or is this a machine you upgraded?

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

It was upgraded. Other than reformatting the drive, is there a way to 'reset' the system for a given background item? I would think that an upgraded machine should still show the app in the list.

I would think that an upgraded machine should still show the app in the list.

Oh, absolutely. My question was just about focusing the discussion.

is there a way to 'reset' the system for a given background item?

I don’t know of any guaranteed way to do that — that’s why I do all this sort of testing in a VM, where I can restore from a snapshot — but sfltool has an resetbtm that might be useful.

Before you try to fix this, please take a ‘before’ sysdiagnose log to include in any potential bug reports.

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

Shoot... I realized that the existing processes were from a previous build that utilized SMJobBless. After unloading, the app does add the service to loginItems, but now there's a note that the process isn't signed, and the app doesn't connect to the helper. Guessing I should start a new thread?

now there's a note that the process isn't signed, and the app doesn't connect to the helper. Guessing I should start a new thread?

Probably best. Make sure to set the topic, subtopic, and tags to match this thread; that way I’ll definitely see it go by.

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

We hit the same issue with machines upgraded from macOS 14. FB13886433 was filed with a modified sample project taken from https://developer.apple.com/documentation/servicemanagement/updating-your-app-package-installer-to-use-the-new-service-management-api