Printing to the Console

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

In this section, you’ll learn two ways your app can send messages about how it’s running. When using breakpoints, you have to stop your app to inspect things and then restart it. But sometimes, you want the app to leave little messages you can look at later if you’re trying to troubleshoot. You want logging.

Two log destinations are available to you when you’re developing. There’s the Xcode log and the system log. So far, in this lesson and in your prior lessons that used Playgrounds, you’ve seen the Xcode log. You’ve written to the log by putting either print or dump commands in your code.

print("This will get written to the console log.")
print("So will this, and the value of \(thisVariable)")

dump(anArray)

If you put these commands in your code, when Xcode executes them, the message writes to the console log. You can watch the messages in real time or open the Report navigator in Xcode to see older ones. Every time you build and run your code in Xcode, a new log is created.

Using print and dump are quick ways to leave yourself messages when you’re writing your code so that you can monitor what the app is doing without making it pause. For simple apps or temporary messages, they work pretty well.

However, they have drawbacks that become obvious as apps get more complicated. First, they need to be on the main thread to work correctly. For example, if you have a print or dump inside some network code that works in the background, it’ll likely output at odd times or not at all.

Also, print and dump use system interrupts to print to the console. If you’ve got some code where execution timing is critical, a print can throw the timing off.

Finally, print can leak sensitive information into the logs, like API keys or user passwords, so removing all of them before you deploy your app to the App Store is essential.

Unified Logging

Because of the shortcomings of print, especially around leaking sensitive information and multi-threaded apps, Apple introduced a new logging framework a few years ago in iOS 14.

import OSLog

let movementLogger = Logger(subsystem: "com.example.bragbookapp", category: "movement")
let imageLogger = Logger(subsystem: "com.example.bragbookapp", category: "images")

movementLogger.log("backward button clicked")

imageLogger.log("\(dogImages[currentImage])")

imageLogger.error("The image caused an error \(dogImages[currentImage])")
The Console app shows your Mac, other Apple devices, and any running simulators.
Vte Yicgufa anw zbeml duiy Saz, ekqux Oxdsa fohuyow, emk esl kavlivv belefesopr.

Control the flow of messages in the console using its buttons. You can also search and filter.
Zopptap hgo ylaq ev nebyelem os bhi wekmovu omujm urn wabviwg. Fea vuh icqo teemgb uxg yilzuf.

subsystem: com.example.bragbookapp

imageLogger.log("This string is ok to show \(dogImages[currentImage], privacy: .public)")
imageLogger.log("This string should be hashed so I can look for other occurences of it \(aString, privacy: .sensitive)")

movementLogger.log("Employee salary \(aSalary, privacy: .private)")
See forum comments
Download course materials from Github
Previous: Breakpoints Demo Next: Logging Demo