Should I remove NSLogs when releasing my App

Question

Is it advisable to do any NSLogging in a shipping app? I know that I should not in heavily used loops. Or not log too verbosely. But I am not sure if it is a good practice to do so.

Removing all the NSLogs prior to a release does not seem like a good practice too.

Athenaathenaeum

Answer 1

I think it is a good practice to not spam the user's device log.

For this, I have a macro, DebugLog, that is only active for debugging builds:

#ifdef DEBUG
#define DebugLog(fmt, ...) NSLog(fmt, __VA_ARGS__)
#else
#define DebugLog(fmt, ...)
#endif

For all log messages that are interesting to me for development, I use DebugLog. For all error messages that should be logged I use unconditional NSLog. This way the distribution builds don't clutter the user's console log. Only important messages get logged.

Chanell

Exactly. Moreover, the system log on iOS devices is ridiculously short-lived, so in real life it's just useless. NSLog() in iOS is just a local debug tool. – Relinquish

Answer 2

This is one of those coding philosophy questions, but in my production apps I use asl and configure it to be off by default, but leave the option (via an entry in Info.plist) to enable various levels of logging. I tend to agree with you that too many NSLogs in a shipping app looks bad.

North

Still NSLog should't be a way to troubleshot an app in production. There are several tools for reporting errors and crashes such as NewRelic and some other many that are even free to use. – Breccia

Answer 3

Logging is always important when there is a particular support team is present to support that live application, in that case they can check what happens and they can fix the issue if some thing not related to code and if it's a core code issue then they can pass to Dev team.

But if application is something like Game , then log doesn't matter. You can remove those before releasing the app.

Ermaermanno

Answer 4

It depends. If you are not using a crash reporting facility in your application, it is generally a good idea to keep some NSLog statements that log critical errors, so that a knowledgeable user might report them back to you and help you fix the issues with the app after release. It is definitely not a good idea to have too many esoteric debug NSLog calls in your release.

Floaty

Answer 5

If you want your NSLog to work only when your are debugging and you don't want to do any changes to your code the best approach is to do this on your .pch file:

#ifndef DEBUG
#define NSLog(x...)
#endif

EXPLANATION AND TROUBLESHOOTING:

This means that if DEBUG is not defined it will "override" all NSLogs to do nothing, this string replace takes place before compiling so no NSLog in the whole code will escape, no NSLog will be left on production by mistake, this eliminates the human error of forgetting to remove NSLogs on production apps.

DEBUG is normally defined in debug mode by default in all Xcode projects. you can find out if it is defined at:

Build Settings -> 
Apple LLV #.# - Preprocessing -> 
Preprocessor Macros -> Debug

if it is not there add

DEBUG=1

also if you don't have a pch file or is not wired up here's what you got to do (because it was automatically added in xcode 5 but is no longer added in xcode 6 and up by default on the new project templates)

Why isn't ProjectName-Prefix.pch created automatically in Xcode 6?

Breccia

This is perfect when working with other developers because normally everyone uses NSLog, and if you want to define another macro such as "DebugLog()" developers can forget to use it and therefore shipping an app with log printing out. This eliminates human error. – Breccia