Service Management framework supports installing and uninstalling services, including Service Management login items, launchd agents, and launchd daemons. General: Forums subtopic: App & System Services > Processes & Concurrency Forums tag: Service Management Service Management framework documentation Daemons and Services Programming Guide archived documentation Technote 2083 Daemons and Agents — It hasn’t been updated in… well… decades, but it’s still remarkably relevant. EvenBetterAuthorizationSample sample code — This has been obviated by SMAppService. SMJobBless sample code — This has been obviated by SMAppService. Sandboxing with NSXPCConnection sample code WWDC 2022 Session 10096 What’s new in privacy introduces the new SMAppService facility, starting at 07˸07 BSD Privilege Escalation on macOS forums post Getting Started with SMAppService forums post Background items showing up with the wrong name forums post Related forums tags include: XPC, Apple’s preferred inter-process communication (IPC) mechanism Inter-process communication, for other IPC mechanisms Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi, I was trying to run a macOS VM under a launchd daemon as part of a requirement. The parent daemon spawns a macOS VM under root user. Sometimes this is fine, but sometimes I'm getting a security error from VZ library : Unable to access security information. The virtual machine encountered a security error. In system logs, I was able to see this : ctkd: unable to generate key: error e00002e2 for com.apple.Virtualization.VirtualMachine with SepKey ACL I think this indicates Virtualization.framework asked CryptoTokenKit/Secure Enclave to create a key, and the security subsystem rejected it in the current execution context. Is it possible to run VM this way ? If yes, what am I missing ?

Hi, We are looking for guidance on synchronizing a user’s login keychain passphrase after changing that user’s local account password, when the user is not currently logged in. Context We have an MDM product for macOS, and we sometimes need to change a local account password while that user is not logged in. Updating the account password itself from our privileged daemon is fine. The hard part is keeping their login keychain in sync — that only seems to work when we run as that user, in their own session. So we perform the keychain update from a per-user LaunchAgent, not from root. What works (user is logged in) From the user’s LaunchAgent we run: # 1) Change account password (if not already changed) dscl . -passwd "/Users/<username>" "<currentPassword>" "<newPassword>" # 2) Sync login keychain passphrase security set-keychain-password -o "<currentPassword>" -p "<newPassword>" login.keychain-db With correct current/new secrets, this succeeds when the helper is running as that user while they are logged in. What fails (user is not logged in) Starting the same LaunchAgent for that user fails with: Bootstrap failed: 125: Domain does not support specified action So we cannot get user-context execution for the keychain update while the user is not logged in. Approaches we already tried Post-login LaunchAgent — We stage the current/new passwords and install a LaunchAgent that runs after the user logs in to migrate the keychain. By the time the user is logged in and the agent runs, macOS has already created a new login keychain and renamed the previous one (e.g. login.keychain-db-renamed-N). At that point we can no longer reliably migrate/restore the original keychain. sudo -u <username> security set-keychain-password … from a root daemon — Led to Keychain Access / keychain state corruption in our testing; we do not consider this a production path. Delete the login keychain — Works as a reset, but discards saved credentials. Acceptable for some admin reset flows; not acceptable for a password change where we know both secrets and want to preserve the keychain. Ask Is there a supported way to update login.keychain-db for a user who is not logged in, given known current and new passphrases, without deleting the keychain? If so, what is that way? If not is there a way to merge the old login keychain as we have the old password too? Also please confirm whether updating another user’s login keychain from root / sudo -u is unsupported, so we can exclude it from product design. Happy to provide sanitized logs (error 125, security failures, renamed keychain timelines) if useful. Thanks.

Environment macOS 14+ (Sonoma), Apple Silicon Background LaunchAgent installed at /Applications/.app, launched by a plist in /Library/LaunchAgents. LSUIElement = true (no Dock icon). Signed with a Developer ID Application certificate, hardened runtime, secure timestamp. Notarized. No provisioning profile embedded. Distributed outside the App Store (signed .pkg installer). Info.plist keys present in the installed bundle: NSLocationUsageDescription NSLocationWhenInUseUsageDescription NSLocationAlwaysAndWhenInUseUsageDescription Entitlements file: empty (I removed com.apple.developer.* entitlements because they require a provisioning profile that Developer ID distribution cannot ship.) What I need CoreWLAN's scanForNetworks(withSSID:) returns entries with nil ssid / nil bssid on macOS 14+ unless the process has Location authorization. I'm trying to obtain that authorization from the LaunchAgent so I can populate SSID/BSSID for a connectivity report. What I'm doing Instantiating CLLocationManager on the main thread (verified via Thread.isMainThread) from an NSApplication.shared.run() runloop. Setting a CLLocationManagerDelegate. Calling requestWhenInUseAuthorization(), requestAlwaysAuthorization(), and startUpdatingLocation(). Observed behavior No authorization prompt is ever displayed. authorizationStatus stays at .notDetermined across launches. locationManager(_:didFailWithError:) fires with kCLErrorDomain error 1 (kCLErrorDenied). System Settings → Privacy & Security → Location Services lists the app and its toggle can be flipped ON, yet the process still reads authorizationStatus == .notDetermined immediately after and on subsequent launches. locationd logs (Console) around the same time show: "#Warning #ClientResolution the passed keyPath is not registered. Resolving to #nullCKP" Things I've already tried Verified Info.plist keys are embedded in the installed bundle (defaults read /Applications/<app>/Contents/Info.plist). Verified codesign is valid and entitlements are preserved on install (codesign -d --entitlements - /Applications/<app>). tccutil reset All <bundle-id> and full reboot. Uninstall + reinstall. Toggling Location Services OFF and back ON, both globally and per-app. Ensuring all CLLocationManager interaction runs on the main thread. Verified CLLocationManager.locationServicesEnabled() returns true. Questions Is a Developer-ID-signed LaunchAgent (LSUIElement=true, no Dock icon) supposed to be able to trigger the standard Location prompt on macOS 14+, or is a foreground/UI process required to establish initial authorization? What does the locationd "keyPath is not registered / Resolving to #nullCKP" message indicate, and how do I diagnose which registration is missing? Is there an entitlement or Info.plist key I'm still missing for Developer-ID-distributed background agents to be recognized by locationd? Given that the Settings toggle appears to be ON but authorizationStatus still reports .notDetermined to the running process, is there a bundle identity / code-signing check I can run to confirm locationd is looking at the same identity Settings is showing? Any pointers appreciated - happy to share codesign output, sample entitlements plist, or the full locationd log excerpt on request.

My scenario I have an app which stores data using SwiftData / CloudKit automatic sync It works as expected on iOS, sync happens even when the app is closed. On Mac, when mac app is closed the data from the CloudKit is not pulled into the DB. It would be nice if the widget on the Mac is updated even when the Mac app is closed. Like from a sync from an iPhone. My problem: I don't do anything for sync other than just initializing the ModelContainer and everything is taken care of. The local store has its own system level tables to maintain the sync states. So I am a bit hesitant to do a separate sync in the background process (LoginItem / LaunchAgent / LaunchDaemon. I need to read a lot on this because I am just beginning to explore this part Questions Is it feasible / advisable to have one instance of the ModelContainer created in the background process and access it in the main app for the Mac? Reason for asking is because ModelContainer is the one that does all the sync magically. Or is this too much of an overhead and users can open the app to keep the widget updated?

I develop a tool on macOS which is composed of an UI app to manage the main app settings, and an Agent that runs in background doing some tasks ? (Running the agent is optional, can be launched from the UI app, and can be launched by macOS at startup with SMAppService. ) Agent has the LSUIElement flag set, and only shows a Menu Extra (or whatever it now named), and sometimes some notifications. The whole App package is bundled this way MainAppUI.app/Contents/Library/LoginItems/AppAgent.app (for SMAppService to work) This has been working correctly for years Now on macOS 27 beta, once I quit the UI App, having launched the Agent, the Dock reports the UI App is still running in background (with the grey dot) . But only the Agent is running, not the UI app process. Moreover, System Settings->Background apps reports both the UI app AND the Agent as both requesting to run in background. I would have expected only the Agent being listed in System Settings, and nothing appearing in the Dock. Is this a bug in the OS beta , showing the top-level container bundle as the app running in background instead of the executable direct container ? Or maybe it's on me and I should bundle my app differently ? (I cannot "reverse" the bundle and put the Agent as the main app, with UI "inside", as double clicking the main app should launch the UI App , not the Agent. ) BTW, filed FB23203848 for the same subject. thanks for any direction

I’m building a sandboxed macOS App Store app that registers an agent using SMAppService. I’m trying to understand the IPC setup between the main app and the SMAppService-managed agent. The obvious options seem to be: XPC with a Mach service But from what I understand, I’d need a special entitlement that allows me to communicate over XPC Mach service - which is unlikely to pass Mac App Store review. So how do people communicate with processes registered with SMAppService?

I have one report from a customer, who migrated all data from his old MacBook to a new one. His is on Tahoe 26.5.1 (25F80). Here is my relevant code: + (BOOL)enableLoginItem:(BOOL)enable { NSOperatingSystemVersion osv = NSProcessInfo.processInfo.operatingSystemVersion; if (osv.majorVersion >= 13) { NSError* error; SMAppService* service = [SMAppService loginItemServiceWithIdentifier:MY_HELPER_APP_ID]; if (![service registerAndReturnError:&error] && error) @throw error; return YES; } return SMLoginItemSetEnabled((__bridge CFStringRef)MY_HELPER_APP_ID, enable); } What should I do to re-enable the login helper?

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?

My software installs a privileged daemon using the SMAppService api. After removing the executables and recompiling the software I sometimes find that it needs to be registered again. After doing this, i.e. ensuring the application is properly registered and enabled in Login Items & Extensions the helper is not run when initiated from XPC. SMAppService.status has returned .enabled, and there is a valid job dictionary for the helper. I check the job dictionary with a function called updatePenaltyBoxStatus() that was given to me by a friend but I think originated from Apple. If I logoff (or reboot), login again, manually open Login Items & Extensions to check registration, then retry the application, it works. I don't mind doing this but it is probably a bit much for a lot of my users. Is there a reliable way to do this programatically? Here is my Swift translation of updatePenaltyBoxStatus. I fetch the job dictionary with SMJobCopyDictionary() prior to calling isInPenaltyBox(). I also had to write C wrapper functions for the WIFEXITED and WIFEXITSTATUS macros. func isInPenaltyBox(_ dict: Dictionary<String, Any>?) -> Bool { guard let jobDict = dict else { // If the helper was in the penalty box, unregistering it doesn't change that. So don't override a previous helperInPenaltyBox value return m_penalty_box } if let lastExitStatusObj = jobDict["LastExitStatus"] as? NSNumber { let lastExitStatus = lastExitStatusObj.intValue if wifexited(Int32(lastExitStatus)) == 0 { // It might've stopped or exited due to a signal or whatever. // Regardless, it didn't meet our criteria for winding up in the penalty box. m_penalty_box = false } // Now get the exit status and check for `EX_CONFIG`. let status = wexitstatus(Int32(lastExitStatus)) let newInPenaltyBox = status == EX_CONFIG if m_penalty_box != newInPenaltyBox { Logger.instance.log( "Penalty box change: " + m_ident + " old: " + String(m_penalty_box) + " new: " + String(newInPenaltyBox)) } m_penalty_box = newInPenaltyBox } return m_penalty_box }

My enterprise app requires a launch daemon that provides services to support my Security agent plugin. I bundle everything in an App and install using AirWatch. This all used to work until something changed, either AirWatch or the MacOS version. Now the install fails because my SMAppService instance returns an error when .register is called: Error Domain=SMAppServiceErrorDomain Code=1 "Operation not permitted" UserInfo={NSLocalizedFailureReason=Operation not permitted} If I install by opening my installer package as a user, the install always succeeds. The app is an enterprise app and is not distributed through the App Store. The app also installs a security extension. The security extension is installed and activated before any calls to SMAppService. I can't figure out what has changed in the last few months that would cause the error, or how to fix this. Any help or pointers would be appreciated.

On Sequoia, I want to configure my postfix as a server. And for this I have to change the way postfix is started from: /System/Library/LaunchDaemons/com.apple.postfix.master.plist But this file is on the read only / file system. Then I just unloaded this startup, and made a new one in: /Library/LaunchDaemons/com.apple.postfix.master.plist and I was able to start it. But on the next system boot, the system one in /System/Library/LaunchDaemons was started again. How should I cleanly and permanently achieve this server basic modification?

I'm working on securing communication between an Authorization Plugin and an XPC daemon, and I’d appreciate some guidance on best practices and troubleshooting. The current design which, I’ve implemented a custom Authorization Plugin for step-up authentication, which is loaded by Authorization Services at the loginwindow (inside SecurityAgent). This plugin acts as an XPC client and connects to a custom XPC daemon. Setup Details 1. XPC Daemon Runs as root (LaunchDaemon) Not sandboxed (my understanding is that root daemons typically don’t run sandboxed—please correct me if this is wrong) Mach service: com.roboInc.AuthXpcDaemon Bundle identifier: com.roboInc.OfflineAuthXpcDaemon 2. Authorization Plugin Bundle identifier: com.roboInc.AuthPlugin Loaded by SecurityAgent during login 3. Code Signing Both plugin and daemon are signed using a development certificate What I’m Trying to Achieve I want to secure the XPC communication so that: The daemon only accepts connections from trusted clients The plugin only connects to the legitimate daemon Communication is protected against unauthorized access The Issue I'm facing I attempted to validate code signatures using: SecRequirementCreateWithString SecCodeCopyGuestWithAttributes SecCodeCheckValidity However, validation consistently fails with: -67050 (errSecCSReqFailed) Could you please help here What is the recommended way to securely authenticate an Authorization Plugin (running inside SecurityAgent) to a privileged XPC daemon? Since the plugin runs inside SecurityAgent, how can the daemon reliably distinguish my plugin from other plugins? What is the correct approach to building a SecRequirement in this scenario? Any guidance, examples, or pointers would be greatly appreciated. Thanks in advance!

A macOS privileged helper tool that uses SubProcess crashes on intel Macs (running macOS 13 - 15: unable to test on macOS 26 on intel) with the error that libswiftCompatibilitySpan.dylib cannot be loaded when built with XCode 26.3. The same helper tool works as expected with XCode 26.2. The helper is installed using SMAppService. When I remove the dependency for SubProcess, the crash no longer occurs (but important functionality is also disabled).

The same code built in a regular Mac app (with UI) does get paired. The characteristic properties are [.read, .write, .notify, .notifyEncryptionRequired] The characteristic permissions are [.readEncryptionRequired, .writeEncryptionRequired] My service is primary. In the iOS app (central) I try to read the characteristic, but an error is reported: Error code: 5, Description: Authentication is insufficient.

I have migrated my code to use SMAppService but am running into trouble deleting the old SMJobBless launchd registration using launchd remove. I am invoking this from a root shell when I detect the daemon and associated plist still exist, then also deleting those files. The remove seems to work (i.e. no errors returned) but launchd list shows the service is registered, with a status code of 28 I am using the same label for SMAppService as previously and suspect this is the reason for the problem. However, I am reluctant to change the label as there will a lot of code changes to do this. If I quit my application, disable the background job in System Settings and run sudo launchd remove in the Terminal then it is removed and my application runs as expected once the background job is re-enabled. Alternatively, a reboot seems to get things going. Any suggestions on to how I could do this more effectively welcome.

I am running postfix on macOS Sequoia, and need it to log any kind of error to fix them. I found that in this version of macOS, syslogd is configured with the file /etc/asl/com.apple.mail, which contains: # mail facility has its own log file ? [= Facility mail] claim only > /var/log/mail.log mode=0644 format=bsd rotate=seq compress file_max=5M all_max=50M * file /var/log/mail.log which is its install configuration and seems correct. Postfix is started ( by launchd ) and running ( ps ax | grep master ), but on sending errors occur, and nothing is logged. How to make postfix to log in /var/log/mail.log which is the normal way on millions of postfix servers around the world?

Hello! I've been successfully using StartCalendarInterval in Launch[Agent|Daemon] *.plists for years. You know the deal: Mac is sleeping when CalendarInterval passes, then launchd runs the job when Mac is awoken. (This behavior is described at the bottom of an Apple doc from 2016 -- exactly how it worked before!) Recently, behavior has changed: with the computer asleep, when the date/time of the CalendarInterval passes, macOS runs the job! Even when "sleeping". However, it gets stranger: macOS will start a job when sleeping, but then suspend it in the middle. I wrote a timestamped log to check this behavior: I see job start, pause in the middle, then resume hours later when a user wakes the computer. This all makes me think that "sleep" on macOS in the past few years is now defined differently -- perhaps an Apple Silicon change? But I can't find documentation that covers this. Buried in a WWDC video, maybe? Has anyone else seen this change in launchctl calendar scheduled jobs?

I am developing a remote support tool for macOS. While we have successfully implemented a Privileged Helper Tool and LaunchDaemon architecture that works within an active Aqua session, we have observed a total failure to capture the screen buffer or receive input at the macOS Login Window. Our observation of competitor software (AnyDesk, TeamViewer) shows they maintain graphical continuity through logout/restart. We are seeking the official architectural path to replicate this system-level access. Current Technical Implementation Architecture: A root-level LaunchDaemon manages the persistent network connection. A PrivilegedHelperTool (installed in /Library/PrivilegedHelperTools/) is used for elevated tasks. Environment: Tested on macOS 14.x (Sonoma) and macOS 15.x (Sequoia) on Apple Silicon. Capture Methods: We have implemented ScreenCaptureKit (SCK) as the primary engine and CGDisplayCreateImage as a fallback. Binary Status: All components are signed with a Developer ID and have been successfully Notarized. Observed Behavior & Blockers The "Aqua" Success: Within a logged-in user session, our CGI correctly identifies Display IDs and initializes the capture stream. Remote control is fully functional. The "Pre-Login" Failure: When the Mac is at the Login Window (no user logged in), the following occurs: The Daemon remains active, but the screen capture buffer returns NULL or an empty frame. ScreenCaptureKit fails to initialize, citing a lack of graphical context. No TCC (Transparency, Consent, and Control) prompt can appear because no user session exists. The "Bootstrap" Observation: We have identified that the loginwindow process exists in a restricted Mach bootstrap namespace that our Daemon (running in the System domain) cannot natively bridge. Comparative Analysis (Competitor Benchmarking) We have analyzed established remote desktop solutions like AnyDesk and Jump Desktop to understand their success at the login screen. Our findings suggest: Dual-Context Execution: They appear to use a Global LaunchAgent with LimitLoadToSessionType = ["LoginWindow"]. This allows a child process to run as root inside the login window’s graphical domain. Specialized Entitlements: These apps have migrated to the com.apple.developer.persistent-content-capture entitlement. This restricted capability allows them to bypass the weekly/monthly TCC re-authorization prompts and function in unattended scenarios where a user cannot click "Allow." Questions Entitlement Requirement: Is the persistent-content-capture entitlement the only supported way for a third-party app to capture the LoginWindow buffer without manual user intervention? LaunchAgent Strategy: To gain a graphical context at the login screen, is it recommended to load a specialized agent into the loginwindow domain via launchctl bootstrap loginwindow ...? ScreenCaptureKit vs. Legacy: Does ScreenCaptureKit officially support the LoginWindow session, or does it require an active Aqua session to initialize? MDM Bypass: For Enterprise environments, can a Privacy Preferences Policy Control (PPPC) payload grant "Screen Recording" to a non-entitled Daemon specifically for the login window context?

our app has a helper to perform privileged operations which communicates with the main app via xpc_connection* previously that helper was installed via SMJobBless() into the /Library/LaunchDaemons/ and /Library/PrivilegedHelperTools/ due to various issues with the old SMJobBless() as well as it being deprecated we have ported the helper to the new SMAppService API where the helpers do not need to be installed but remain within the app bundle ( [[SMAppService daemonServiceWithPlistName:HELPER_PLIST_NAME] registerAndReturnError:&err] ) the new approach has been used in production for a year now and works fine in most cases and seems to be more reliable than the old SMJobBless(). however, we've observed two problems with the new helper architecture. • sometimes when users update the app (with the built-in Sparkle framework), the app does not seem to have FullDiskAccess, although the checkbox in the system settings remains toggled on. only once the Mac has been restarted, things work fine again. since this is cured by a reboot, lets ignore this issue • on some Macs, it just seems impossible to use the helper, while "installation" via SMAppService runs fine without error, using the helper always just fails with Connection invalid. This issue seems to affect ~0.2% of our users Macs, and we have found no cure yet how to get things into a working state on those Macs. luckily the issue also occurs 100% reproducible on one of the Macs in our office now. the problem seems to be a regression in macOS 26, as things worked absolutely fine on all previous macOS versions. we'd like to investigate why the helper just won't work on some Macs. unfortunately even enabling Console logging for just a few seconds yields thousands of messages nowadays, but this may be insightful: we found that on the "bad Mac", the "FATAL ERROR - fullPath is nil" always appears and subsequently no working XPC connection to the helper is ever established. on the "good Macs", this "fullPath is nil" error never appears, and the XPC connection works fine after all the required permissions (helper permission, FDA permission) are granted. so, my questons: • has anyone else seen a problem where a SMAppService / XPC based priviledged helper just won't work on a handful of Macs? • what about the "FATAL ERROR - fullPath is nil", is this the real root cause of the issue or should we look somewhere else? how can we prevent the issue on the affected Macs? the only thing that seems to be clear here is that this is a macOS 26 Tahoe bug.

Hello to all I have coded in swift a headless app, that launches 3 go microservices and itself. The app listens via unix domain sockets for commands from the microservices and executes different VPN related operations, using the NEVPNManager extension. Because there are certificates and VPN operations, the headless app and two Go microservices must run as root. The app and microservices run perfectly when I run in Xcode launching the swift app as root. However, I have been trying for some weeks already to modify the application so at startup it requests the password and runs as root or something similar, so all forked apps also run as root. I have not succeeded. I have tried many things, the last one was using SMApp but as the swift app is a headless app and not a CLI command app it can not be embedded. And CLI apps can not get the VPN entitlements. Can anybody please give me some pointers how can I launch the app so it requests the password and runs as root in background or what is the ideal framework here? thank you again.