I received the following from Terrence Talbot, one of the Sandvox developers:
b.bum: Sorry to catch you off-guard. In the next public version of Sandvox we’ll include an extra dialog specifically allowing the user to install — or not — SmartCrashReports.
A number of great apps out there make use of SCR. I don’t mean to draw other developers into the controversy, but Unsanity publishes a list on their site. FlickrExport, for example, links to the same .o as we do, but doesn’t install SCR. If it’s there, fine, it uses it. If not, no crash reports go back to the developer. This is a fairly important feature for us, however, particularly during the beta period. You’re right though, we should have made its use explicitly optional.
Putting the merits of using an InputManager aside just for a moment, SCR is actually a very nice solution in terms of “on the screen” user experience. Apps crash, and reports go out, in the “standard” way (over HTTP).
The only other “public” crash reporter for developers is ILCrashReporter which we’ve also tried. It, too, is somewhat of a hack, killing off Apple’s CrashReporter and leaving a third process running around that didn’t always go away. (It also explicitly uses SMTP which our early beta testers found to be blocked by corporate firewalls.)
An in-house solution would probably need to be a similar hack since some process would have to run outside the app watching for problems — just as Apple’s crashreporterd does now. Would you consider this to be unacceptable? (I think having extra processes running around, not under control of the system, has its own set of problems for the user.)
Obviously as a user you shouldn’t have to care. As a fellow developer, however, I’d rather use this as an opportunity to push for a crash reporter that we all can use. SCR seemed to be a great step in that direction. What’s the best way to move this forward for everyone?
I would like to see the same kind of tool, as well. I agree that having an additional daemon or that replacing Apple’s crash reporter isn’t really a good solution. Fortunately, it doesn’t appear to be necessary.
One person suggested something that monitors ~/Library/Logs/CrashReporter and redirects bugs accordingly. This is certainly a viable solution. It could be done via launchd, which can easily monitor a path or directory for activity.
Another solution is to do this entirely from within your own process. That was how CrashCatcher worked. Or do so in a wrapper application that springboard launches the real application. Sandvox is actually already doing this to provide the user with a nice dialog indicating that Sandvox won’t work on versions of Mac OS X prior to Tiger.