In-process crash reporting is a highly complex problem. All kinds of reasonable assumptions about your environment can break down when you are running code after a process has already failed. It's incredibly perilous, but can also make for some pretty fun challenges. Can you be defensive enough to survive failure and corruption – and still produce a useful report? This is what we really obsess about, and our latest release, Crashlytics 3.0 for iOS and OS X, takes crash reporting reliability to a whole new level.

Implementing effective defenses against memory corruption

The most common cause of report failures by far is memory corruption of some kind. With the 2.0 release, we began using the mprotect API to guard our SDK’s data structures. We used read-only pages where we could, and guard pages to help protect the writeable areas. This worked out fantastically, and produced a huge improvement in reliability.

Since then, we’ve continued to analyze the remaining sources of corruption, and with 3.0, we've gone even further, using specialized on-disk structures to further minimize our exposed memory. This means the next time some code stomps all over your memory, we're even more likely to get you an accurate report.

Reporting exceptions in your OS X apps

Exceptions have a long and complex history on OS X. This is particularly evident in the differences between how UIKit and AppKit interact with and approach exceptions. By default, exceptions can be very problematic for an AppKit app. Under many circumstances, they are caught by the framework itself. Not only does this prevent a crash report from being generated, it can also result in serious damage to the running process. This is due to the general exception-unsafety of Cocoa. While we cannot fix those issues, we can integrate more closely with AppKit. Now, we're far more likely to be able to produce useful crash reports for exceptions on OS X.

Background uploads

We’re also excited to announce that we’ve adopted NSURLSession’s background capabilities. Where available, SDK 3.0 makes use of background uploads for report submission. This is a huge reliability win, particularly for apps that tend to have short user session durations. As a side effect, we also benefit from the OS’s ability to efficiently schedule networking operations. This means a report that might have gone over a power-hungry cellular connection can now wait until Wifi is available. This can translate into reduced power requirements for crash reporting.

Ship with more confidence

We know how shipping goes. You're huddled over the Answers dashboard, waiting for that new version to start ramping up. This is the best part of shipping, and also where stability problems spoil all the fun. That is why we try so hard to build reliability into everything we do. We want to give you the ultimate confidence in your app's stability, so you can get back to enjoying all those fancy graphs.

To get SDK 3.0, make sure you're on the new Fabric Plugin and upgrade your kit!