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.

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 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.

issue still exists in final Xcode 15

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.

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

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?

no idea until Apple says anything about this. i've filed a bug report about the missing documentation on this  FB8901281 'LSMinimumSystemVersionByArchitecture' undefined for "Apple Silicon"