iOS: Can OSLogPreferences applied to Xcode console?

I'm trying to figure out how to maximize the value of structured logging in my project. The log filtering improvements in Xcode 15 are great but limited to being able to control the logging at a fine-grained level. For example, if I want to always disable some chatty debug logs for a specific category.

Setting OSLogPreference solves this problem once you've installed it onto a device, but when running in debug mode on Xcode, it seems to ignore this and print everything.

Is there a way to apply OSLogPreference while running Xcode, or another way to selectively disable categories?

Post not yet marked as solved Up vote post of p8burns Down vote post of p8burns
516 views

Replies

Actually, OSLogPreference isn't behaving as expected when on the device either.

From what I can tell Level in OSLogPreference only seems to affect the logs if they are labeled "Off". Default, Info, and debug do not seem to have the desired effect.

So in a fresh project I added these log lines:


            let offLog = Logger(subsystem: sub, category: "offLog")
            let debugLog = Logger(subsystem: sub, category: "debugLog")
            let infoLog = Logger(subsystem: sub, category: "infoLog")
            let defaultLog = Logger(subsystem: sub, category: "defaultLog")
            let unsetLog = Logger(subsystem: sub, category: "unsetLog")

            offLog.debug("1: offLog.debug")
            debugLog.debug("2: debugLog.debug")
            infoLog.debug("3: infoLog.debug")
            defaultLog.debug("4: defaultLog.debug")
            unsetLog.debug("5: unsetLog.debug")

            offLog.info("1: offLog.info")
            debugLog.info("2: debugLog.info")
            infoLog.info("3: infoLog.info")
            defaultLog.info("4: defaultLog.info")
            unsetLog.info("5: unsetLog.info")

            offLog.notice("1: offLog.notice")
            debugLog.notice("2: debugLog.notice")
            infoLog.notice("3: infoLog.notice")
            defaultLog.notice("4: defaultLog.notice")
            unsetLog.notice("5: unsetLog.notice")

            offLog.error("1: offLog.error")
            debugLog.error("2: debugLog.error")
            infoLog.error("3: infoLog.error")
            defaultLog.error("4: defaultLog.error")
            unsetLog.error("5: unsetLog.error")

With this pList

Xcode always outputs all of the logs. and console only removes the logs from "offLog"

Xcode:

Console

Seems like a bug?

One more update, I tried running sudo log collect --last 15m --device-name 'X. This does seem to respect the log preferences...

This does seem to respect the log preferences

Interesting. There are multiple views on the log stream, some public (like OSLogStore) and some private. I suspect that Xcode is using an interface that has the behaviour you’re seeing.

I’m not sure whether I’d call that a bug myself, but it’s clearly causing you grief so I recommend that you file a bug about it. Make sure to explain what you’re doing and why the current behaviour is a problem.

Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for the response, Eskimo,

Agree it may not be a bug the idea of public vs private is illuminating. However, it would be beneficial to document what OSLogPreference affects. Its behavior between Xcode, Console, the log utility, and syslogs pulled from cfgutil is surprisingly different. Unless I'm missing some documentation, the only way to figure this out is through empirical testing. In the ideal, this would be consistent, but if nothing else some addition to the man pages could be really useful.

I also noticed you responded to a post I made four years ago. I appreciate your support in the forums!

I have a renewed interest in leveraging structured logging for my team with the introduction of Xcode 15. I'm actually finding I have a lot of feature requests to make. I'll write those up later this week with my findings and post them here.