Could somebody go over how to exempt NSLog's from a release build of an app? Also, does it matter if comments are left in a release version? Thanks!
-
1Possible duplicate of http://stackoverflow.com/questions/9063100/xcode-ios-how-to-determine-whether-code-is-running-in-debug-release-build – He Shiming Apr 09 '12 at 02:18
-
1Most everyone creates their own DebugLog macro or some such, conditioned off of a debug flag. While you're at it you can automatically insert a `%s` of `__PRETTY_FUNCTION__` to list where the log comes from. – Hot Licks Apr 09 '12 at 02:20
-
This post is tagged iPhone. Why do you care if your code is writing to the console? Nobody's going to see it. – Michael Dorst Apr 09 '12 at 02:26
-
1Michael - it slows down an app to have log unnecessarily, even on iPhone. While you cannot see the log, it still exists in the device itself. – johnbakers Apr 09 '12 at 02:31
4 Answers
Use a macro like DLog
to wrap NSLog
, and turn it off in Release builds.
#ifdef DEBUG
# define DLog(...) NSLog(__VA_ARGS__)
#else
# define DLog(...) /* */
#endif
Comments absolutely don't matter. They are only in your source code, not the compiled output. You don't submit your source code to Apple, only the built copy of your app.

- 27,695
- 5
- 68
- 74
-
The only problem I see with this is that you can't apply it retroactively to an app that has a lot of NSLogs already. – EmilioPelaez Apr 09 '12 at 03:08
-
2True, but search and replace works fine. Or, if you follow the link, it shows how to run a `sed` command in Terminal to do the same thing. – Kurt Revis Apr 09 '12 at 03:15
What I do to exclude NSLogs is to add this to the prefix file:
#define NSLog(...)
That way, when compiled, all NSLogs will be replaced with nothing, it will be like an empty line.
As for the comments, they never make it into the binary at all, those are ONLY for whoever can see the source code.

- 18,758
- 6
- 46
- 50
-
-
But sometimes you want a few NSLogs to be present in the released code. Better to define a new macro for a debug log function. – Hot Licks Apr 09 '12 at 03:49
-
If you just want to remove all logs from the release version, this works as is, and you can just comment it when you want logs to show. – EmilioPelaez Apr 09 '12 at 04:38
-
2The "define NSLog(...)" approach is very clever, but not as desirable as the "define DLog(...) NSLog (__VA_ARGS__) approach posted earlier. Why? Because a programmer unaware of your clever define will see "NSLog" calls in the code and wonder why they're not working, or possibly remove them for performance reasons. It's almost always a bad idea to redefine the semantics of a known identifier as opposed to introducing a new identifier. Readability is very important. – Stan Sieler Aug 09 '12 at 17:27
-
@StanSieler very valid point. I've been using this method on projects I work by myself only, because it's a really quick fix, and I'm already used to it, but I guess it wouldn't be appropriate to do it in larger projects with a team. – EmilioPelaez Sep 04 '12 at 08:49
-
I am a victim of this trick! Its really better to use a custom debug macro, that way other developers who will use your code will easily know there was a trick involved. For me, I've look into 2 more things before I found out there was a redefinition of NSLog: (1) if Xcode automatically turns off NSLog for release and (2) iPhoneConfigUtility has an update that prevents it from displaying logs for live apps – schystz Mar 10 '14 at 09:10
The newer versions of the Xcode projects usually include a macro definition DEBUG
when building for a debugging version, so the easiest way would be to go for:
#ifdef DEBUG
NSLog(@"Safe and sound ...");
#endif
It doesn't really matter though, in my experience sometimes you don't want the console to be vomiting a bunch of logs, you probably only need them at certain occasions.

- 3,345
- 1
- 21
- 40