At times, even full stack traces with line numbers aren't quite enough to pinpoint the bug. To give you even more insight, Crashlytics provides 3 logging mechanisms right out of the box, Custom Logging, Custom Keys, and User Information.
CLS_LOG, you can leave bread crumbs in your code
in the form of logged messages that will give you insight into what is
going on in your app leading up to a crash. These
messages are associated with your crash data and are visible in the
Crashlytics dashboard if you look at the specific crash itself.
CLS_LOG to help pinpoint issues. It automatically includes information about the Objective-C class, method and line number where the log line came from.
CLS_LOG(format, ...) is the recommended way to add custom logging to your app.
- In Debug builds,
CLS_LOGpasses through to
NSLogso you can see the output in Xcode and on the device or simulator.
- In Release builds, however,
CLS_LOGsilences all other output, resulting in logging that is about 10X faster than
CLS_LOG(@"Higgs-Boson detected! Bailing out... %@", attributesDict);
Crashlytics/Crashlytics.hheader file for more details.
For more control, you can directly leverage
CLSLog(format, ...) and
CLSNSLog(format, ...). The latter passes through to NSLog so you can see the output in Xcode or on the device or simulator.
CLSLog(format, ...) and CLSNSLog(format, ...) are thread safe.