I am trying to get a followup on the following thread. It seems like it is not possible to prevent non-admin users from unloading launch agents through the terminal or deleting the user level ones.

To gain exclusive access to keyboard HID devices like Amazon Fire Bluetooth remote controls, my app has been installing a privileged helper tool with SMJobBless in the past. The app - which also has Accessibility permissions - then invoked and communicated with that helper tool through XPC. Now I'm looking into replacing that with a daemon installed through the newer SMAppService APIs, but running into a permission problem: If I try to exclusively open a keyboard HID device from the SMAppService-registered XPC service/daemon (which runs as root as seen in Activity Monitor), IOHIDDeviceOpen returns kIOReturnNotPermitted. I've spent many hours now trying to get it to work, but so far didn't find a solution. Could it be that XPC services registered as a daemon through SMAppService do not inherit the TCC permissions from the invoking process (here: Accessibility permissions) - and the exclusive IOHIDDeviceOpen therefore fails?

Hi, We have a macOS application that contains a helper daemon that was registered with launchd using the SMAppService API and for the most part its been working okay until we tried to release an update that added an XPC service to the daemon. When users try to upgrade the software, the new service now fails to launch due to a launch constraint violation. The Console log shows the following error after the upgrade: AMFI: Launch Constraint Violation (enforcing), error info: c[5]p[1]m[1]e[0], (Constraint not matched) launching proc[vc: 6 pid: 1422]: /Applications/Mozilla VPN.app/Contents/Library/LaunchServices/org.mozilla.macos.FirefoxVPN.daemon, launch type 0, failure proc [vc: 6 pid: 1422]: /Applications/Mozilla VPN.app/Contents/Library/LaunchServices/org.mozilla.macos.FirefoxVPN.daemon The service plist before the upgrade looked like this: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>AssociatedBundleIdentifiers</key> <string>org.mozilla.macos.FirefoxVPN</string> <key>Label</key> <string>org.mozilla.macos.FirefoxVPN.service</string> <key>BundleProgram</key> <string>Contents/MacOS/Mozilla VPN</string> <key>ProgramArguments</key> <array> <string>Mozilla VPN</string> <string>macosdaemon</string> </array> <key>UserName</key> <string>root</string> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <true/> <key>SoftResourceLimits</key> <dict> <key>NumberOfFiles</key> <integer>1024</integer> </dict> <key>StandardErrorPath</key> <string>/var/log/mozillavpn/stderr.log</string> </dict> </plist> The updated plist changes the BundleProgram, removes ProgramArguments and adds MachServices, which results in the following plist: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>AssociatedBundleIdentifiers</key> <string>org.mozilla.macos.FirefoxVPN</string> <key>Label</key> <string>org.mozilla.macos.FirefoxVPN.service</string> <key>BundleProgram</key> <string>Contents/Library/LaunchServices/org.mozilla.macos.FirefoxVPN.daemon</string> <key>MachServices</key> <dict> <key>org.mozilla.macos.FirefoxVPN.service</key> <true/> </dict> <key>UserName</key> <string>root</string> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <true/> <key>SoftResourceLimits</key> <dict> <key>NumberOfFiles</key> <integer>1024</integer> </dict> <key>StandardErrorPath</key> <string>/var/log/mozillavpn/stderr.log</string> </dict> </plist> On a fresh machine/VM, this works just fine, we only encounter the Launch Constraint Violation when upgrading from one version to the next. We were hoping that the service could have been upgraded by calling unregisterWithCompletionHandler first, but this seems have no effect on the bug. So, I guess my questions are: Is there a way to diagnose what the launch constraints are for a service, and which why the constraints are being violated? How does one go about changing the plist for a daemon installed via SMAppService? Thanks, Naomi

Hello, I am currently researching to develop an application where I want to apply the MacOS updates without the password prompt shown to the users. I did some research on this and understand that an MDM solution can apply these patches without user intervention. Are there any other ways we can achieve this? Any leads are much appreciated.

Hi, I'm working on an application on MacOS. It contains a port-forward feature on TCP protocol. This application has no UI, but a local HTTP server where user can access to configure this application. I found that my application always exit for unknown purpose after running in backgruond for minutes. I think this is about MacOS's background process controlling. Source codes and PKG installers are here: https://github.com/burningtnt/Terracotta/actions/runs/16494390417

I've discovered that a system network extension can communicate with a LaunchDaemon (loaded using SMAppService) over XPC, provided that the XPC service name begins with the team ID. If I move the launchd daemon plist to Contents/Library/LaunchAgents and swap the SMAppService.daemon calls to SMAppService.agent calls, and remove the .privileged option to NSXPCConnection, the system extension receives "Couldn't communicate with a helper application" as an error when trying to reach the LaunchAgent advertised service. Is this limitation by design? I imagine it is, but wanted to check before I spent any more time on it.

SMAppService Error 108 "Unable to read plist" on macOS 15 Sequoia - Comprehensive Test Case Summary We have a fully notarized SMAppService implementation that consistently fails with Error 108 "Unable to read plist" on macOS 15 Sequoia, despite meeting all documented requirements. After systematic testing including AI-assisted analysis, we've eliminated all common causes and created a comprehensive test case. Error: SMAppServiceErrorDomain Code=108 "Unable to read plist: com.keypath.helperpoc.helper" 📋 Complete Repository: https://github.com/malpern/privileged_helper_help What We've Systematically Verified ✅ Perfect bundle structure: Helper at Contents/MacOS/, plist at Contents/Library/LaunchDaemons/ Correct SMAuthorizedClients: Embedded in helper binary via CREATE_INFOPLIST_SECTION_IN_BINARY=YES Aligned identifiers: Main app, helper, and plist all use consistent naming Production signing: Developer ID certificates with full Apple notarization and stapling BundleProgram paths: Tested both Contents/MacOS/helperpoc-helper and simplified helperpoc-helper Entitlements: Tested with and without com.apple.developer.service-management.managed-by-main-app What Makes This Different Systematic methodology: Not a "help me debug" post - we've done comprehensive testing Expert validation: AI analysis helped eliminate logical hypotheses Reproduction case: Minimal project that demonstrates the issue consistently Complete documentation: All testing steps, configurations, and results documented Use Case Context We're building a keyboard remapper that integrates with https://github.com/jtroo/kanata and needs privileged daemon registration for system-wide keyboard event interception. Key Questions Does anyone have a working SMAppService implementation on macOS 15 Sequoia? Are there undocumented macOS 15 requirements we're missing? Is Error 108 a known issue with specific workarounds? Our hypothesis: This appears to be a macOS 15 system-level issue rather than configuration error, since our implementation meets all documented Apple requirements but fails consistently. Has anyone encountered similar SMAppService issues on macOS 15, or can confirm a working implementation?

My app uses SMAppService to register a privileged helper, the helper registers without errors, and can be seen in System Settings. I can get a connection to the service and a remote object proxy, but the helper process cannot be found in Activity Monitor and the calls to the proxy functions seem to always fail without showing any specific errors. What could be causing this situation?

My app is for personal use currently, so distribution won't be a problem. It registers a privileged helper using SMAppService, and I was wondering whether there is a way to customize the authorization dialog that the system presents to the user.

I am developing the application in Mac. My requirement is to start the application automatically when user login. I have tried adding the plist file in launch agents, But it doesn't achieve my requirement. Please find the code added in the launch agents &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt; &lt;plist version="1.0"&gt; &lt;dict&gt; &lt;key&gt;Label&lt;/key&gt; &lt;string&gt;com.sftk.secure&lt;/string&gt; &lt;key&gt;ProgramArguments&lt;/key&gt; &lt;array&gt; &lt;string&gt;/Applications/Testing.app/Contents/MacOS/Testing&lt;/string&gt; &lt;/array&gt; &lt;key&gt;RunAtLoad&lt;/key&gt; &lt;true/&gt; &lt;key&gt;KeepAlive&lt;/key&gt; &lt;false/&gt; &lt;/dict&gt; &lt;/plist&gt; I have tried by adding manually in the setting, but it was opened sometimes and closed suddenly. On open manually it works. Please provide a solution to start the application automatically on system starts

Hello, I want to create a Launch Agent that triggers an executable upon changes in the /Applications folder. The launch agent is normally a loaded but not running, and by adding /Applications to the WatchPath parameters in the plist, launchd is supposed to trigger the process, that will run and exit once done. Sadly this seems not to be working uniformly. The script only works on one machine, in the the others the execcutable is never run. There seem not to be any meaningful differences in the launchd or system logs. The same identical plist works perfectly when changing something in the user's ~/Applications folder. The script does its job and logs are visible. Is there an undocumented limitation specifically for the /Applications folder that prevents luanchd to observe it in the WatchPaths? Maybe SIP not allowing access? But why does it work on my machine? Here is an example of the ~/Library/LaunchAgents/com.company.AppName.LaunchAgent.plist: &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt; &lt;plist version="1.0"&gt; &lt;dict&gt; &lt;key&gt;AssociatedBundleIdentifiers&lt;/key&gt; &lt;string&gt;com.company.AppName&lt;/string&gt; &lt;key&gt;KeepAlive&lt;/key&gt; &lt;false/&gt; &lt;key&gt;Label&lt;/key&gt; &lt;string&gt;com.company.AppName.LaunchAgent&lt;/string&gt; &lt;key&gt;ProgramArguments&lt;/key&gt; &lt;array&gt; &lt;string&gt;/Users/username/Library/Application Support/com.company.AppName/Launch Agent.app/Contents/MacOS/LaunchAgent&lt;/string&gt; &lt;/array&gt; &lt;key&gt;RunAtLoad&lt;/key&gt; &lt;false/&gt; &lt;key&gt;WatchPaths&lt;/key&gt; &lt;array&gt; &lt;string&gt;/Users/username/Applications&lt;/string&gt; &lt;string&gt;/Applications&lt;/string&gt; &lt;string&gt;/Network/Applications&lt;/string&gt; &lt;/array&gt; &lt;/dict&gt; &lt;/plist&gt; With the executable being a standard app bundle in /Users/username/Library/Application Support/com.company.AppName/Launch Agent.app Thank you

I have created an OpenDirectory module based on the template and docs here: https://developer.apple.com/library/archive/releasenotes/NetworkingInternetWeb/RN_OpenDirectory/chapters/chapter-1.xhtml.html After I copy my module in place and I set my module's configuration (see Configuration APIs section), my module does not get loaded. Currently the way I am able to start/reload it is sending a TERM signal to "opendirectoryd". (Launchctl refuses to stop it.) Then launchd restarts it, and my module gets started fine. Problem is that on some macOS this leads to system inresponsiveness for long time (even minutes). I have tried HUP signal, odutil reset cache etc, they do not help, my module does not get recognized. Is there a recommended way how to notify opendirectoryd about a new module? Repro: My example module can be found here: https://www.dropbox.com/scl/fi/qb8pa100yy56n5hangad0/MyODModule-250527-131702.tar.gz?rlkey=m96vb1rrxc6hml878jn64ybc8&st=h22tl4cy&dl=0 To reproduce the behaviour, uncomment line 12 in register_odmodule.sh: "/usr/bin/killall opendirectoryd", and compile and install the module with "make && sudo make install". And observe that it does not get loaded. Then "killall opendirectoryd", and observe that it got loaded. (To test for loaded or not, you can read on the node it creates with dscl: "dscl /MyExample -list /", or just see that it is not started as a process with "ps"). Thanks for any help in advance!

I have an app which contains a bundled launch agent that I register using SMAppService.agent(plistName:). I’ve packaged the launch agent executable in the typical Mac app bundle structure so I can embed a framework in it. So, the launch agent lives in Contents/SharedSupport/MyLaunchAgent.app/Contents/MacOS/MyLaunchAgent. However, I suspect this approach might be falling afoul of the scheduler, since the taskinfo tool reports my launch agent has a requested & effective role of TASK_DEFAULT_APPLICATION (PRIO_DARWIN_ROLE_UI), rather than the TASK_UNSPECIFIED (PRIO_DARWIN_ROLE_DEFAULT) value I see with system daemons. I tried setting the LSUIElement Info.plist key of my launch agent to YES, but this seems to have had no effect. What’s the recommended approach here?

I've searched around the internet and could not find a clear answer. I have a swift command line tool that needs to run automatically when the Mac mini M4 is started up without a user login and continue running forever. However, the command line tool and the data it uses are located on an external disk due to the size of the data. The service specified by a launchd plist located in /Library/LaunchDaemons tries to start up but fails because it cannot immediately find the command line tool. Which is because the external disk is not mounted when launchd tries to start the service when the Mac is booting. The service runs fine when bootstrapped after the disk is mounted. The first error is "No such file or directory, error 0x6f - Invalid or missing Program/ProgramArguments" and the service is put in the "penalty box". Is there any way for the service to get out of the "penalty box"? What is the best approach to make the launchd service wait for a specific external disk to mount? Some options for waiting seem to be: Use "WatchPaths" in the launchd plist, but the man page says this is unreliable. This makes one wonder what is the purpose of this option? Use "StartOnMount in the launchd plist", but this will run the command line tool every time any disk is mounted. This is not desired. Of course, I could move the command line tool to the startup disk, but then the tool would fail because the data is not available. This could be remedied by modifying the command line tool to wait for the external disk, but it would be polling, which seems inefficient. I could also add a delay, but that seems error prone because there is no assurance that the delay is long enough. When looking at the system plists, there seem to be a lot of options that are not directly mentioned in the man page for launchd.plist and have little to no documentation that I could find. Maybe there is something I am missing here? In the end, I would just like to make sure the launchd service waits for the specific disk to be available before starting the service. Any ideas how best to do that?

Hi all, I'm working on a non-interactive macOS application (a service or daemon), and I'm trying to understand the best practices around logging and error reporting, particularly in failure scenarios. If a daemon or service fails in macOS, where is it expected to log errors, and how can users or developers discover what went wrong? Specifically, I have a few questions: What is the recommended location or system for logging errors from a non-interactive macOS application? Should we use os_log, standard error output, or write directly to files somewhere? How can a user or developer access these logs to diagnose issues—should logs be visible via the Console app? Is there a standard approach to making failure information easily accessible for debugging and support, especially for daemons running under launchd? Any guidance or best practices would be appreciated.

Say I want to sync a toggle in my app with SMAppService's .status property. If the status changes from my app I can track it. But if user toggles it from System Settings, I don't see a notification so then the UI in my app is out of date. The status property is not key value observable and there doesn't appear to be a SMAppServiceStatusDidChangeNotification ? I can re-read it every time my app will become active but feels kind of wrong to do it this way.

For this code: let status = try await container.accountStatus() Seeing this error: 2025-05-08 15:32:00.945731-0500 localhost myAgent[2661]: (myDaemon.debug.dylib) [com.myDaemon.cli:networking] Error Domain=CKErrorDomain Code=6 "Error connecting to CloudKit daemon. This could happen for many reasons, for example a daemon exit, a device reboot, a race with the connection inactivity monitor, invalid entitlements, and more. Check the logs around this time to investigate the cause of this error." UserInfo={NSLocalizedDescription=Error connecting to CloudKit daemon. This could happen for many reasons, for example a daemon exit, a device reboot, a race with the connection inactivity monitor, invalid entitlements, and more. Check the logs around this time to investigate the cause of this error., CKRetryAfter=5, CKErrorDescription=Error connecting to CloudKit daemon. This could happen for many reasons, for example a daemon exit, a device reboot, a race with the connection inactivity monitor, invalid entitlements, and more. Check the logs around this time to investigate the cause of this error., NSUnderlyingError=0x600001bfc270 {Error Domain=NSCocoaErrorDomain Code=4099 UserInfo={NSDebugDescription= I initially started the this process as System Daemon to see what would happen (which obviously does not have CloudKit features). Then moved it back to /Library/LaunchAgents/ and can't get rid of that error. I see also following message from CloudKit daemon: Ignoring failed attempt to get container proxy for &lt;private&gt;: Error Domain=NSCocoaErrorDomain Code=4099 UserInfo={NSDebugDescription=&lt;private&gt;} Automatically retrying getting container proxy due to error for &lt;private&gt;: Error Domain=NSCocoaErrorDomain Code=4099 UserInfo={NSDebugDescription=&lt;private&gt;} XPC connection interrupted for &lt;private&gt; And this error for xpc service: [0x130e074b0] failed to do a bootstrap look-up: xpc_error=[3: No such process] If I start the same cli process directly from XCode, then it works just fine.

I am building an app that uses the SMAppService to register a LaunchDaemon that is bundled with my .app. I've got a priming flow created which walks the user through approving the service so that it will start on login. However, I need to also be able to upgrade this background service if the user updates the app. To do this, I think I need to call unregisterAndReturnError and then registerAndReturnError. From my testing, this seems to work correctly, but I have a concern. Will the user ever be prompted to re-authorize the LaunchDaemon that I am registering? If so, under what circumstances will that happen, and what does it look like (so that I can guide the user through it)?

I have been playing with application bundled LaunchAgents: I downloaded Apple sample code, Run the sample code as is, Tweaked the sample code a lot and changed the LaunchAgents IDs and Mach ports IDs, Created new projects with the learnings, etc. After deleting all the Xcode projects and related project products and rebooting my machine several times, I noticed the LaunchAgent are still hanging around in launchctl. If I write launchctl print-disabled gui/$UID (or user/$UID) I can see all my testing service-ids: disabled services = { "com.xpc.example.agent" => disabled "io.dehesa.apple.app.agent" => disabled "io.dehesa.sample.app.agent" => disabled "io.dehesa.example.agent" => disabled "io.dehesa.swift.xpc.updater" => disabled "io.dehesa.swift.agent" => disabled } (there are more service-ids in that list, but I removed them for brevity purposes). I can enable or disable them with launchctl enable/disable service-target, but I cannot really do anything else because their app bundle and therefore PLIST definition are not there anymore. How can I completely remove them from my system? More worryingly, I noticed that if I try to create new projects with bundled LaunchAgents and try to reuse one of those service-ids, then the LaunchAgent will refuse to run (when it was running ok previously). The calls to SMAppService APIs such .agent(plistName:) and register() would work, though.

Hi, our CourAudio server plugin utilizes the SystemConfiguration.framework to store and restore specific shared system wide settings. While our application can authenticate to utilize the SystemConfiguration.framework to gain write access to the shared configuration settings the CoreAudio server plugin obviously can't have any user interaction and therefor does not authenticate. Is it possible to authenticate the CoreAudio server plugin to gain write permissions? Are there any entitlements or other means that would allow this? Thanks!