Logging has always played a very vital role in all kinds of programming platforms and languages. In objective C the most commonly used method of logging is, as we all are quite well aware of, NSLog(). Though it may seem a little naive for experienced developers to see the usage of NSLog again, but for the new comers I would mention it shortly. However, human beings are curious creatures and never have settled down with anything. So, there are better ways of logging than NSLog. Let us see what these logging mechanisms are:
The NSLog, though being memory heavy, is the most commonly used mechanism for logging. The syntax is as follows:
NSLog(@”%@”, @”message goes here”);
NSLog(@”The %d iteration of this loop provides data: %@”, iteration, data);
Conditional NSLog for Debugging Purpose
Despite of its simplistic nature, NSLog adds memory overhead and is not at all recommended to be kept in release mode of applications. This is not only because of the associated memory load and leak issues, but also due to the most common error of accidentally leaking proprietary and sensitive data to unauthorized users. But we can not simply live without NSLog (we can, but more on that later). Hence the ideal condition would be to enable NSLog when application is in “debug” mode and switch it off when application is released i.e. in “release” mode. To achieve this the best way is the following:
Step 1: Add the following code to the Appname_prefix.pch file
# define DLog(…) NSLog(__VA_ARGS__)
# define DLog(…) /* */
#define ALog(…) NSLog(__VA_ARGS__)
Step 2: Go to “Schema” and set the current schema to Debug
Step 3: In the build configuration “Other C Flags” key add –DDEBUG
That’s all. Now, when you are building the application and need to log anything which you only want to display in debug mode, use DLog(). When the application will be run in “release” mode, the DLog will print nothing. Also if you need anything to be printed irrespective of the configuration, use ALog in this case. The syntax for DLog and ALog would be exactly as NSLog().
Pro Tip: An unexplored horizon – Apple System Logs (ASL)
In most of the cases when the application is launched in the App Store and users are using the app, and unfortunately, the application crashes, there is no way to receive this kind of information without a lot of effort. A few days back, it was impossibly difficult to get access to the crash logs, warning logs etc. However, recently Apple has enabled the “Apple System Log” (ASL) which was there in OS X, in iOS also. Accessing the ASL, now we can get all 7 levels of logs and can easily post them to any server and set up a automatic logger system like Crittercism (however, Crittercism does it too elegantly).
ASL is a low level C API used to access the Apple Server Logs and use them in applications. Here is a quote from the manual page:
The new API allows client applications to create flexible, structured messages and send them to the syslogd server, where they may undergo additional processing. Messages received by the server are saved in a data store (subject to input filtering constraints). This API permits clients to create queries and search the message data store for matching messages.
More details on ASL can be found in the following links: