{"id":24521,"date":"2019-03-06T16:35:38","date_gmt":"2019-03-06T21:35:38","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=24521"},"modified":"2019-04-28T20:20:24","modified_gmt":"2019-04-29T00:20:24","slug":"problems-with-os_log","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2019\/03\/06\/problems-with-os_log\/","title":{"rendered":"Problems With os_log"},"content":{"rendered":"

BJ Homer<\/a>:<\/p>\n

\n

Is there anyone outside Apple who finds the new logging system useful? Seems like it’s annoying and actively intrusive for external developers.<\/p>\n

The os_log<\/code> features are useful to Apple, but without anyway to gather logs for our own reporting, I don’t see how the features are useful to third party devs.<\/p>\n<\/blockquote>\n

Some of the problems: difficulty getting logs from customers, so much spew that the log files are huge and hard to sift through, important log entries that are never persisted to disk, high CPU use when leaving Console open to catch the unpersisted entries, NSLog<\/code> becoming unreliable and not showing anything in some cases, API that needs to be wrapped to be useful but which is designed not to be wrapped. Instead of unifying things, unified logging has resulted in everyone finding their own workarounds.<\/p>\n\n

Peter Steinberger<\/a>:<\/p>\n

Ideally, we’d love to fully switch to Apple’s os_log API. However, it has one major downside: There’s still no way to access the rolling log to add to the reports that get sent back to us. Multiple radars have been submitted to Apple, requesting this feature be added (rdar:\/\/40853863, rdar:\/\/30444429), but in the meantime, developers are forced to implement their own solutions if they wish to include logging in a crash’s backtrace.<\/p>

[…]<\/p>

For our specific use case, we’ve decided to integrate Crashlytics’ CLSLogv<\/code> function as a custom logger that we use with CocoaLumberjack<\/a>, a framework that offers many other useful features, such as adding macOS logging capabilities.<\/p><\/blockquote>\n\n

Mike Piontek<\/a> (tweet<\/a>):<\/p>\n

With NSLog<\/code> I can have a switch in my iOS or macOS app that redirects stderr to a file. The user can turn that on, recreate the problem, and just tap a button to email the file. Super simple.<\/p>\n

With os_log<\/code>, this doesn’t work. Of course there’s sysdiagnose, but that requires a complicated button combination, scrolling through a list of hundreds of other log files, and then… basically the only option is to try to email me a 200MB file.<\/p>\n

[…]<\/p>\n

I was originally planning to create my own wrapper for os_log<\/code>, even though it’s recommended against (see WWDC 2016<\/a>). That way I could have it write to a file as needed, or just pass the data to os_log<\/code> the rest of the time. But it seems there’s actually no good way to do that, due to the problems described here<\/a>.<\/p><\/blockquote>\n\n

Rob Mayoff<\/a>:<\/p>\n

The problem is that os_log<\/code> doesn’t take an Array<CVarArg><\/code> argument; os_log<\/code> is itself variadic over CVarArg<\/code>. So Swift casts args<\/code> (an Array<CVarArg><\/code>) to CVarArg<\/code>, and sticks that casted CVarArg<\/code> into another<\/strong> Array<CVarArg><\/code>.<\/p>

[…]<\/p>

Sadly for you, Swift doesn’t yet have any syntax for argument splatting. It’s been discussed more than once in Swift-Evolution (in this thread, for example<\/a>), but there’s not yet a solution on the horizon.<\/p>

[…]<\/p>

So you might go looking for an os_logv<\/code>. Sadly, you won’t find one. There is no documented companion to os_log<\/code> that takes pre-bundled arguments.<\/p>

[…]<\/p>

One last thing. Why doesn’t the compiler complain about converting Array<CVarArg><\/code> to CVarArg<\/code>? And why does Kamran’s suggestion (of using %@<\/code>) work?<\/p>

It turns out these questions have the same answer: it’s because Array<\/code> is “bridgeable” to an Objective-C object.<\/p><\/blockquote>\n\n

Previously:<\/p>\n