How does a OS X Launch Agent persist settings/state?

Question

I'm writing an OS X launch agent (which watches, as it happens, for FSEvents); it therefore has no UI and is not started from a bundle – it's just a program. The relevant documentation and sample code illustrates persisting FS event IDs between invocations, and does so using NSUserDefaults . This is clear the Right Thing To Do(TM).

The documentation for NSUserDefaults in the Preferences and Settings Programming Guide would appear to be the appropriate thing to read. This shows only the Application and Global domains as being persistent, but (fairly obviously) only the Application domain is writable for an application. However the preferences in the application domain are keyed on the ApplicationBundleIdentifier, which a launch agent won't have. So I'm at a loss how such an agent should persist state.

All I can think of is that the Label in the launchd job can act as the ApplicationBundleIdentifier – it at least has the correct form. But I can't see any hint that that's correct, in the documentation.

The obvious (unix-normal) thing to do would be to write to a dot-file in $HOME , but that's presumably not the Cocoa Way. Google searches on 'osx daemon preferences', and the like, don't show up anything useful, or else my google-fu is sadly lacking today. Googling for 'set application bundle identifier' doesn't turn up anything likely, either. NSUserDefaults:persistentDomainForName looks like it should be relevant, but I can't work out its intentions from its method documentation.

I've found one question here which seems relevant, but while it's tantalisingly close, it doesn't say where the daemon gets its identifier from.

I've limited experience with Objective-C and Cocoa, which means that by now I rather suspect I'm barking up the wrong tree, but don't really know where to look next.

Answer 1

You can (and imo should) have an Info.plist even in a single-file executable.(see http://www.red-sweater.com/blog/2083/the-power-of-plist )

However, NSUserDefaults is a little more questionable. Conceptually, it's intended for user settings, rather than internal state. However, there's no real reason it wouldn't be suited to this, so I'd probably go ahead and do so.