Hmmmm, I always assumed that using SMAppService to unregister and then re-register your daemon would fix this. But I suspect you’ve already tried that and it didn’t work. Is that right? Yes, it doesn't update the path of the app bundle. I'll mention that I'm testing in macOS 13 since that's the minimum system my company still supports, so I wonder if this is an issue that's been fixed in later macOS releases.

Let’s start by talking about user machines. Many apps have a first launch check, one that checks whether they’re located in Applications and prompts the user to move the app there if they’re not. I’m not super enthusiastic about that concept in general, but if your app has an embedded launchd daemon I think it makes sense. Yes, I've already coded that behavior into my app. I agree it's not ideal, but my app may also include a system extension which would make being somewhere inside of /Applications a hard requirement. I was hoping though that the user might be able to choose where in Applications they put it, but it seems like it might just be a better idea to force it to go into the root of Applications, otherwise it will break if the user ever decides to move it later. ⠀ Also, it probably makes sense to have some sort of self-repair mechanism, so something that detects that things have gone wrong and either tells the user how to fix it or offers to fix it for them. This is part here is really the crux of my question. Is there anything the app can do on its own to fix the situation? For example, is there a way to modify which copy of the app is registered as the default copy with Launch Services? SMAppService lacks the means to do so on its own. Since you mentioned Launch Services, I dug a little deeper and found that if I dump the Launch Services database on my dev machine using: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump ...it doesn't have an entry for my app in the Applications folder. But that's where its launch daemon is trying to start from, and that's where the entry for it is listed if I run sfltool dumpbtm. This suggests to me that it's not actually the default copy from Launch Services that determines where it runs. Am I correct, and if so, any idea where it's actually getting the path of the app that's associated with the launch daemon? ⠀ Second, there’s the question as to what to do about your development machine... I worked around this actually by making a symlink in /Applications that points to the copy of the app I'm currently working with. Not particularly elegant but it means I don't have to use sfltool resetbtm to fix it.

What is "this"? I think you two might have different concepts of what "works" means in this case. I did broaden what I was discussing, but the "this" was about having a secondary standalone executable in the app bundle being granted Accessibility permissions along with the main executable. Or is this, and only this, what you're asking about? The bit about Activity Monitor is the disadvantage of the approach I was referring to. If you're happy with the current TCC and Accessibility behaviour, then I recommend you just ignore Activity Monitor. If users vandalize your processes, tell them not to do that or else it won't work. There are tons of duplicate process names in Activity Monitor. Why would they care about yours? This is what I intend to do. And of course Activity Monitor is full of duplicate or inscrutible process names. But all else being equal I like software that makes things as clear as possible. Having the secondary process being named something like "MyApp System Service" or similar would make it a lot clearer, and being that I'm the sort of power user who appreciates that sort of thing, there are likely others out there too. And a significant portion of the userbase of the app I'm developing is power users. Again, I think you're talking about different things. That flow and all those barrers aren't bugs. They are by design. They are "the feature". And they're very fragile and often change. Yes, they are by design, but what you are describing is something that is badly designed and implemented, which is why I am critical of it. I know all too well how fragile, buggy and subject to change the process of granting these permissions is, because I've been working with them extensively ever since they were introduced in OS X 10.9. My recommendation is to focus on your core app features and treat any of those extras that require user assent as "nice to have". Accessibility looks great from a marketing perspective, but you shouldn't depend on it. I'm afraid this isn't a useful suggestion. For a whole class of apps, Accessibility permissions aren't a "nice to have", they are a hard requirement, and this is the case of the app I'm working on. In fact all four of the permissions I mentioned earlier are all required in order for the app to run, which is why I had to make a bespoke bit of UI that walks the user through granting all of them before the app will even launch.

Unfortunately I don’t think there’s a way around that when it comes to TCC. Regardless of this specific issue, there is basically no documentation for the TCC edge cases that crop up on macOS (multiple instances of an app, user vs system-wide privileges, launchd daemons and agents, and so on). Good point. I think the fact that this behavior has been working for many years suggests that it's likely to continue for a while longer. And as I mentioned, it'd be a problem if only the main executable of an application bundle could be granted TCC permissions, and not the standalone executables that live next to it. Curiously, we recently introduced something like that, but only for managed devices. Check out WWDC 2026 Session 206 What’s new in managing Apple devices, starting around 10:56. That's encouraging and certainly an improvement. I hope Apple brings this sort of flow to every day users on non-managed devices!

So, you’re using the BundleProgram property to tell SMAppService to locate your daemon relative to your app? Yes, that's right. That launch daemon will start up, but only if my app bundle is at the file location associated with my app's bundle ID as printed by sfltool dumpbtm

Interesting. I’m surprised that works. This has me wondering now, is this is supported behavior? I'm hesitant to rely on something that could be removed in a future release. I suppose it does make some sense, since Accessibility permissions are granted to an app bundle and it'd be impossible for a bundled standalone executable to have the permission if this wasn't the case. And it has been working for at least five years now. Regardless of what you choose, I think it makes sense for you to file a bug requesting that we add better support for this. To be perfectly frank, the process of granting permissions in macOS is a mess, so I feel like my bug report would be a lot more comprehensive than that. My app requires as many as four permissions from the user (system extension, background items, accessibility, screen recording) and could be more depending on how things play out with granting the launch daemon permissions. Each permission has a different flow, and it required spending a lot of time creating a bespoke UI for walking users through it complete with screen shots highlightling what to click, because the process is not that straight-forward for novice users. And it's going to be a nightmare to localize. macOS desparately needs a standard dialog that allows an app to grant all of its needed permissions to itself and any helper apps, similar to what you see when installing an extension in a browser like Chrome. Something that lets the user see exactly what they're agreeing to, but lets them grant it with a simple "yes" or "no" rather than a cumbersome series of steps.

Some corrections (that I unfortunately cannot edit into my original post!) NSRunningApplication.activateWithOptions isn't deprecated, but the option NSApplicationActivateIgnoringOtherApps is. Instead of NSRunningApplication.yieldActivationToApplication I meant NSApplication.yieldActivationToApplication. Instead of NSRunningApplication.activate I meant NSRunningApplication.activateFromApplication. These corrections aside, I'm still looking for an answer to my original main question.

Please disregard. The installation scripts were deactivating an existing kernel extension before activating, hence the extra prompt.