Thank you for the answer!
If you need to manipulate the launchd state, you should use Service Management (if it's available and does what you want) or simply fork/exec launchctl. And yes, it is both sad and a chore )-:
The approach I usually use here (for example, this is what BAS shows) is to have my launchd job provide a service, and then try to connect to that service. If the connection works, the job must be installed properly. If the connection fails, some corrective action is necessary.
Could you tell a little more about what kind of services do you provide usually and how do you respond to them? Is it something like AppleEvents? Or some kind of user-signals?
Well, yes. But launchd is *normally* used in this way, to launch gui-less tools. The path to your tool is the first element in the ProgramArguments array. If you wanted to launch an *app* with launchd, you'd need to use /usr/bin/open.
But how should it be done? Do i need to save a plist file to /users/myuser/library/launchagents? or can i have it dynamically? As i understand for now, to correctly launch a GUI-less tool (for example, ls), i need: 1) generate plist file (using NSDictionary, for example - and correctly fill ProgramArguments field there) 2) save that plist file somewhere on disc (for example, some kind of tmp folder) 3) call fork/exec with params launchctl load "a/path/to/my/saved/plist/folder" 4) call fork/exec with params launchctl start "my.justloaded.nongui.app.label" 5) if i want to terminate that application, i have to fork/exec launchctl unload "my.justloaded.nongui.app.label" 6) then i have to delete that temporary plist file (at what moment of program execution?) Is it the only right way? Sounds like a bit of overhead.. Could you comment these steps? Thanks again!