13

I'm trying to log function arguments into os_log like this:

func foo(x: String, y: [String:String]) {
    //...
    os_log("foo: \(x) \(y.description)", log: OSLog.default, type: .debug)
}

But getting error:

Cannot convert value of type 'String' to expected argument type 'StaticString'

So how can I log function arguments, or any other dynamic data?

rmaddy
  • 314,917
  • 42
  • 532
  • 579
timbre timbre
  • 12,648
  • 10
  • 46
  • 77

5 Answers5

33

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.

Community
  • 1
  • 1
Martin R
  • 529,903
  • 94
  • 1,240
  • 1,382
17

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.

matt
  • 515,959
  • 87
  • 875
  • 1,141
3

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

Apoc
  • 797
  • 1
  • 10
  • 15
  • bad idea: apple highly discourages from wrapping os_log (because of performance issues). Besides on iOS 14+ Logger allows to do this without any custom overwrites. – timbre timbre Nov 11 '20 at 21:27
  • also if you look at your message on Mac log console it will look like this: `" : : "` – timbre timbre Nov 11 '20 at 21:28
1

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.

Community
  • 1
  • 1
pkamb
  • 33,281
  • 23
  • 160
  • 191
  • Except Apple explicitely recommends against this: "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." See https://developer.apple.com/videos/play/wwdc2016/721/ – timbre timbre Mar 12 '20 at 14:38
  • @KirilS. that's good info. Will edit into answer; maybe someone can submit a macro alternative. – pkamb Mar 12 '20 at 23:40
  • Although it seems to be that Line Numbers are not available from stock `os_log` either...? https://stackoverflow.com/questions/40757530/how-to-find-source-file-and-line-number-from-os-log – pkamb Mar 12 '20 at 23:41
  • 1
    @pkamb See my reformulation of the OSLog extension idea here: https://stackoverflow.com/a/62488271/341994 – matt Jun 22 '20 at 02:10
  • @matt have any idea on how to write a "wrap them in macros and not in functions" version of the extension? – pkamb Jun 22 '20 at 22:10
1

The macOS 11 Big Sur Release Notes state that os_log can now be passed Swift string interpolation:

https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-beta-release-notes

Logging

New Features

  • New APIs are available for using os_log from Swift as part of the os framework:

    • A new type Logger can be instantiated using a subsystem and category and provides methods for logging at different levels ( debug(_:) , error(_:) , fault(_:) ).

    • The Logger APIs support specifying most formatting and privacy options supported by legacy os_log APIs.

    • The new APIs provide significant performance improvements over the legacy APIs.

    • You can now pass Swift string interpolation to the os_log function.

Note: The new APIs can't be back deployed; however, the existing os_log API remains available for back deployment. (22539144)

pkamb
  • 33,281
  • 23
  • 160
  • 191