I looked online for help on how to disable OS_Log in Release, but it looks like the environment variable OS_ACTIVITY_MODE is only transient and present for Xcode environments (not for Apps downloaded from the App Store).
Is there a recommended practice for disabling all OS_Log logs in Release without resorting to preprocessor directives like #if RELEASE?
Thanks in advance
Our general advice is that you not remove your logging in release builds. The unified logging calls have very low overhead when they’re not enabled, and thus it’s fine to leave them in place in your shipping product. Additionally, on macOS at least, this gives you the ability to re-enable logging in the field using logging configuration profiles; see the os_log(5) man page.
Share and Enjoy
Quinn “The Eskimo!” @ DTS @ Apple
Great thanks for sharing Quinn. I guess these iOS logs can't be viewed by an end-user correct? I am just asking for security reasons since we do a lot of os logging and NSLogs as well.
I guess these iOS logs can't be viewed by an end-user correct?
Yes. Users can view these logs by connecting their iOS device to their Mac and then running Console. This can also end up in sysdiagnose logs.
I am just asking for security reasons
You definitely need to be careful there. Unified logging has a standard mechanism for redacting potentially sensitive data (see the discussion of %{public} and %{public} in the os_log man page) but you still don’t want to be logging passwords and so on.
Share and Enjoy
Quinn “The Eskimo!” @ DTS @ Apple
Thanks Quinn, I am thinking of trying out a service like SwiftyBeaver instead of print statements and NSLog. Is lots of logging generally a good thing as long as sensitive info is redacted? It would be cheaper for me to reduce the number of logs, but I don't know if that's a good idea for debugging user issues.
Thanks again for your help.
[I’m unfamiliar with the landscape of third-party offerings here, so I’m going to limit myself to commenting on Apple stuff.]
Is lots of logging generally a good thing as long as sensitive info is
redacted?
Yes, and no (-:
As with most things it’s a balancing act. My experience is that well-positioned logging is vital for investigating issues that only appear in the field (and helping developers debug such issues is an significant part of my job). However, there are drawbacks to too much logging:
Privacy — The unified logging system gives you the tools to handle this, you just have to use them correctly.
Size of the compiled binary — This one is pretty obvious. All code to log and the log messages themselves will increase the size of your binary.
Overwhelming the logging system — The unified logging system is pretty good about protecting itself from apps that log too much but it’s still possible to see negative effects. The most common of these is that a particularly ‘loggy’ app might push other, more useful, log events out of the system log.
The most important thing to get right is the log level. By default on iOS log entries at .info and below will be suppressed at the point of log generation, so the only real negative with those is the binary size. If you log at .default or higher, you need to be careful about not logging too much. My general advice is that you look at each of these higher-level log entries to make sure they contain info that might potentially useful while debugging.
Finally, make sure set the subsystem and category. The unified logging system processes a lot of log entries and the subsystem and category make it much easier for you to focus on specific problems.
Share and Enjoy
Quinn “The Eskimo!” @ DTS @ Apple
Amazing answer as always @eskimo! Thanks so much. 