I have a problem with a helper implemented with SMAppService daemonServiceWithPlistName. The helper run a command line program that executes system(dscl . delete /Users/name_of_user) Previously, this was implemented using AuthorizationExecuteWithPrivileges and it worked, from macOS Ventura start to show a dialog window "App would like to administer your computer. Administration can include modifying passwords, networking and system setting". But with SMAppService there is no such dialog window and helper app just stuck. I would like to know if this is a bug or correct behavior for a helper through SMAppService. Thanks for the answer.

I'm getting a code signing crash when I try to register a helper app as a login item, and I think this is new with macOS 13.4. That is, the crash log contains this: Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: CODESIGNING 4 Launch Constraint Violation I'm seeing one suspicious message in the system log: tccd Prompting policy for hardened runtime; service: kTCCServiceAppleEvents requires entitlement com.apple.security.automation.apple-events but it is missing for accessing={TCCDProcess: identifier=com.jwwalker.AutoPairs.uiapp, pid=91471, auid=501, euid=501, binary_path=/Applications/AutoPairs 4.0.1a1/AutoPairs4.0.1a1.app/Contents/MacOS/AutoPairs}, requesting={TCCDProcess: identifier=com.apple.appleeventsd, pid=531, auid=55, euid=55, binary_path=/System/Library/CoreServices/appleeventsd}, I can't figure out why the OS would think that I need an Apple Events entitlement. I've looked a the thread Resolving Code Signing Crashes on Launch, but it hasn't enlightened me. One problem I ran into is at the step certtool d "authorised0.cer" I get the output CSSM_CL_CertGetAllFields: CSSMERR_CL_UNKNOWN_FORMAT

Looking at the sample project in: https://developer.apple.com/documentation/servicemanagement/updating_your_app_package_installer_to_use_the_new_service_management_api It appears that the SMAppServiceSampleCode command line tool must be executed in a user context to successfully register the agent. Consequently, the pkg that is created in the sample project would not register the agent if it is installed as root (or when installed from an MDM). This could be worked out by using launchctl asuser to run the command line tool as the logged-in user user in the postinstall, but if nobody is logged in the pkg installation would actually fail. If the command line tool is meant to be transparent to the user and not necessarily used by the user, are there any workarounds for this or something that I am missing?

All launchdaemons inside /Library/LaunchDaemons won't launch on reboot. The launchdaemon plists seem to still work if you launch them manually with launchctl load -w but they don't survive a reboot. It was still OK with Ventura 13.0 but something seems to have changed at the system level with 13.1. I've tried every variation with configuring the plists but nothing works. There is a new SMAppService API with Ventura 13 betas but it's still too new - the old system needs to work until we've safely migrated to the new system. Changing horses in midstream and drowning... Does anyone else see this?

Under Ventura we are noticing that our software "service" is displaying under Apple Settings the "person's name" associated with the Apple Account rather than labeling the service using the name of "the service". Obviously confusing. Does anyone have a suggestion how to get a service to grab and use the service name from some plist entry in the Launch Daemon plist file? Any clues would be very welcome. Thanks.

I'm attempting to root-cause analyze issues I've been having with launch daemons controlled by launchd. My product has a single privileged LaunchDaemon running in the system domain (supposed to at least). I was looking at a client's machine that, for some reason, was running the daemon process both in the system domain and the gui/ domain for the logged in user. When I would kill both processes on the client machine, both of them would start right back up in their respective domains. The associated plist for this daemon process only exists in /Library/LaunchDaemons. My question is, how can this be possible that launchd would spin up multiple privileged daemons, but one of them running in the gui/ domain? How can this be prevented from happening? Some context/details: It was observed on the client's machine that the daemon service was previously disabled. The service was manually re-enabled using: launchctl enable system/<nameOfDaemon> sudo launchctl enable system/<nameOfDaemon> The daemon was reloaded by using: sudo launchctl load /Library/LaunchDaemons/<plist of daemon process>

I am developing a screen share app and would like to launch an agent on demand whenever i receive a request to the port on which the app listens. Based on the documentation available from Daemons &amp; Agents , i designed a plist file which looks like this, &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.myapp.assist-loginserver&lt;/string&gt; &lt;key&gt;LimitLoadToSessionType&lt;/key&gt; &lt;array&gt; &lt;string&gt;LoginWindow&lt;/string&gt; &lt;string&gt;Aqua&lt;/string&gt; &lt;/array&gt; &lt;key&gt;ProcessType&lt;/key&gt; &lt;string&gt;Interactive&lt;/string&gt; &lt;key&gt;ProgramArguments&lt;/key&gt; &lt;array&gt; &lt;string&gt;/Applications/My\ App\ share.app/Contents/MacOS/My\ App\ Assist&lt;/string&gt; &lt;string&gt;--args&lt;/string&gt; &lt;string&gt;--launcher&lt;/string&gt; &lt;/array&gt; &lt;key&gt;Sockets&lt;/key&gt; &lt;dict&gt; &lt;key&gt;Listeners&lt;/key&gt; &lt;dict&gt; &lt;key&gt;SockServiceName&lt;/key&gt; &lt;string&gt;50053&lt;/string&gt; &lt;/dict&gt; &lt;/dict&gt; &lt;/dict&gt; &lt;/plist&gt; However when i pass a request to the listening port '50053' , i don't see the app being launched. From the terminal , if i provide the Program Arguments separated by space , i can see app launch . So i don't think there is a problem with Program Arguments. When i look for active ports , i can see the port '50053' being monitored by launchd. sh-3.2# lsof -i:50053 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME launchd 1 root 30u IPv6 0xb9009595656d4fe7 0t0 TCP *:50053 (LISTEN) launchd 1 root 43u IPv4 0xb900959efe5cf82f 0t0 TCP *:50053 (LISTEN) when i pass in a curl request to the port , i do see a TCP Establishment , but it doesn't launch the app. I would like the app to be launched and let the app handle the socket connection (50053) till it is alive sh-3.2# lsof -i:50053 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME launchd 1 root 30u IPv6 0xb9009595656d4fe7 0t0 TCP *:50053 (LISTEN) launchd 1 root 43u IPv4 0xb900959efe5cf82f 0t0 TCP *:50053 (LISTEN) curl 15759 testuser 5u IPv4 0xb900959efe5ca2ff 0t0 TCP localhost:50054-&gt;localhost:50053 (ESTABLISHED) Any help on this will be much appreciated Thanks, Abhilash

I'm having some trouble getting a Login Item to launch at all. Both the main App and the Login Item are Sandboxed. I'm launching the Login Item with the following call: try SMAppService.loginItem(identifier: agentBundleID).register() The call does not fail in any way, and the subsequent status of the login item is "registered", but the login item does not launch. Then I do: -> launchctl list | grep myapp - 78 teamid.com.myorg.myapp.agent.debug and -> launchctl error 78 78: Function not implemented and -> launchctl list teamid.com.myorg.myapp.agent.debug { "EnableTransactions" = true; "LimitLoadToSessionType" = "Aqua"; "MachServices" = { "teamid.com.myorg.myapp.agent.debug" = mach-port-object; }; "Label" = "teamid.com.myorg.myapp.agent.debug"; "OnDemand" = true; "LastExitStatus" = 19968; "Program" = "teamid.com.myorg.myapp.agent.debug"; }; The LastExitStatus 19968 doesn't tell me a lot. Just that launch services probably is not being able to find my login item for some reason. Is there anything I can do to try and narrow this down to something I can fix? I have a different target for our DeveloperID App and Agent (same code different targets), and that combination works just fine. The plist produced is very similar.

We were using API "SMLoginItemSetEnabled" earlier to register loginItem with launchd. loginItem(helperApp) registers with launchd and on next reboot launchd service launches helperApp which in-turn launches mainApp. Our loginItem app is bundled within mainApp LoginItem path: $mainAPP.app/Contents/Library/LoginItems/helper.app But since it got depreciated in macOS 13 so we are planning to use new API's of "SMAppService" as suggested in this link https://developer.apple.com/documentation/servicemanagement/updating_helper_executables_from_earlier_versions_of_macos. But on invoking the register() API of SMAppService it returns success but fails to register with launchd service. On checking the status for our loginItem in terminal via command launchctl list it shows as 78 Also on checking launchd logs we observed errors related to our loginItem Please suggest if any other changes are need to be done. Thanks in Advance.

I have a UI App, myApp that I launch before login. The app launches when a button on the authorization plugin is clicked. I have acheived this using launchd. When I click the button, I write to a file which is in watchPaths in my launchd plist file. When the file is written to, launchd launches myApp. I am able to achieve this behaviour during logout-login. But it does not happen on lock-unlock. On clicking the button , the file is written to , but myApp is not launched. I need it achieve the same behaviour at lock-unlock too. How can I achieve this behaviour at lock-unlock?

I have an app that I would like to register a launchd agent at the login window. my plist looks 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>RunAtLoad</key> <true/> <key>LimitLoadToSessionType</key> <array> <string>LoginWindow</string> </array> <key>AssociatedBundleIdentifiers</key> <string>com.myapp</string> <key>Label</key> <string>com.myapp.login-window</string> <key>ProgramArguments</key> <array> <string>/usr/local/myapp.app/Contents/MacOS/myapp-agent</string> <string>--login-window-agent</string> </array> </dict> </plist> If I manually copy the com.myapp.loginwindow.plist to /Library/LaunchAgents and load it manually it works as I'd expect If I use SMAppService though it does not work: let service = SMAppService.agent(plistName: "com.myapp.login-window.plist") do { try service.register() } catch let error { print(error.localizedDescription) } I get: The operation couldn’t be completed. Service cannot load in requested session. That makes sense as I'm not at the login window when I run that routine. However checking service.status() (with formatting) I get LaunchAgent(com.myapp.login-window.plist) status: Enabled which would suggest that it's loaded, yet when I log out or reboot and I'm at the login window the agent is not running. Indeed the agent does not appear in launchctl list I'm not sure what else to check to see what's going on. I've tested loading LaunchAgents and LaunchDaemons in other contexts using the ServiceManagement framework and these all work as I'd expect once approved. It's just the LoginWindow agent that is having issues.

I need to know the list of all users connected live to the system. I am able to fetch the users detail using ioreg -d1 -c IORegistryEntry -a and look for IOConsoleUsers . But this doesn't provide information regarding the users connected via native screen share app of Mac. How can we get this detail via command line or using some files ? Thanks in Advance, Abhilash Vaidhya

We have a UI app for Mac which we want to keep running all the time, for all the non-admin users on the system. It looks like this can be achieved by adding a 'KeepAlive' launch agent in /Library/LaunchAgents. But since this solution adds an entry into System Preferences -&gt; Login Items -&gt; Allow in Background, any user can toggle the ON/OFF switch to stop the app from 'keeping alive'. Is there a way to restrict user from toggling the switch (unless the user enters admin credentials)?

I'm currently developing a screen-sharing app and i followed this post to setup daemons &amp;amp; agents , and i am able to screen share succesfully. In user-context , keyboard and mouse movements work fine; But during the login screen (first login or all users logged out) , i can perfectly relay the screen , but the app is not able to interact with the login window . ie Mouse clicks/keyboard actions fail in the login window. Is there a special configuration i'm missing to ensure the system trusts third party app for getting user inputs when logged out ? Request your help on this Attach LaunchAgents plist LaunchAgents

I have a swift app which uses SMJobBless with kSMDomainSystemLaunchd to install a privileged helper tool which performs some actions which require root. My app talks to it over XPC using NSXPCConnection. I embed the helper tool under Contents/Library/LaunchServices When building my app under macOS 13.2.1 with Xcode 14.2, installing the helper tool with SMJobBless no longer works. A copy of the app built on earlier macOS / Xcode does work fine. Can I use SMAppService.agent() ? The helper does not need to run when the user logs out. It only performs some actions as root when invoked over XPC and can exit afterwards. Is there some workaround to make SMJobBless work as before? If I use SMAppService.agent, where do I put the plist file? In which directory should I embed the tool executable if I use an agent? How should the plist file look like for a XPC launch agent? Can I have a working example xcode project which uses SMAppService.agent() to embed a privileged helper?

We have a launch daemon installed to /Library/LaunchDaemons which is loaded in the installer's postinstall by "launchctl load /Library/LaunchDaemons/com.company.AppName.service.plist". Since there have bin problems with the service starting on startup on ventura, we tried to install the plist-file into the bundle to /Contents/Library/LaunchDaemons, as recommended in the article "Updating helper executables from earlier versions of macOS", for installations on ventura. The problem is, that loading it in postinstall by "lauchctl load /Applications/AppName.app/Contents/Library/LaunchDaemons/com.company.AppName.service.plist" fails with "Load failed: 125: Domain does not support specified action". launchctl seems not to be prepared to handle LaunchDaemons included in bundles. So how can I load my launch daemon in postinstall?

Hello all, I am working on an application which will work as daemon for the user. With the update to Ventura I have seen that notification when daemons are installed is displayed. is there any way to add code to prevent that notification to show up? Thanks!

I'm writing a program that shouldn't be stopped automatically by the user. Is there a way to write code so that the UI of the background allowed item in the login item cannot be manipulated by the user? Any hints are appreciated.

On the systems with FileVault enabled, the LaunchDaemons and system extensions start after the first user login. But I expect that they will launch before LaunchAgents and other user services. When I use endpoint security as a LaunchDaemon, it launches after some LaunchAgents in 100% of cases. When I use endpoint security as a system extension with the flag NSEndpointSecurityEarlyBoot, it launches after some LaunchAgents in 90% of cases. This behavior looks like a system issue because the flag NSEndpointSecurityEarlyBoot should guarantee an earlier start than other services.

In macOS 13 Ventura, as soon as mac apps gets installed from packages, it shows two alerts (Login Items Added) one as "Unknown Developer" and other as with proper developer name. On click of alerts, it opens System Preferences and navigates to General -&gt; Login Items. It lists our apps under "Allow in the Background", one with "unidentified developer" and other with proper developer name. We followed all steps required with all apps. So why one app showing as "unidentified developer" and other with proper developer name? Also app with correct developer name, missing with its app icon.