This answer is from 2013 but is mostly still relevant.
Prior to Mountain Lion, all processes managed by launchd, including
regular applications, had their stdout and stderr file descriptors
forwarded to the system log. In Mountain Lion and above, stdout and
stderr go nowhere for launchd managed applications. Only messages
explicitly sent to the system log will end up there.
If you're writing an application and would like some output to show up
in the console, then adopt an API built on syslog(3) or asl(3)
instead. NSLog is one such API, and it has the advantage of logging to
stderr too so you can easily see your output no matter how you've
launched your application. If you'd like that functionality but want
to use asl or syslog directly then you'll want to look in to the
ASL_OPT_STDERR option to asl_open, and the LOG_PERROR option to
openlog respectively.
Basically, when you double-click an app (same as /usr/bin/open /Applications/SomeApp.app
) there is no stdout/stderr. The dev is expected to send any relevant output/errors to the available logging APIs such as NSLog.
dmg
) is irrelevant to how it generates error messages and logs them. It my send the output to the standard system log or it may have a log all on it's own. How it behaves based on how it's launched is also a function of the app, not the system so that too would have to come from the dev. What's the application (not that there's any guarantee we'd know the inner workings of said app)? What version of macOS? Without info like this it tough to even hazard a guess. – Allan Jun 9 '20 at 17:28