Log in Swift with OSLog

Tram Ho

When the need to use Log in swift, the first thing we think of is usually print and NSLog. However, Apple recently introduced a new standard for Logging when programming as unified loggin , using OSLog. This is the way Log is currently being proposed, providing an effective way to capture the information needed when coding.

Unified loggin provides some improvement over previous techniques and also some differences from what we are used to.
  1. Each message will be logged at an appropriate level, including: default, error, debug and info. Helps determine how messages are displayed and stored.
  2. Messages are grouped into subsystems and categories to allow for more efficient searching and filtering.
  3. No need to wrap Log in the conditions.
  4. User security is set high, with the necessary dynamic content strings being marked as public, the rest will not be processed in any log.

Along Log

Using unified loggin in Swift is as simple as using the os_log function, we can quickly see that StaticString is an argument instead of a regular String. The easiest way to log messages is to put String constants directly in the function. It is possible to extract the message into a property, but it still has to be a StaticString

Because using StaticString is required, instead of using a simple string, we need to formart arguments. This can be confusing when first used, however, not too difficult to use and beneficial to the privacy of users that we will discuss later. We have access to all common parameter symbols, as well as decoders.

Organize the Log

Calling to os_log can specify the OSLog to use, containing a specific subsystem and category. This information is not evaluated when filtering, searching and reading log later. When a log argument is not specified, a default argument is used, with no subsystem or category configured.

The subsystem gathers all the logs for a specific application or module, allowing us to filter what belongs to our logs. From Apple’s log evaluation, the convention for subsystems is reverse domain style, just like the Bundle Identifier of an application or framework. If the application is modularized into frameworks, this type of log is essential to distinguish.

Categories are used to log groups into relevant areas, to help us localize the scope of the message log. The convention of the category used is human-readable name like UI or User. We can group logs into layers across systems or functions, such as Network or Contacts. Or instead of the above, we can group them into classes such as the Contacts Repository. It all depends on which direction we go to understand our project the easiest.

We can add categories and subsystems as OSLog extensions, making them more accessible throughout the application. Save them in a place that avoids making them rampant to control.

Logging levels

The general log system contains a set of log layers in which messages will be displayed. The log layers control how and when the log will show up for each different environment. The log management system can be easily customized based on the command-line.

  1. Default: Summary of everything related to failure or fall-back if no floor is in charge. Unless changed, the message will be saved in memory and kept when full.
  2. Info: Summary of what is useful, but not for diagnosing and fixing errors. Unless changed, the message is not saved for long, when the memory is full it will be freed.
  3. Debug: Summary of information during development to diagnose a specific error and at debugging. This layer will not work unless config changes.
  4. Error: Summary of system errors. The message is always saved, to make sure it is not lost.
  5. Fault: Replay the system layer or multithreaded error, usually the fault is not caused by our application. Like the Error layer, messages are always saved.
The specification of the log layers using OSLogType is an os_log parameter

User privacy

To ensure that user information is tightly secured in the application’s log system, the unified log system has a parameter that distinguishes public and private. By default, only scalar (boolean, integer) is aggregated and dynamic strings or complex dynamic objects are recorded. If necessary, dynamic string parameters can be specified as public and scalar parameters can be specified as private.

Avoid making public arguments because it can easily expose information via device log.

Reading logs

During debugging, the message log will be displayed in Xcode. But the best way to read logs is in the MacOS console. Here we will sort, loc and search logs, along with viewing them easier.

  • Display logs in tables, read data more easily
  • Search and filter by subsystem and category
  • Display or hide fields for each message log
  • Disable or debug cascading debug and infor
  • Save the search structure to find again in the future easier.
Reference source: https://medium.com/swift-programming/clear-and-searchable-logging-in-swift-with-oslog-eadc97b1a9b8
Share the news now

Source : Viblo