Archive for March 6, 2019

Wednesday, March 6, 2019

Problems With os_log

BJ Homer:

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_log 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.

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.

Peter Steinberger:

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’ CLSLogv function as a custom logger that we use with CocoaLumberjack, a framework that offers many other useful features, such as adding macOS logging capabilities.

Mike Piontek (tweet):

With NSLog 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.

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 to os_log the rest of the time. But it seems there’s actually no good way to do that, due to the problems described here.

Rob Mayoff:

The problem is that os_log doesn’t take an Array<CVarArg> argument; os_log is itself variadic over CVarArg. So Swift casts args (an Array<CVarArg>) to CVarArg, and sticks that casted CVarArg into another Array<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 to os_log that takes pre-bundled arguments.


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

It turns out these questions have the same answer: it’s because Array is “bridgeable” to an Objective-C object.


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_log can’t be called from scripting languages such as python

Finder Bug Replacing a Folder With Dot Files

Lloyd Chambers:

  1. Copy a folder with dot files to another destination (I used “.icj”).
  2. Change one of the dot files.
  3. Repeat the copy. When the Finder offers Cancel or Replace, choose Replace.

PROBLEM: the copied folder contains old data in the invisible “.icj” file.

I was easily able to reproduce this on macOS 10.14.3.

Previously: Finder Shows Incorrect Folder Sizes.

GameClub Plans to Resurrect Abandoned iOS Games

Mitchel Broussard:

As Hodapp explained on TouchArcade, Apple’s frequent updates to the iPhone have caused ongoing problems for iOS developers on older App Store games. The first of these major issues hit during the release of the iPhone 4 in 2010 and its introduction of an increased resolution, which meant all developers needed to update their games with higher resolution textures.

While some developers decided to do this, others couldn’t justify spending time and money to modernize their games. Of course, this issue grew exponentially worse with the introduction of iOS 11 in 2017, bringing with it the removal of all 32-bit apps from the iOS App Store. TouchArcade kept an ongoing list of every 32-bit app that was no longer supported with iOS 11, including the TouchArcade app itself.


Now, Hodapp is leaving TouchArcade to address this issue with GameClub, a developer with the intent to bring the best of these forgotten and unplayable iOS games back to life. To achieve this, GameClub will handle all of the updates, ongoing maintenance, and support for each game, in essence becoming the new developer of the game.


MacStories Shortcuts Archive

Federico Viticci (tweet):

Since the original release of Workflow in 2014, we’ve created hundreds of automations to help readers use their iOS devices more efficiently. The goal of this archive is to offer a complete catalogue of our old workflows as well as new custom shortcuts for Apple’s Shortcuts app.

Each shortcut in this archive has been created, updated, and tested by Federico and the MacStories team. Shortcuts are organized in categories, and you can jump directly to a specific category by using one of the section links below.

Dr. Drang:

This is not only a set of pre-built shortcuts, it’s also a source of inspiration for new shortcuts you can build based on these.