The most powerful, yet lightest weight crash reporting solution for iOS and Android developers. | Crashlytics
Production ready


On average, Crashlytics adds only 45kb - 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 a minimal amount of required work and defers the rest until a few seconds after app startup completes. This delay time is configurable -- we want your app to start as quickly as possible!

Our memory footprint has been carefully tuned to be the minimum necessary.

We care tremendously about the stability of your app and the experience for your users. If for any reason our SDK fails to do what it's supposed to do, it has no impact on your app or to your users.

We use run-time feature detection to ensure compatibility with Android 2.1 and beyond and iOS 4.0 and beyond.

All server communication is completed over SSL using packed-binary file formats. An average crash represents 20kb of data, which varies based on the length of your method names and the depth of the stack trace.

The first time a user launches your application, a single request is fired to our servers to configure the SDK’s behavior. The response is cached for later access and expired on a configurable time-period.

On the next execution after a crash occurs, binary data is POST’d to our servers.


  • An RFC-4122 UUID which permits us to deduplicate crashes.
  • The timestamp of when the user launched the application and when the crash occurred.
  • The app's bundle identifier and full version number.
  • The device's operating system name and version number.
  • A boolean indicating whether the device was jailbroken/rooted.
  • The device's model name, CPU architecture, amount of RAM and disk space.
  • The uint64 instruction pointer of every frame of every currently running thread.
  • If available in the runtime, the plain-text method or function name containing each instruction pointer. Given that in iOS it is not possible to mark user RAM pages as executable, it is effectively impossible for user data to be present in your function names.
  • The uint64 value of each register on the CPU. These are pointers only - we do not collect or introspect what they point to.
  • If an exception was thrown, the plain-text class name and message value of the exception. It is your responsibility to ensure no private data is contained in these values.
  • If a fatal signal was raised, its name and integer code.
  • For each binary image loaded into the application, it's name, UUID, byte size, and the uint64 base address at which it was loaded into RAM. Again, given that in iOS it is not possible to mark user RAM pages as executable or load dynamic libraries, it is effectively impossible for user data to be present in these values.
  • A boolean indicating whether or not the app was in the background at the time it crashed.
  • An integer value indicating the rotation of the screen at the time of crash.
  • A boolean indicating whether the device's proximity sensor was triggered.
  • The device's battery level, battery velocity, physical orientation (integer), current amount of RAM used, and current amount of disk space used.
  • Crashlytics uses a variety of identifiers to provide our services including the Android ID, and the Android Advertising ID, as well as the iOS identifierForAdvertising (IDFA) if your app links against AdSupport.framework.
  • A list of names of the processes also running on the system at the time of crash.
  • Custom key-value pairs provided by the host application.
  • Whether or not to collect crashes at all for this version of your app.