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.
import os
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:
Debug
Info
Notice
(default)Error
Fault
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:
Logging in 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.