Thanks a lot!

Thanks Quinn, that matches my understanding. Sadly, I didn't find that article during my research, would have saved me a lot of work. Is there an overview of your articles somewhere? It's quite hard to find them.

Thanks, that works. However, this records traces for all processes. Is there a way to limit the recording to a particular process? That's a benefit with ktrace. I couldn't find this in the man page of trace.

Thank you both for your help @Shay39 @DTS Engineer Quinn ! It really was the wrong address. I just tested it again with interface addresses other than loopback and it works just fine. It also works with the firewall enabled. I already tested other interface addresses, but when I did there were probably other things wrong and I discarded the idea. @Quinn: Thanks for the reply on the other thread, I didn't get a notification. Thanks again!

I'm facing the same problem. Were you able to fix it?

Thanks for your help Quinn, as always. Yes, we definitively fall under the second category. We were under the impression that daemons and agents must live under /Library/LaunchDaemons starting with Ventura and that this will become mandatory some time in the future. The documentation said: In apps that target macOS 13 and later, your app needs to only use the property list locations outlined above. If we can continue to put our launchd plists under /Library/Launch... and ignore SMAppService that would be great. I was following the provided example Xcode project in which an installer package is created and then calls the SMAppService part during the postinstall. I just assumed that "this is the way", even if it is very painful.

Thanks for your help Quinn. I figured out what the problem was. As documented, exec events increase the pidversion. But what's not documented is that even attempted execs are also increasing the pidversion. So if another ES client is denying an exec, this still increases the pidversion for that process. Accounting for this edge case, I was able to fix the traceability chain.

Thanks, that's helpful. Each of these has a fairly well-understood TCC story, and I’m happy to go into those details. That would be much appreciated! I initially encountered this problem when trying to use CLion by Jetbrains. When I try to develop a command line tool in CLion and run it there, my program does not get FDA unless I approve FDA for CLion - my actual program does not matter. While this seems to go against the least privilege approach, I can live with that. What would Jetbrains need to do to behave like Xcode in this case? Would the story differ if I put the command line tool in an app bundle?

From a user's or developer's perspective this behavior is not comprehensible. If I build a command line tool in Xcode and it lacks FDA approval, it doesn't work ✅ If I then add FDA for that binary and run it from Xcode it works ✅ but then it still can't be run from the terminal (if the terminal does not have FDA), what? 🚨 **Why is the FDA approval only honored when it is run by Xcode? ** How can I compile a program w/o Xcode and grant it FDA? The fact that this kind of behavior is not clearly documented (and all the other missing important documentation) is a constant source of frustration for us developers.

Did you figure it out? Can you post your solution?

@eskimo thanks for linking my original post. I've just posted the solution there as well. If Apple people are also reading it there, I can delete this post.

I've also succeeded with the comment in the virtual buddy repo, updating my UTM Sonoma beta 7 to rc. I can't stress enough how vital better virtualization support for us developers is. There are just so many roadblocks to virtualizing, and thus, testing other OS versions, it has become a major issue for our company. We're developing software for large enterprise customers and require a thorough testing environment across all supported OS versions. It's bad enough that there is no more professional virtualization software for macOS guests, since Parallels seems to have given up on that topic completely and UTM remains the only option. Also, the limitation of 2 VMs running simultaneously needs to be lifted ASAP and support for remote debugging needs to be added to Xcode. I'm not even getting started on better developer documentation... I don't mean to rant, but there's just so much frustration accumulated. I really enjoy macOS, but developing for it, especially when it's not a GUI app, shouldn't be this frustrating and full of roadblocks.

Were you able to solve your problem? Facing the same issue.

Filed a bug report FB11982345

We're running into similar problems with the app name not being shown in the system settings. Please let us know if you find a solution. How do you call LSRegisterUrl in the postinstall script? Do you have a dedicated binary for that?