we are seeing SMAppService.mainAppService.status returning SMAppServiceStatusNotFound for some of our users. from the documentation: SMAppServiceStatusNotFound = An error occurred and the framework couldn’t find this service. however shouldn't it be impossible for the mainAppService to be not found? it seems that return would only make sense for agents/daemons/loginitems. any idea what is going on here?

same here and for any other Xcode user. the lack of quality control at Apple is unbelievable

same issue here, no more notarisation possible on Xcode 14.2 (on macOS 12.6.7). i cannot confirm that it works after 4-5 times, had 10 failures in a row with the very same "Couldn’t communicate with a helper application." message.

issue still exists in final Xcode 15

thanks for your reply here SMAppService is really intended to be used by apps; the clue is in the name (-: yes but there must be a way to fully install apps (even if they use SMAppService) in a non-interactive way, especially for businesses. I’m not 100% sure why you’re having this problem. Is that script you posted an example of what you were previously doing with your SMJobBless code? yes, as mentioned this script is what we were previously doing when the app was still based on SMJobBless. now that the app('s helper) is based on SMAppService, how to install&approve the helper instead? as written launchctl bootstrap system just errors out... Having said that, in a managed environment the site manager can configure some of these privileges via the com.apple.TCC.configuration-profile-policy payload, deployed via MDM. thanks, exactly what we need.

In my experience folks who run managed sites really like installer packages, because MDM systems are good at running those. So, one option here is to repackage your app as an installer package, no problem there. but it really doesn't matter technically if the solution is triggered by a script run during PKG installation or if the script is embedded in the app and the MDM admin calls it in some other way and have the installer package install the daemon like it would any other launchd daemon should not matter if the daemon is installed via a PKG or by a script run as root, right? that is, copy the launchd property list file to /Library/LaunchDaemons. this finally sounds like a solution, great and THANKS. i was not aware that SMAppService actually supports daemons installed outside the app, as the documentation always mention they stay embedded in the app. however and in any case, i tried your solution, but it did not work. the plist can be copied to LaunchDaemons but cannot be loaded into launchd steps to reproduce: • i made a copy of the PLIST file that points to the app via an absolute instead of a relative path (attached as com.corecode.MacUpdaterPrivilegedInstallHelperTool2_MDM.plist ) • i modified the installation script (attached as priviledgedHelperTool_install.sh ) to install the plist file to /Library/LaunchDaemons but it cannot be activated either via launchctl or just by rebooting or via the LaunchControl guy. launchctl gives the same uninformative "Bootstrap failed: 5: Input/output error" error that i mentioned in my initial report. • since the daemon cannot be bootstrapped, the app cannot communicate with the helper so, we are still at the beginning. how to install the SMAppService based helper daemon non-interactively? thanks! note: this content was sent private to DTS on 12. February as part of a TSI. since i have still not received a reply there i'll repost here instead. attachment 'priviledgedHelperTool_install.sh': https://pastebin.com/QurSFjUT attachment: 'com.corecode.MacUpdaterPrivilegedInstallHelperTool2_MDM.plist': https://pastebin.com/cZCPWZhf

thanks for your update and correction. i can confirm that skipping BundleProgram and using ProgramArguments or Program now works as intended, at least in initial testing. to recap, to install a SMAppService based LaunchDaemon from a script or a PKG instead of interactively with daemonServiceWithPlistName you only need to change the BundleProgram key in the helpers plist to Program or ProgramArguments.

Log output in the "good case" error 16:19:36.784221+0000 MacUpdater Info: installHelperTool=>install called in response to 'install helper' button click default 16:19:36.793426+0000 backgroundtaskmanagementd effectiveItemDispositionWithAuditToken: pid=1133, type=daemon, url=Contents/Library/LaunchDaemons/com.corecode.MacUpdaterPrivilegedInstallHelperTool2.plist -- file:///, config={BTMConfigArguments = ();BTMConfigBundleIdentifiers = ();BTMConfigExecutablePath = "Contents/Resources/com.corecode.MacUpdaterPrivilegedInstallHelperTool2";BTMConfigLabel = "com.corecode.MacUpdaterPrivilegedInstallHelperTool2"; BTMConfigSHA256Checksum = {length = 32, bytes = 0xdb895cbb 550e1cf7 1174e785 98817f14 ... 36a73b15 dcffc6cc }; } default 16:19:36.812777+0000 backgroundtaskmanagementd effectiveItemDisposition: appURL=file:///Applications/MacUpdater.app/, type=daemon, url=Contents/Library/LaunchDaemons/com.corecode.MacUpdaterPrivilegedInstallHelperTool2.plist -- file:///, config={BTMConfigArguments = ();BTMConfigBundleIdentifiers = ();BTMConfigExecutablePath = "Contents/Resources/com.corecode.MacUpdaterPrivilegedInstallHelperTool2";BTMConfigLabel = "com.corecode.MacUpdaterPrivilegedInstallHelperTool2"; BTMConfigSHA256Checksum = {length = 32, bytes = 0xdb895cbb 550e1cf7 1174e785 98817f14 ... 36a73b15 dcffc6cc };} error 16:19:36.812838+0000 backgroundtaskmanagementd effectiveItemDisposition: record not found: appURL=/Applications/MacUpdater.app, url=/Contents/Library/LaunchDaemons/com.corecode.MacUpdaterPrivilegedInstallHelperTool2.plist, type=daemon, config={ BTMConfigArguments = ( );BTMConfigBundleIdentifiers = (); BTMConfigExecutablePath = "Contents/Resources/com.corecode.MacUpdaterPrivilegedInstallHelperTool2"; BTMConfigLabel = "com.corecode.MacUpdaterPrivilegedInstallHelperTool2"; BTMConfigSHA256Checksum = {length = 32, bytes = 0xdb895cbb 550e1cf7 1174e785 98817f14 ... 36a73b15 dcffc6cc }; } default 16:19:36.813157+0000 MacUpdater Service <private> status: 3 … default 16:19:54.185694+0000 MacUpdater [0x9e18c0c80] activating connection: mach=true listener=false peer=false name=com.corecode.MacUpdaterPrivilegedInstallHelperTool2 default 16:19:54.186103+0000 com.corecode.MacUpdaterPrivilegedInstallHelperTool2 [0x74acb4180] activating connection: mach=false listener=false peer=true name=com.corecode.MacUpdaterPrivilegedInstallHelperTool2.peer[1133].0x74acb4180 …

Log output in the "bad case" error 16:40:03.112823+0100 MacUpdater Info: installHelperTool=>install called in response to 'install helper' button click default 16:40:03.124697+0100 backgroundtaskmanagementd effectiveItemDispositionWithAuditToken: pid=19798, type=daemon, url=Contents/Library/LaunchDaemons/com.corecode.MacUpdaterPrivilegedInstallHelperTool2.plist -- file:///, config={ BTMConfigArguments = ( ); BTMConfigBundleIdentifiers = ( ); BTMConfigExecutablePath = "Contents/Resources/com.corecode.MacUpdaterPrivilegedInstallHelperTool2"; BTMConfigLabel = "com.corecode.MacUpdaterPrivilegedInstallHelperTool2"; BTMConfigSHA256Checksum = {length = 32, bytes = 0xdb895cbb 550e1cf7 1174e785 98817f14 ... 36a73b15 dcffc6cc };} default 16:40:03.141046+0100 backgroundtaskmanagementd effectiveItemDisposition: appURL=file:///Applications/MacUpdater.app/, type=daemon, url=Contents/Library/LaunchDaemons/com.corecode.MacUpdaterPrivilegedInstallHelperTool2.plist -- file:///, config={ BTMConfigArguments = ( ); BTMConfigBundleIdentifiers = ( ); BTMConfigExecutablePath = "Contents/Resources/com.corecode.MacUpdaterPrivilegedInstallHelperTool2"; BTMConfigLabel = "com.corecode.MacUpdaterPrivilegedInstallHelperTool2"; BTMConfigSHA256Checksum = {length = 32, bytes = 0xdb895cbb 550e1cf7 1174e785 98817f14 ... 36a73b15 dcffc6cc }; } error 16:40:03.141098+0100 backgroundtaskmanagementd effectiveDisposition: FATAL ERROR - fullPath is nil, container=(null), item=uuid=753BC2AC-6854-4F5D-B556-80A605739848, name=com.corecode.MacUpdaterPrivilegedInstallHelperTool2, type=daemon, disposition=[disabled, disallowed, notified], identifier=16.com.corecode.MacUpdaterPrivilegedInstallHelperTool2, url=Contents/Library/LaunchDaemons/com.corecode.MacUpdaterPrivilegedInstallHelperTool2.plist -- file:/// default 16:40:03.141324+0100 MacUpdater Service <private> status: 0 … default 16:40:18.433378+0100 MacUpdater [0x91edf6300] activating connection: mach=true listener=false peer=false name=com.corecode.MacUpdaterPrivilegedInstallHelperTool2 default 16:40:18.433536+0100 MacUpdater [0x91edf6300] failed to do a bootstrap look-up: xpc_error=[3: No such process] default 16:40:18.433548+0100 MacUpdater [0x91edf6300] invalidated after a failed init error 16:40:18.497570+0100 MacUpdater testConnection: exiting with ERROR 0x20a8d0c30 <dictionary: 0x20beb7c10> { count = 1, transaction: 0, voucher = 0x0, contents = "XPCErrorDescription" => <string: 0x20beb7d58> { string cache = 0x0, length = 18, contents = "Connection invalid" }} …

good logfile attached goodlog.txt bad logfiles here (too large to attach, bah) https://230402id2zpmvv4ytt6.nextcloud.hosting.zone/s/gJzsxWR3JrMt6G9

thanks. the issue was 100% reproducible on this Mac for at least 3 months (maybe since Tahoe installation?) across dozens of reboots. i've generated the log files of the failures just 2 days ago. but the funny thing is, i just tried to reproduce it again because you requested the sysdiagnose logs and ... today the issue is gone. the helper now works just fine on this Mac too. so, unless the log files i already have are enough, i cannot contribute more to get this resolved. the logfiles are quite comprehensive, its nearly 2 MB text...

thanks here to both of you While I've seen these issues happen to many developers, they're much, MUCH rarer on end-user systems. creating weird fails that would otherwise have never occurred. i already guessed as much. normally if there are weird issues that affect less than 0.1% of users, it will be completely impossible to ever reproduce them on a developer Mac, which is usually much cleaner / less broken. but the fact that we saw this very rare issue also in the office which would normally be very unlikely suggests that this type of issue (and i guess all across XPC/Helpers/Login/Permissions/Certificates/…) is more prone to occur on dev-Macs. That's not something that would ever happen on end-user machines and it's easy to accidentally waste a few hours investigating a "bug" that's never actually going to happen. i am sure that this is generally good advice, in this particular case the issue also affected tiny percentage of users so this would have been a great opportunity to nail down the issue if it had just lasted a bit longer There’s a lesson to be learnt here, namely grab sysdiagnose logs early and often (-: ok thanks. if anything else comes up or i or a customer can grab a sysdiagnose i'll post here again and make a bug report. p.s. no luck just looking at the effectiveDisposition: FATAL ERROR - fullPath is nil code path? ;-)