PLCrashReporter is great. We've built many things on top of PLCR. A sliver of the many things we've built on the SDK side:
- 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
We also took the time to make our small SDK compatible with others so mobile devs can just drop us in easily.
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!
ARC is Apple's new scheme for memory management (more info here: http://developer.apple.com/library/ios/#releasenotes/Objecti...) and there are a bunch of requirements (see "ARC Enforces New Rules") that have to be met for an app to be ARC-compatible. Our SDK also has to follow those rules in order be used painlessly in an ARC-based app.
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!