It's easy to "disable" NSLog at compile time by replacing it with a macro, etc.
Can NSLog (or ASL in general) be disabled at runtime?
My goal is to silence some logs that I do not have control over.
Look at the Lumberjack Framework. There you can set the logging level as required. To hide certain log statements when you release the app, just change the logging level from say DEBUG to INFO using #ifdef RELEASE and #ifdef DEBUG macros.
Update:
In case the log statements are coming from a different framework that you are linking, you can use something like Method Swizzling to swap the implementation of NSlog with your custom method.
Related
Is there any way to completely remove logs from a final release build of an application written in Swift? By completely I mean that if I open the compiled binary file in a text/hex editor there should be no logged strings in it and if someone disassembles the binary file also he should not see any logged strings in a disassembler.
I know that I can disable writing the logs to the console in release build with #if DEBUG for example with something like this:
func log(_ message: String) {
#if DEBUG
print(message)
#endif
}
But when using this approach logged strings are still visible in compiled binary (and could for example help someone in analysing disassembled code of the application). They are just not printed on the console and that is not acceptable for me. I want to remove them completely from compiled binary. In Objective-C we could use preprocesor macros to achieve that but they are not available in Swift. I could put #if DEBUG before each occurrence of log/print function in the code and that would work but obviously this is not a great solution as it would require to add this #if DEBUG in hundreds of places. Alternatively I could just do find and replace to comment all print/log calls before building a release build but this is also not a great solution as I would need to comment and uncomment those logs each time I build the release version. Is there any better way to achieve that?
You could try using the the Logger framework provided by Apple
It is more performant that print statements, and you have more control over what is logged - for developing and debugging you can use the debug log level. There are other logging levels that generate messages during run time with privacy options.
There is a WWDC Video which you may find useful to introduce you to this.
This looked promising but doesn't seem like a duplicate question as it addresses issues in Swift.
I am finalising an existing Objective C project but NSLog disappeared when I updated to Xcode 9. So I'm looking for some setting in Xcode that lets me continue using NSLog to fine tune the project.
Basic debugging using logging for Swift and Objective-C apps appears to have changed in Xcode 9 as NSLog messages no longer appear in the Debug area. The window where DEBUG=1 is set no longer looks like Figure 2 The DEBUG preprocessor macro setting in an Xcode project.
As an example, I want to display this string message in the Debug area using Xcode9.
NSString *outputData = #"This should show in Debug area";
NSLog( #"text: %#", outputData );
I studied the latest documentation here or here but so far that has not helped. It may also be worth noting that previously the Debug area would open automatically when I ran the project. Since installing Xcode9 it no longer does that.
Hopefully the extra information provided in the edits below will suggest to someone where I have yet to look. Thanks.
EDIT 1
In the Console area - i.e. the bottom right part of the Debug area - I had All Output selected. So I tried using Debugger output and Target output but there was still no log.
I added these statements in the Prefix.pch file
#ifndef DEBUG
#define NSLog(...) /* suppress NSLog when in release mode
#endif
When I ran the code the following appeared in the Issue Navigator.
Unused variable 'outputData'
EDIT 2
There seems to be a different place to set DEBUG=1 in Xcode9 (see below).
I inserted a DEBUG macro into the .pch file using the examples suggested in several SO posts here, here, here (all quite old) and even here (making sure to change MyLog back to NSLog). And in each case I was able to report the same issue in the Issue navigator but never in the Debug console. A similar problem (with Xcode5) was solved here by copying over the files into a new project but I want to avoid this.
My app which was almost finished has so far not had to deal with any of the complex issues that unified logging seeks to address. But I watched the 2016 WWDC video on unified logging and read through its slide show files searching for an example of how to use the appropriate API to do something as basic - print NSLog live to the console area - the way I did before installing Xcode9. This may be the wrong approach. But I can’t think of a better way to proceed.
EDIT 3
It's worth noting that when I created a new Objective C project using Xcode9 and ran the above code, the string message appeared in the Console area.
In other words, using Xcode9 the new logging API does work with NSLog, but only for a new project and not for one created using an earlier version of Xcode.
Enable DEBUG preprocessor macro
Rather than writing your debug statement into code, you might try dropping in a breakpoint, right clicking on it, and selecting "Edit Breakpoint". You should see this menu:
From there, you'll click "Edit Breakpoint" and you're presented with this:
From there, you can click "Action" and you'll see this menu:
You can enter print messages (ex: myMethodCalled) or variable values (myIntValue = #myIntValue#), or you can type debugger commands to execute at that spot in the code (ex: po dump(myArray)).
The downside of this approach is the breakpoints aren't always "sticky" to the line of code you originally drop it in on.
Try this. Navigate to:
Product -> Scheme -> Edit Scheme -> Run -> Arguments -> Environment Variables
in Xcode.
Add OS_ACTIVITY_MODE and set the value to disable or leave it empty.
Make sure it is checked!
Hope this helps
A Debug log was enabled in the Console area of Xcode9 after replacing these definitions in the preCompile header
#ifndef DEBUG
#define NSLog(...) /* suppress NSLog when in release mode */
#endif
with the following
#ifdef __DEBUG__
#define NSLog(...) /* suppress NSLog when in release mode */
#endif
Environment Variables for Arguments were set according to the answer above with an additional setting for Options. Someone more familiar with the unified logging API might explain the particular options but I'm satisfied I have a working solution.
Arguments
Options
When developing iOS apps using XCode, you can use NSLog calls to write information to the console for debugging. In Xamarin.iOS, the same can be done with Console.WriteLine.
When running a release build of an app, without the debugger attached, these calls serve no purpose. So I've thought of excluding them with pre-processor directives:
#if DEBUG
Console.WriteLine("foo");
#endif
So that the calls don't even exist in the release build. I appreciate this may be micro-optimisation - but I'm curious if Xamairn already does this, making this unnecessary?
Console output is not removed in iOS release builds.
FYI: Xcode does not "automatically" remove NSLog or print from Obj-C/Swift "release" code either. (You typically define a single global preprocessor macro to remove them all, if desired...)
Your options are many... including:
DEBUG preprocessor as you show in your question.
Use System.Diagnostic.Debug.WriteLine:
Any calls to Debug.* will be removed by the compiler due to the [Conditional("DEBUG")] attribute being applied.
Create your own "Logger" class as a wrapper to the stdout writers and [Conditional("DEBUG")] it
Use Fody and re-weave the assemblies to remove/NOP/redirect the WriteLine
I do this to redirect the calls to in internal log and upon crash or user stat requests, forward this log to our crash reporting servers.
etc, .....
Ref: Xamarin's NSLogWriter Helper Class
I am currently making an application using swift where I am using some debug code.
Here is my logic:
//Do some code that always gets executed
if self.debug
{
//Do some debugging code
}
//Do more code that always gets executed
When I put this for release, should I remove the debug code or could I just set self.debug to false?
I have looked at this question: Should debugging code be left in place?, however that sounds like it's to give the user choice if they want to debug the application or not, with iOS applications users cannot debug it unless they have the Xcode project.
Preprocessor directives are a more preferable way of marking code that should only be compiled for debug builds.
#if DEBUG
// Do debug things
#endif
By using preprocessor directives, the code that you put in that block doesn't get compiled into release builds.
Recently I enabled /W4 warnings (MSVC) to clean up a bit in my project and noticed that GLM uses non-standard compiler extension guarded by #define GLM_HAS_ANONYMOUS_UNION, that causes a very long warning spew.
There seems to be compiler feature detection mechanism, but I can't disable compiler extensions entirely because of Windows SDK dependencies and the /Za is discouraged as buggy anyway. So what is the proper way to disable that particular thing in GLM?
I could slap an #undef everywhere i use GLM but is there a "proper" place to configure these things, like a separate config file or something? I'm upgrading GLM from time to time so I wouldn't want to modify that define in the GLM's code.
I ran into the same problem as you.
GLM will try to use all capabilities of your compiler and if it detects VS it will use nonstandard extensions in order to do some fancy things.
If you want these non-standard things to go away (e.g. nameless unions/structs)
you can switch GLM into standard mode by using
#define GLM_FORCE_CXX11
just before you include any glm header.
I plugged this info from the manual at:
http://glm.g-truc.net/0.9.7/glm-0.9.7.pdf
Alternatively you can look into disabling this very specific warning via pragma warning push
#pragma warning(push)
#pragma warning(disable:4201) // suppress even more warnings about nameless structs
#include<glm/glm.hpp>
#pragma warning pop
more info at https://msdn.microsoft.com/en-us/library/aa273936(v=vs.60).aspx