Introducing a new logging system

We design a new logging system for our SDK which is capable of logging to the console and also save log files locally in the application document directory.



Those logs can help you understand what is going on inside our SDK and also used for debugging in case of issues and bugs.

Before we dive into the logger and the available options, you should note that we do not use those logs for anything else except improving our SDK and making it a better and more stable product for our partners.



As of today, those log files, if enabled, are not being sent to our BE. 
In case of rare issues which cannot be reproduce easily, you as a developer, will have the ability to manually send those logs to our customer success so we can have better insight about what the issue might be.



We will work on an option to automatically send those logs to us, with your approval of course.

Logger available options

So let’s start by lookin on some enums:

SPLogLevel

SPLogMethod

Now after you are familiar with the related enums of the logger, let’s see some examples of the result each method will produce.

NSLog

The good old NSLog which probably every iOS engineer is familiar with.

Xcode debugger console

Device logs

OSLog

The new recommended way of logging by Apple.

Xcode debugger console

Device logs

Files

This option will produce log files inside the documents directory inside your application.

So just by looking on file(maxFilesNumber: Int), it’s obvious that maxFilesNumber define the maximum amount of logs which will be created.

maxFilesNumber allowed range is 1-200. Passing a value which is not in the range will result in a fallback to the defualt number which is 20.

After exceeding this number, the logger will automatically remove the older log file when creating a new logger file.

The logger will create a file in either of the following conditions:

• We have 100 of items to log
• Application moved to background

We define items here as each message we internally log.
This means an item might be a simple line or full information about a network request for example.
Obviously different log levels will effect the data each item will contain and whether this item will be logged at all.

From our internal testing, when using SPLogLevel .verbose, each file won’t exceed 1.5MB.

The above is the worst case. A user can enter the background before and this will result in only a few KB log file.

Let’s see examples inside a simulator directory:

Which log level to choose

Using .error will log only errors.
Using .medium will log general info and errors
.
Using .verbose will log all available information and will obviously include the previous two.


It’s up to you to decide.

Which log method to choose

This sounds really great so far!

I can see the potential here, but which method should I choose as an engineer?



We saved you the hassle, you can use all 3 available options if you would like.
However we recommend using .files and either .nsLog or .osLog methods.
By default we are using [.nsLog, file(maxFilesNumber: 20)].

What about performance

We glad you asked, so everything related to the logger is being done in a background queue with priority of .utility and the label of the queue is OpenWebSDKLoggerQueue.
You can actually see this when stopping the debugger on a breakpoint and examine the existing queues.



The files are actually created on a different queue with a priority even lower of .background and label OpenWebSDKLoggerFileCreationQueue.

How can I configure the log level and methods

You can easily configure the logger, just call:
SpotIm.configureLogger(logLevel: SPLogLevel, logMethods: [SPLogMethod])

By defualt we are initializing the logger with methods [.nsLog, .file(maxFilesNumber: 20)] and log level .verbose.

The only thing to take in mind, is that when you configure the logger, we disregard any pending logs if any, so for them a file won’t be created.


So if you are configure the logger, do it after the initialization method so you won’t lose logs.

How can I cancel this awesome feature?

We really sorry to hear that, we do think it will greatly improve the SDK with your help and within some time.
At least consider using it in your own debug environment.
If you still want to cancel it, just call SpotIm.configureLogger(logLevel: .none , logMethods: []).

Conclusion

By now you have enough information about what this logging system is capable of doing.
Thank you for reading so far, we hope this logger will help us to create a more stability and a better product for you.