I'm just wondering how much one could raise revenues doubling twice in the last 2 years and more than half a million expected in the next 12 months.
I've been using it for about 2 years now (even submitted a patch or two), and I have a pretty good grip on my crashes. When you use it for a while you realize you don't really need the statistical analysis of the crash reports, because you end up having no crashes if you fix the problems as soon as they show up.
So yeah, if you have a crash reporting problem just add PLCrashreporter to your project, add a file upload code (to your S3 bukket) and look through them regularly. That's all it takes.
- transparent symbolication so that you get the exact line of code
- compatibility with ARC in iOS 5
- we handle both fatal and non-fatal exceptions
- detect low-memory warnings
- and much more
Beyond that, there's a whole other world to consider outside the SDK. For example, since we want to make sure devs don't need to ship with debug symbols built in (30-50% increase in app size), we have done all the heavy lifting instead of shifting that to the developer (and then to the user).
In terms of just dumping the logs to an S3 bucket, that may work initially, but once you start getting tons of crash reports, the real problem starts -- how to make sense of it all. We also wanted the filename and the line of code that it crashed on, but this wasn't terribly easy to do. We ran into these issues ourselves and decided to build an elegant solution to this problem.
We're excited about this space and have been deeply involved in it. Great stuff to announce soon that should shed more light!
- Team HockeyApp
http://landonf.bikemonkey.org/code/objc/Reliable_Crash_Repor...
Landon has done incredible work in this area and we are incredibly grateful he has shared his work with the world - it very much inspired a good chunk of what we do. We have taken things further, though, and updated his techniques to work more robustly with LLVM3 and ARC, added non-fatal exception handling etc. All of this must be done extremely carefully, using async-safe code that is tuned to minimize memory footprint. It's not trivial, but it's worth the effort on our end to deliver the best product we can.
We're huge proponents of PLCR and I wouldn't discourage anyone from using it directly. In fact, we're 100% compatible with it, if you wish to run us and PLCR at the same time, side-by-side. The benefits to using our system, apart from the significant aggregation and analysis we do, is that we actively maintain and update our report collection to support the latest iOS and compiler capabilities, so you don't have to worry about that.
Hope this helps!