Problems With os_log
Is there anyone outside Apple who finds the new logging system useful? Seems like it’s annoying and actively intrusive for external developers.
The
os_logfeatures 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.
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 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.
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.
[…]
For our specific use case, we’ve decided to integrate Crashlytics’
CLSLogvfunction as a custom logger that we use with CocoaLumberjack, a framework that offers many other useful features, such as adding macOS logging capabilities.
With
NSLogI 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.With
os_log, 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.[…]
I was originally planning to create my own wrapper for
os_log, even though it’s recommended against (see WWDC 2016). That way I could have it write to a file as needed, or just pass the data toos_logthe rest of the time. But it seems there’s actually no good way to do that, due to the problems described here.
The problem is that
os_logdoesn’t take anArray<CVarArg>argument;os_logis itself variadic overCVarArg. So Swift castsargs(anArray<CVarArg>) toCVarArg, and sticks that castedCVarArginto anotherArray<CVarArg>.[…]
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), but there’s not yet a solution on the horizon.
[…]
So you might go looking for an
os_logv. Sadly, you won’t find one. There is no documented companion toos_logthat takes pre-bundled arguments.[…]
One last thing. Why doesn’t the compiler complain about converting
Array<CVarArg>toCVarArg? And why does Kamran’s suggestion (of using%@) work?It turns out these questions have the same answer: it’s because
Arrayis “bridgeable” to an Objective-C object.
Previously:
Update (2019-03-07): Kyle Howells:
It feels like an internal tool Apple built for themselves and then asked everyone else to use for our use cases, without realising it doesn’t actually work for those uses.
See also: Custom String Interpolation and Compile-time Interpretation applied to Logging (via Tony Arnold).
Update (2019-03-08): Per Olofsson:
Add to this that
os_logcan’t be called from scripting languages such as python
