At the WWDC 2020, Apple introduced the new Swift logging API for iOS 14. This post summarizes how to take advantage of this new API to debug behavior in your iOS apps.
When it comes to logging messages in iOS applications, the APIs that first come to your mind might be print or NSLog. Or maybe you are using a third party library like CocoaLumberjack or SwiftyBeaver.
However, already with iOS 10, Apple introduced a new iOS standard for logging with OSLog, providing an efficient way to log information.
At this year's WWDC 2020, this API became - you could say - more Swifty like. It offers different logging levels, categories, persistence, formatting, high performance and privacy features. It's worthwile checking it out.
Let's take a look at an example.
let logger = Logger(subsystem: "com.tanaschita.funapp", category: "funnyanimals")
let videoName = "The turtle"
logger.log("Starting video with title \(videoName, privacy: .public)")
The subsystem parameter is typically the bundle identifier of your app. The category parameter can be used to structure logs from different parts of the app. You can log any type confirming to CustomStringConvertable.
The log outputs appear in Xcode's console while running the app. You can also use the Console.app from the Utilities folder on your Mac when your device is connected.
The API provides five log levels:
The Logger instance provides appropriate methods for this levels like debug, info etc. So for example to log an API error in your app you could do the following:
logger.error("Missing field \(field) in response from \(endpoint).")
Logs are archived to retrieve them later from the device. To browse through persisted messages from your device, connect the device to your Mac and open Console.app that is preinstalled on your Mac in the Utilities folder.
Only logs that are persisted can be retrieved after execution. Whether or not a log message is persisted depends on the log level. The Notice, Error and Fault messages are persisted.
According to Apple, the logging system is very performant, so you can use it widely in your app without slowing it down. Unlike with print, log messages are not fully converted into a string representation. Instead, the compiler and the logging library work together to produce an optimized representation of the log message.
Nonnumeric values in your logs are configured as private by default, so they are hidden in the message. This makes sure, that after shipping your app, the logs do not show any personal information. So when using:
logger.log("Logging in user with email \(emailAddress)")
The statement above will produce the following log message:
Loggingin user with email <private>
If the information you are logging should not be hidden, you have to explicitly mark it as public:
logger.log("Opening funny video \(videoId, privacy: .public)")
One thing I'm personally missing when comparing the API with the mentioned third party libraries, is the ability to retrieve all messages from the Logger instance, for example to be able to show the logs directly within the application.
Nontheless, the new API is a promising and powerful logging solution.