This a rather complex fix as it turns out Bundle.main.bundleURL behaves differently for helper tools located within an .app bundle if they're located in Contents/MacOS/ vs Contents/Resources/. In the case of Contents/MacOS/ which I had previously never tested, the bundleURL returned is for the entire bundle while for the Contents/Resources/ case it returns a path to Resources.
This by itself wouldn't be too complicated because in these cases Bundle.main.executableURL will return a path to itself. However it's valid for a SMAppService agent or daemon to be an app bundle (and not just a command line tool) and we need to differentiate this situation otherwise it wouldn't be possible to identify the parent bundle.
Additionally it's valid for the case where the helper tool isn't in a bundle at all in which case Bundle.main.executableURL isn't applicable. As such _NSGetExecutablePath was used to consistently derive a path.
This a rather complex fix as it turns out
Bundle.main.bundleURLbehaves differently for helper tools located within an.appbundle if they're located inContents/MacOS/vsContents/Resources/. In the case ofContents/MacOS/which I had previously never tested, thebundleURLreturned is for the entire bundle while for theContents/Resources/case it returns a path toResources.This by itself wouldn't be too complicated because in these cases
Bundle.main.executableURLwill return a path to itself. However it's valid for aSMAppServiceagent or daemon to be an app bundle (and not just a command line tool) and we need to differentiate this situation otherwise it wouldn't be possible to identify the parent bundle.Additionally it's valid for the case where the helper tool isn't in a bundle at all in which case
Bundle.main.executableURLisn't applicable. As such_NSGetExecutablePathwas used to consistently derive a path.