toggle quoted messageShow quoted text
SMJobBless is a royal pain to get going. By far the easiest (and perhaps coolest) way of running a privileged app (usually for an installer) is to do it through AppleScript.
Something like: “do shell script xxx with administrator privileges” does the job of setting up authentication quite nicely and gets around all the SMJobBless mess.
This is set up in a top-level app, one that runs when the installer is launched. It then launches a lower-level app (with privileges) where the actual work is done.
Once thing to watch for - the low level program does not inherent the same settings as a normal application. It will probably run in English with a US locale, as
opposed to whatever language and locale setting the user has set. It is easy to capture these in the top level app and send them over to the main installer,
usually through command line arguments.
I doubt it is usable in an MAS program, mostly because it requires a two-program approach. But then so does SMJobBless, so it might be worth a try.
On Jul 20, 2017, at 12:07 PM, Jens Alfke <jens@...
I achieve this with a launchd.plist installed in /Library/LaunchDaemons which simply relaunches the app if the window is ever closed (closing the window terminates the app).
LaunchDaemons is the wrong directory; that’s for system daemons that run outside of any user context. (I’m surprised you actually got this to work, because it’s difficult to present any UI from a daemon.) LaunchAgents is better, as those are launched into the current login context.
Also, if you want the window to be visible at all times, just don’t make it closable (turn off that checkbox in IB.)
What is the preferred way to install this file for a distributable version of my app? Do I create an installer?
That’s one way, or use the authorization API to run a helper shellscript that installs the file.
This seems to be a thing of the past, especially considering the MAS.
You’ll never be able to distribute this via the MAS, because that would require the app to be sandboxed, which prevents it from being able to install the plist. (It’s pretty obvious that altering files in /Library has tremendous potential for malware, and this is the kind of thing sandboxing is designed to protect the user from.)