0

I have custom keyboard extension app. It uses compiled library that logs a lot of connection errors but otherwise works fine (Apple's NSSpellChecker). For details see this question (JAL's answer is not working well).

Questions:

  1. What kind of problems can be caused by having a lot of production logs on the iPhone. For example can long log consume memory (keyboard extensions are limited to ~40MB)? Can it consume disk space? What other issues might I encounter? It certainly slows down the app a bit but that is no issue in my case.

  2. When I receive crash logs from Apple will they include all those spam logs from NSSpellChecker?

  3. @JAL has discovered this way how to disable logging globaly in the app - including logs coming from compiled libraries. It works but the suggested way of reenabling logging does not. If I use it to globally disable logs in my app will I still receive meaningfull crash logs from Apple? Or just empty logs?

Please feel free to answer even if you can answer just some of those questions.

Community
  • 1
  • 1
Rasto
  • 17,204
  • 47
  • 154
  • 245

1 Answers1

0

1 - NSLog() definitely has the potential do slow things down when used incorrectly. Calls to NSLog() are synchronous in order to allow errors to print to the console at a point where you can still observe the state that caused the error to occur in the first place. If you are in fact logging errors, this is perfect. If you are just printing general information to the console like ("User logged in") or ("Network response received: %@", response) you are using NSLog() incorrectly. If you decide to use NSLog() inside of an iterator or a method that runs quickly and often like drawRect or a for in loop , you will see a very dramatic performance hit.

Excessive logging, in my experience, shouldn't take up a extra space in device storage or run away with RAM as they are ephemeral and the system will purge them automatically over time.

That being said, using logs incorrectly in a release build of an app has the potential to slow things down and litter the console with garbage. Any developer who needs to subsequently debug on a device drowning in your logs will not appreciate it.

2 - The logs you receive from Apple and TestFlight will be crash reports and tend to only include information relevant to the threads / state of execution at the moment of the crash. Unless the exception is directly related somehow to an NSSpellChecker related exception, those logs shouldn't dominate your crash reports.

3 - Those methods are employing private APIs and have the potential to get you rejected from the App Store. If you want to use them for development for some reason, go ahead. You should not use them for a production build of an App. You should either silence your logs when you are not running a debug build or remove them entirely. Eliminating them with semi-documented private logging APIs could easily get you flagged by a reviewer if they pick up on its misuse.

Dare
  • 2,497
  • 1
  • 12
  • 20
  • As stated in the question I have no control over the code that is calling `NSLog`... So I cannot use it *corectly* or *incorrectly*. Somebody at Apple is already using it incorrectly and I have to deal with it - [the question](http://stackoverflow.com/q/36309812/311865) is how. – Rasto Mar 30 '16 at 13:48
  • You still do not get it... In 3. you are suggesting to *remove logs entirelly* - how do I do that if the `NSLog` statement that is doing all that logging is part of implementation of `NSChecker` which is class coded and provided by Apple?! I cannot modify compiled `UIKit` framework code... As for silencing the logs when not debug build - how can that be done? – Rasto Mar 30 '16 at 13:58
  • -1 You are answering something different than what I am asking. There are parts of your answer that are usefull (part starting with *in my experience*) but most of the rest is not relevant. *Please* read my question again, try to understand my needs and edit your question so I can remove my downvote. Thank you – Rasto Mar 30 '16 at 14:04