First of all thanks for all the information. [quote='809677022, DTS Engineer, /thread/766464?answerId=809677022#809677022'] This is very specific to Python and I’m not really the right person to advise on that. [/quote] Fair enough, I'll seek advice elsewhere for that. [quote='809677022, DTS Engineer, /thread/766464?answerId=809677022#809677022'] I recommend that you install the agent via SMAppService [/quote] I've created a sample project and have been doing precisely that. I followed the Embedding a command-line tool in a sandboxed app with a slight variation: no sandboxing and including a .plist for the launchd agent in Contents/Library/LaunchAgents I've been using cx_freeze to build the application, and it produces the following structure: . ├── frozen_application_license.txt ├── main ├── lib/ └── share/ lib/: Contains a bunch of .so and .pyc files. It also includes a Python executable and some .dylib files. share/: Some binary files for zone_info. Due to its nested structure, I struggled to automatically code-sign the files using Xcode. I've used a build phase script to do that manually. If I move all that content into Contents/MacOS, the final app cannot sign. However, if I move only the main executable into Contents/MacOS and symlink the rest from Contents/Resources/lib -> Contents/MacOS/lib, I can run the main application and run the launchd agent successfully. I don't know if that's a valid approach. [quote='809677022, DTS Engineer, /thread/766464?answerId=809677022#809677022'] ...it’ll have to be placed in an app-like wrapper. [/quote] Fair enough. Suppose I put the agent into an app-like structure. How exactly would I nest that into my existing application? The agents .plist would need to be inside Contents/Library/LaunchAgents of the main application. How about the rest? Thanks!

First of all, thanks for all the information. This is very specific to Python and I’m not really the right person to advise on that. Fair enough, I'll seek advice elsewhere for that. I recommend that you install the agent via SMAppService I've created a sample project and have been doing precisely that. I followed the Embedding a command-line tool in a sandboxed app with a slight variation: no sandboxing and including a .plist for the launchd agent at Contents/Library/LaunchAgents I've been using cx_freeze to build the application, and it produces the following structure: . ├── frozen_application_license.txt ├── main ├── lib/ └── share/ lib/: Contains a bunch of .so and .pyc files. It also includes a Python executable and some .dylib files. share/: Some binary files for zone_info. Due to its nested structure, I struggled to automatically code-sign the files using Xcode. I've used a build phase script to do that manually. Additionally, I'm unsure if it's possible to split up the files correctly to achieve the wanted structure as explained in Placing content in a bundle What works is when I move only the main executable into Contents/MacOS and create symlinks for the rest: e.g. Contents/MacOS/lib -> Contents/Resources/lib, I can run the main application and run the launchd agent successfully. This feels similar to Use symlinks for gnarly edge cases in Embedding nonstandard code structures in a bundle. I'm not sure if that's a valid approach in this case, though. ...it’ll have to be placed in an app-like wrapper. Fair enough. Suppose I put the agent into an app-like structure. How exactly would I nest that into my existing application? The agents .plist would need to be inside Contents/Library/LaunchAgents of the main application right? How would I put the launchd app-like structure into the existing app structure? Thanks!

That makes sense, thanks. [quote='820978022, Developer Tools Engineer, /thread/772300?answerId=820978022#820978022'] Is there any reason why would you want to use immediate mode with xctrace? [/quote] I'm developing a program which runs multiple XCTests in sequence and records each test separately using xctrace. Since it can take a while before the .trace file is stored, I was wondering if this could be improved with something like an immediate mode. But I'll probably just implement it in a way where the next test can already start, thus, having potentially multiple xctrace commands running at the same time.