Getting the back trace is not the hard part. When you get tens of thousands or millions of them, they become useless very quickly. The real work is in de-duplicating, coalescing, and analyzing the backtraces to tell you the insights you need, including the exact line number of code that caused the crash. Pro tip: It's usually not line 0 of the backtrace :)
You're right - it's extremely difficult, but what I was trying to get at is that it's only the beginning of the complexity.
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.
