The follow-up I wrote for CocoaPods issue #1852 covers a lot of technical ground, but I also wanted to tackle the issue from a less crash reporting-focused perspective.
While I think the technical direction is interesting, and we're exploring some of these ideas in PLCrashReporter, it's easy to lose sight of the original goal -- ensuring that CocoaPod users can introduce library dependencies without concern that there are significant regressions in a given library or release.
In this area, I think that social and tool-driven hints are not only cheaper to implement, but would be just as powerful -- if not more so -- than a complex crash reporting system that can only find issues after they've already shipped.
If you look at automated build and dependency tooling on other platforms (in particular, I have Maven since that's what I'm familiar with, but these notions are hardly unique to the JVM language family),