Using os_log to log function arguments, or other dynamic data

See Logging:

Formatting Log Messages

To format a log message, use a standard NSString or printf format string, ...

and String Format Specifiers for the standard format string specifiers, such as %@ and %d.

In your case:

os_log("foo: %@ %@", log: .default, type: .debug, x, y.description)

The format string is restricted to static strings to prevent (unintentional) expansion of format string specifiers. Here is an example demonstrating the problem, using NSLog() because that does not restrict the format to constant strings:

let s = "50%"
NSLog("\(s)percent")
// Output: 500x0ercent

The %p expects a pointer on the variable argument list, which is not provided. This is undefined behavior, it can lead to crashes or unexpected output.

In Xcode 12 / Swift 5.3 / iOS 14, you don't have to call os_log directly at all. Instead, replace your use of the OSLog class with the new Logger class (available when you import os). Here's an example:

let myLog = Logger(subsystem: "testing", category: "exploring")

You can then call a method directly on your Logger object to log with that subsystem and category:

myLog.log("logging at \(#function)")

To log at a level other than the default, use that level as the name of the method:

myLog.debug("logging at \(#function)")

In the message string, as you can see, Swift string interpolation is legal. It is allowed for Int, Double, Objective-C objects with a description, and Swift objects that conform to CustomStringConvertible.

The legality of Swift string interpolation here is surprising, because the point of os_log format specifiers is to postpone evaluation of the arguments, pushing it out of your app (so that your app is not slowed down by logging) and into the logging mechanism itself. Well, surprise! Thanks to the custom Swift string interpolation hooks that were introduced in Swift 5, the interpolation is postponed.

And the use of custom string interpolation has two further benefits here. First, the custom string interpolation mechanism allows an interpolation to be accompanied by additional parameters specifying its behavior. That's how you prevent a value from being redacted:

myLog.log("logging at \(#function, privacy: .public)")

You can also use additional parameters to perform various sorts of string formatting that you would otherwise have had to perform using NSLog format specifiers, such as dictating the number of digits after the decimal point and other sorts of padding and alignment:

myLog.log("the number is \(i, format: .decimal(minDigits: 5))") // e.g. 00001

So you'll never need to call os_log directly again, and you won't have to use the NSLog-type format specifiers any more.

---

OLD ANSWER FOR iOS 13 AND BEFORE:

Two points expanding on Martin R's answer:

os_log("foo: %@ %@", log: .default, type: .debug, x, y.description)

You can omit the type: parameter, but you cannot omit the log: parameter; you must have it, including the log: label, or os_log will misinterpret your intentions.

Also, the log: value does not have to be .default. It is usual to create one or more OSLog objects up front, to use as the argument to the log: parameter. The advantage here is that you get to specify the Subsystem and Category for the OSLog object, and these in turn permit you to filter on the results, in the Xcode console or the Console application.

---

Also, with regard to pkamb's answer, if we know our message is always going to be a string, we can write the OSLog extension like this (taking advantage of the new Swift 5.2 callAsFunction method):

extension OSLog {
    func callAsFunction(_ s: String) {
        os_log("%{public}s", log: self, s)
    }
}

The result is that we can now treat our OSLog object myLog itself as a function:

myLog("The main view's bounds are \(self.view.bounds)")

That's nice because it's as simple as a basic print statement. I appreciate that the WWDC 2016 warns against that sort of preformatting, but if it's what you were already doing in a print statement I can't imagine it's all that harmful.

This is my approach:

import Foundation
import os.log

struct Log {
    enum LogLevel: String {
        case error = "⛔️"
        case warning = "⚠️"
        case debug = "💬"
    }

    static func debug(_ info: String, level: LogLevel = .debug, file: String = #file, function: String = #function, line: Int = #line) {
        os_log("%@ %@:%d %@: %@", type: .default, level.rawValue, (file as NSString).lastPathComponent, line, function, info)
    }

    static func warning(_ info: String, level: LogLevel = .warning, file: String = #file, function: String = #function, line: Int = #line) {
        os_log("%@ %@:%d %@: %@", type: .default, level.rawValue, (file as NSString).lastPathComponent, line, function, info)
    }

    static func error(_ error: NSError, level: LogLevel = .error, file: String = #file, function: String = #function, line: Int = #line) {
        os_log("%@ %@:%d %@: %@", type: .default, level.rawValue, (file as NSString).lastPathComponent, line, function, "\(error)")
    }
}

Usage:

Log.debug("MyLog")

Output example:

💬 AppDelegate.swift:26 application(_:didFinishLaunchingWithOptions:): MyLog

I was getting annoyed at not being able to use "\(variable)" Swift string interpolation in os_log.

I wrote a small extension to get around the issue:

import os.log

extension OSLog {
    
    static func log(_ message: String, log: OSLog = .default, type: OSLogType = .default) {
        os_log("%@", log: log, type: type, message)
    }
    
}

This does cause "private" logging, which is expected.

App Name <private>

In Console.app, how can I reveal to what <private> tags are actually referring?

---

In Apple's WWDC 2016 presentation "Unified Logging and Activity Tracing" they say:

Avoid wrapping os log APIs in other functions.

If you wrap it in another function you then lose our ability to collect the file and line number for you.

If you absolutely have to wrap our APIs, then wrap them in macros and not in functions.

So this is perhaps not the best solution if you are concerned about additional collected information. Although that information still may not be available even using stock os_log: How to find source file and line number from os_log()

A "macro" alternative that allows "\(variable)" substitution would be welcome if anyone want to write it.