Looking for our logo? X
|
|
|
|
The Crashlytics SDK uses a multi-step symbolication process to provide progressively higher levels of detail. We start with on-device symbolication. Once a crash report makes it into our system, stack frames are then re-processed against your application's dSYM on our servers. This two-step symbolication process, coupled with our advanced aggregation algorithms, provides the highest information fidelity available.
To better respond to customer support inquiries, it's often helpful to know which of your users experienced a given crash. Fortunately, Crashlytics makes this easy!
Our user attribute methods let you provide an id number, token, or hashed value that uniquely identifies the end-user of your application without disclosing or transmitting any of their personal information. This value is displayed right in the Crashlytics dashboard for easy access.
We've built both macro- and function-based logging to help pinpoint issues. The macros automatically include file, line number and function name information in addition to any logging text you provide. They also make it easy to suppress logging in release builds.
We've worried about performance so you don't have to: our logging facilities are nearly 10X faster than NSLog!
Context is king when debugging crashes, and knowing the values of critical variables in your app, such as the level of the game the user got to, how many friends they have, or the byte size of the last photo they took, might be critical in shaving hours off your debugging time.
You're in luck — Crashlytics allows you to associate arbitrary key/value pairs with your crash reports, and they're viewable right along side the crash details.
0 |00:00:00.27|$ -[FirstViewController viewDidLoad] line 20 $ view one
1 |00:00:00.27|$ collider starting
2 |00:00:00.27|$ particles ready
3 |00:00:00.27|$ higgs boson test 1
The Crashlytics SDK was designed with utmost care to guarantee
that it has no negative impact on your app's performance.
One of the world's top apps ran an internal test comparing the startup time between us and another SDK. The other SDK clocked in at 34% of their app's startup time — Crashlytics came in at 2%.
On average, Crashlytics adds only 40 KB — or the size of a single image — to the weight of your application.
We don't require linking against any additional frameworks or libraries.
When initialized at start-up, Crashlytics performs only the minimal amount of required work and defers the rest until a few seconds after app startup completes. This delay is configurable — we want your app to launch as quickly as possible!
Our memory footprint has been carefully tuned to minimize overhead. We guarantee Crashlytics will not impact gameplay, video processing, or any memory-intensive operations you perform.
We care tremendously about the stability of your app and the experience for your users. If for any reason our SDK fails, its defensive design will ensure it has no negative impact.
We use run-time feature detection to ensure compatibility with iOS 4 to iOS 6 and beyond.
In-process crash reporting is an incredibly delicate affair. One misstep can lead to deadlocks, infinite loops or un-reportable crashes. We've taken great pains to ensure that our SDK is async-safe — a necessity for safe crash-time execution.
When the device is in airplane mode or experiencing a bad network connection, we will queue crashes so you still get all of the reports — with no impact on your app's performance. When network access is restored, off they go.
