DDOSLogger Info, Warning, Debug, and Verbose logs do not appear in Console.app when streaming from iOS simulator.

[jaredsinclair]

DDOSLogger Info, Warning, Debug, and Verbose logs do not appear in Console.app when streaming from iOS simulator.

[ffried]

First of all thanks for taking the time to describe everything in such detail, including recommendations!

Downgrade of Warning to Info

You're right that this is incorrect! They should be upgraded to error, which is what the .warning function on Logger in OSLog does as well:

Btw. there was an open source implementation of Logger in the Swift repository. While it was only used for tests, I could imagine it being pretty close to the real thing...

Missing messages in Console.app

I'm a bit torn here...
Reading a bit further in the forum you linked, I found this answer by Quinn.
Using CocoaLumberjack version 3.8.4, I was able to reproduce his findings:
Everything logged with .info or above is visible in Console.app:

This lines up with .debug messages not being shown, which was also classified as bug by Quinn in the forums.
Also matching Quinn's findings, I'm able to see these messages when using the Terminal:

Last but not least, I see all messages in Xcode's Console as well (Xcode 15.2):

Long story short, I don't think it's that simple to add a workaround in CocoaLumberjack.
In its current form, the bug seems to only affect the Console.app, not the logging SDK itself.
Personally, I've never used the Console.app to read Simulator logs, though I can see that it might be helpful to see other logs (not only the application's logs).
Given that all log messages show up correctly in Xcode, we shouldn't generally raise .debug logs to a higher level.

I could imagine adding a "level mapper" of sorts to DDOSLogger, though. This could be used to map our log levels to the ones of OSLog. We'd then provide two default implementations:

• One that basically does what the current implantation does.
• One that's only available when building for Simulator, that raises .debug to either .default or .info.
  Users of CocoaLumberjack would then still need to add a little more code, but not implement the whole workaround themselves.

What do you think?

[jaredsinclair]

You're right that this is incorrect! [Warning logs] should be upgraded to error

I left something out from my description. I've noticed that off-the-shelf there is not a neutral DDLogMessage() or DDLog() or DDLogDefault() etc method that logs at a neutral level equivalent with os_log(...) (OSLogType .default). If Warning logs get upgraded to Error, then there's still no way to produce a log that is higher than a debug/info but not an error.

This is of particular importance when viewing logs in Xcode.app or the Console.app where error and fault logs are given special UI treatment (little yellow dots in Console.app, for example) and filter capabilities. If every log that would otherwise be logged at a neutral level (i.e. warning) gets lifted to an error, then there's no way to distinguish between true error logs and neutral logs. Everything will look like an error.

Neutral-level system logs (OSLogType.default) can also provide critical information in production builds. Debug and Info type logs cannot be enabled in a production build (at least not without jumping through hoops requiring the installation of a special debugging profile), but neutral/default type logs are enabled by default. That means I can ask an end user to install my app from the App Store, run it, export a sysarchive, and view logs from that device without having to log everything at an error level. I've had to do this on projects before (that didn't use CocoaLumberjack) and it was a lifesaver.

[jaredsinclair]

I could imagine adding a "level mapper" of sorts to DDOSLogger, though

I think this idea is interesting. I've worked on projects where logging requirements change as different platform teams become subject to belated cross-platform logging standards. These standards can force teams to raise or lower log levels across the board, which can potentially wreak havoc on a codebase as thousands of log statements have to be audited to raise or lower the level to the new standard. It would be far easier to define a level mapping in one place, and leave call sites and team-specific logging practices untouched.

[ffried]

I've noticed that off-the-shelf there is not a neutral DDLogMessage() or DDLog() or DDLogDefault() etc method that logs at a neutral level equivalent with os_log(...) (OSLogType .default).

That's due to CocoaLumberjack not having a 'neutral' log level. To be honest, I haven't really understood the concept of a 'neutral' log level - and have often seen it being overused if there was one.
FWIW, I've changed the default in the switch to use the OS_LOG_TYPE_DEFAULT in #1410.

I think this idea is interesting.

Feel free to have a look at #1410 and see if the solution I've implemented there would fit your needs.