Growl, Notification Center, and Sandboxing
The benefit of this is that you do not need to rewrite your code, you’ll simply drop in an updated Growl.framework, update the XPC if you use that, and then you’re done. You now support Notification Center. If Growl is running, then Growl is used. The notification experience is pretty straight forward, users who want Growl are happy, users who just want NC are happy, etc etc.
Growl 1.4 is the current version, and the post talks about the upcoming Growl 2. However, I’m now building my apps with version 1.2.3 of the Growl SDK. Growl 1.0 through 1.2 used distributed objects and distributed notifications to communicate from the application to Growl. These are mature Cocoa APIs (dating back to NeXT) designed for interprocess communication. They are not allowed under Apple’s sandboxing rules, so for version 1.3 the Growl developers had to build an entirely new communication mechanism (called GNTP) atop the network APIs.
The developers started early and were ready for the original November 2011 sandbox deadline. They’re still working hard on bug fixes and improvements, but unfortunately my experience is that the new system is not mature enough yet. The new version of the Growl framework has caused many crashes in my applications, and the Growl application itself regularly gets into a state where it stops processing notifications and pegs the CPU.
The good news is that if your application isn’t sandboxed, or if you’re lucky enough to be granted a temporary com.apple.security.temporary-exception.mach-lookup.global-name entitlement, you can use the old version of the Growl framework with the new version of the Growl app. This seems to be perfectly reliable, although I’m not sure whether it will continue to work once the Growl application itself is sandboxed.
