[lollymatch]

I don't understand why anyone would use this now. It was one thing when Google bought Urchin, which was already incredibly pervasive.

But Crashlytics is a relatively mediocre solution that doesn't already have market dominance. I guess that probably made them cheaper to acquire, but now that we know that Twitter wants them to spy on everyone's mobile apps, why would anyone use them?

There are other crash reporting solutions, and we're not already locked in. It seems like a bad tactical move for Twitter to have telegraphed why they wanted Crashlytics so clearly.

[danielsju6]

I'm curious to know how you think Crashalytics is a mediocre solution.

I run AppBlade (a tangentially competitive service which offers open-source [PLCrashReporter based] crash reporting for enterprises) I have customers that opt to use Crashalytics when closed-source isn't a show stopper and have huge respect for Wayne and the team.

From what I understand they use Mach Exceptions which are the hairy/scary holy grail for exception reporting in Darwin. Mediocre is using signal handlers which the rest of us mortals do.

[pifflesnort]

Mach exceptions aren't the "holy grail", they're private API on iOS. That is why nobody is using them. If you want Mach exception handling, it should only take a couple days (if that) for a qualified engineer to implement, of which there are quite a few available from the Mac OS X olden days.

Mach exception handling was explained in _2001_ on the OmniGroup's macosx-dev mailing list: http://www.omnigroup.com/mailman/archive/macosx-dev/2000-Jun...

Crashlytics is big on marketing (your use of the phrase "holy grail" came straight from their press release), but they're possibly less than forthcoming when it comes to explaining the realities of their technical solutions. Due to this fact alone, I can't share your respect for Crashlytics' management.

[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?