Mar 06

A simple method to debug your iPhone application code is to use NSLog() statements at strategic points. I often find myself printing out the response from server calls using NSLog. Even after the iPhone client development is done, these log statements can be useful to debug server issues. But you obviously don’t want to fill the console log in your released code.

To skip lines of code you don’t want to include in the release build you can use a preprocessor instruction:

#ifdef DEBUG
NSLog(@"Server Response: %@", response);
#endif

Unfortunately Xcode does not automagically define DEBUG when you do a debug build. So you have to add a definition to your project target.

1. Be sure you select Debug in the Configuration drop down.

2. Select Settings Defined at This Level in the second drop down to reduce the number of fields shown.

3. Now click the tool button in the bottom left corner and select Add User-Defined Setting from the menu.

4. Enter the following name value pair:
OTHER_CFLAGS    -DDEBUG=1

Now when you build and run in debug configuration you will see the log messages, but those lines of code will not be included in your release builds.

Update: Use GCC_PREPROCESSOR_DEFINITIONS instead of OTHER_CFLAGS. See comments below.

Update 2: See this post for a vastly improved method: The Evolution of a Replacement for NSLog

Update 3: See this post if you’re working with an SDK 3.0 project: How To Add DEBUG Flag In A 3.0 Project In Xcode

written by Nick \\ tags:

10 Responses to “How To Create Conditional Log Statements in Xcode”

  1. iPhoneKicks.com Says:

    How To Create Conditional Log Statements in Xcode…

    You’ve been kicked (a good thing) – Trackback from iPhoneKicks.com – iPhone SDK links, community driven…

  2. Richard Parker Says:

    The GCC_PREPROCESSOR_DEFINITIONS and GCC_PREPROCESSOR_DEFINITIONS_NOT_USED_IN_PRECOMPS build settings are a better choice than OTHER_CFLAGS.

    All of these build settings are documented in:
    http://developer.apple.com/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/Xcode_Build_Settings.pdf

  3. Nick Says:

    @Richard: There are so many ways to accomplish almost the same thing in Xcode… I used OTHER_CFLAGS based on Apple’s Technical Q&A QA1431.

    After reading the Xcode Build Settings document carefully, I realize that GCC_PREPROCESSOR_DEFINITIONS is a more specific way to define DEBUG, and is therefore preferred. Thanks for the tip!

  4. Huy Says:

    If you’re going to use GCC_PREPROCESSOR_DEFINITIONS instead of OTHER_CFLAGS,
    make sure to use the form “DEBUG=1” instead of “-DDEBUG=1”

  5. Ben Says:

    Thanks Nick! Two questions:
    1) will GCC_PREPROCESSOR_DEFINITIONS work with LLVM, if not is there an equivalent?
    2) OTHER_CFLAGS seems to work just fine for this, is there a reason why you wouldn’t use it?
    Thanks.

  6. Nick Says:

    @Ben: In my limited testing GCC_PREPROCESSOR_DEFINITIONS does seem to work with LLVM. Since the setting is specifically directed at the preprocessor that seems to be the more appropriate setting to use, per Apple’s document linked above. But there’s nothing wrong with using OTHER_CFLAGS.

  7. bob Says:

    Symbols are either defined or not defined

    -DDEBUG is correct.

  8. How To Add DEBUG Flag In A 3.0 Project In Xcode | iPhone Development Blog Says:

    […] this post How To Create Conditional Log Statements in Xcode I described how you could add a DEBUG flag to your Xcode project setting so that you could use […]

  9. mmw Says:

    please, when rewriting stuff make the effort to give a complete and useful example.

    #ifdef DEBUG
    #undef MYLIB_DEBUG
    #define MYLIB_DEBUG 1
    #endif

    #ifndef MYLIB_LOG
    #ifdef MYLIB_DEBUG
    #ifdef __OBJC__
    #define MYLIB_LOG(…) NSLog(__VA_ARGS__)
    #else
    #define MYLIB_LOG(…) fprintf(stderr, __VA_ARGS__)
    #endif
    #else
    #define MYLIB_LOG(…)
    #endif
    #endif

  10. Hubert Kunnemeyer Says:

    Saves me from pulling my hair out when trying to read the debugger console output with all the date,time and other crap that I never need. This solution works great when struggling with calculations especially when all you want is a simple number or flag as output. Plus not having to worry about removing all of the NSLog()’s for release builds is awesome. Thanks for the tips!

Leave a Reply