I have made an app that requires a daemon to run. For this I use the ServiceManagement framework and the SMAppService.register to register the daemon. The macOS 14.4 update broke the installation process and the daemon cannot be installed anymore and instead returns an error when trying to install the helper. The installation works on MacOS 14.3.1 or lower. I have narrowed the error to the main app being sandboxed. Both the daemon and the main app are sandboxed (as MacOS 14.2 introduced the restriction that a sandboxed app can only run/install a sandboxed daemon, https://developer.apple.com/documentation/macos-release-notes/macos-14_2-release-notes#ServiceManagement). I have been able to confirm that removing the sandbox on the main application results in the register function working again on MacOS 14.4. However, the release notes of 14.4 do not mention anything regarding the ServiceManagement API or something related. So my question is, what has changed in MacOS 14.4 so that the register function for a daemon causes an error when the main app is sandboxed? And moreover, how can I prevent this error without removing the sandbox -- Information regarding the error: The .register function returns the following error: Error Domain=SMAppServiceErrorDomain Code=22 "Invalid argument" UserInfo={NSLocalizedFailureReason=Invalid argument I have also created a log file according to the procedure at the link below and attached it to this post: https://forums.developer.apple.com/forums/thread/707482#716553022 It appears from the log file and from observing the logs in the Console app, that the error "plist changed between client and smd" causes the issue but I don't understand what causes this error out2 2.log -- (I already use the com.apple.security.temporary-exception.sbpl entitlement in the daemon such that it can write to a specific file that the pmset command write to when invoked. This to indicate that I would prefer to keep the main app sandboxed as well. As I could also just remove the sandbox but I don't want to do that)

Since the macOS 14.2 update, services installed with SMAppService are required to be sandboxed when the main app is sandboxed as well (113037504). I had developed a daemon to communicate with the pmset interface, as that requires root privileges to make changes. Since the macOS 14.2 this daemon executable has to be sandboxed as well if I want my main app to be sandboxed. When sandboxing the daemon, it requires a temporary exception entitlement as the pmset command writes to one of the following two preference located in /Library/Preferences/: com.apple.PowerManagement.plist com.apple.PowerManagement.{UUID}.plist The specific command I use writes to the latter, which includes some specific UUID, that is specific to that device. When I use the: com.apple.security.temporary-exception.shared-preference.read-write entitlement with com.apple.PowerManagement.0000 where 0000 is the exact UUID string as on my Mac, the daemon is able successfully use the pmset command. This results however in that on other user devices it would not work as the UUID in the preference name would be different. When I try setting it to a wildcard variation such as com.apple.PowerManagement.*, the command doesn't run anymore as this format for the exception entitlement seems to be unsupported. My question is now, is there any way to get an exception entitlement which accounts for the unique identifier or is that impossible and must I disable the sandbox altogether? (as I have to use a daemon, I am not developing for the Mac App Store and a sandbox isn't strictly necessary so it wouldn't break my app. Its more I would prefer to use sandboxing if possible) Thanks in advance! For reference, this is the error I get when the entitlement is set incorrectly or not set: rejecting write of key(s) AC Power in { com.apple.PowerManagement.0000, kCFPreferencesAnyUser, kCFPreferencesCurrentHost, /Library/Preferences/com.apple.PowerManagement.0000.plist, managed: 0 } from process 15694 (pmset) because setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access