>
Wayne here. We're extremely proud of the work that the team here at Crashlytics has put into our crash reporting solution.Can you explain why you're using headers for private data structures from the Mac SDK on iOS, while also stating the following?
"At Crashlytics, one of our founding principals has been an extreme (some would say, absurd) attention to detail. Crash detection and reporting, particularly on iOS, is a complex and esoteric problem to solve, with arcane restrictions that throw modern programming practices out the window."
Copying in private headers from the Mac SDK for use on iOS isn't something you can do accidentally.
> There are many flaws in PLCR that we've addressed -- our customers,like Twitter, Vine, Square, Yelp, OpenTable, Hipmunk, Delta, Kayak, and others, enjoy the increased visibility as well as the wider net to catch issues that other solutions cannot.
We're discussing systems software engineering on the level of compilers and operating systems. Without concrete information, you are not providing what an actual engineer requires to evaluate your solution.
This topic is deep, broad, and complicated. This deserves honest engineering discourse.
A specific example. In a blog post, you state:
"Need to allocate memory at crash-time? Revisit your approach. Thinking of calling an Objective-C method? Dream on."
Those things are not possible because of the requirement that signal and exception handlers be async-safe. Ironically, while Crashlytics does not use Objective-C, it still includes code that is not async-safe.
These kinds of mistakes are a fact of engineering, which is why good engineers are humble engineers. Your unequivocal boastful marketing -- and evaluation of other solutions -- is perhaps not entirely forthcoming.