[danielsju6]

Thank you for a detailed response, we're mostly an iOS shop (little OSX experience) few here will touch a private API out of fear of Apple's wrath and Boston based, so it's hard to not get caught by the marketing wake. You've demonstrated knowledge and I'm satisfied with your belief that they are a mediocre solution.

Since you seem to have some knowledge in the field and an alternative opinion to engineers here, what is your preference for iOS crash reporting? We're currently reevaluating PLCrashReporter in our SDK but need things to be open-source.

[pifflesnort]

I would suggest also reviewing Google Breakpad. They've added iOS support, and while I haven't reviewed it first-hand, the I do know that the Google Breakpad developers don't fool around.

I do not wish to steal the OP's thunder, in that I wouldn't call Crashlytics mediocre myself. They're essentially on par with the other solutions technologically, minus the issue of private API and a tendency to overstate their marketing case.

[lollymatch]

Agreed, by mediocre I meant "ordinary." My original question being, if it's basically the same as other solutions, why would anyone use it now that we know what Twitter is doing with it.

[ttol]

Hi pifflesnort,

Wayne here. We're extremely proud of the work that the team here at Crashlytics has put into our crash reporting solution. 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 look forward to improving our solution even further - stay tuned ;-)

[pifflesnort]

> 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.

[lollymatch]

If you consider Crashlytics to be a valuable service that is a step above others, I'm curious to know why you sold it as a data spy play to Twitter? Doesn't that kind of compromise the integrity of your vision? Or was it not clear to you what Twitter was going to do with it before the acquisition?