Software Development

In my app ScreenFloat, I use the command line tool screencapture via NSTask to create screenshots. On OS X El Capitan and earlier versions of Apple’s operating system, this worked perfectly fine. Now, on macOS Sierra, I’ve been getting reports that screenshot creation didn’t work anymore, so I investigated.

At first I thought it might be the keyboard shortcut API that has undergone some changes, but that doesn’t seem to be the case, as I saw something actually occurred when I pressed the keyboard shortcut – Xcode’s console printed:

screencapture: cannot run two interactive screen captures at a time

Since I was absolutely sure I’m not launching screencapture via NSTasktwice, I took to Console.app to see if anything unusual was reported there. And there it was:

Sandbox Violation of ScreenFloat on macOS SierraThe output in Console.app when trying to launch an interactive screencapture with NSTask.

deny mach-register

So registering a global Mach service is denied on macOS Sierra. In the back of my mind, I remembered a temporary exception entitlement, but it wasn’t quite the same – com.apple.security.temporary-exception.mach-lookup.global-name. I tried adding it to ScreenFloat’s entitlements file, with com.apple.screencapture.interactive as its value (this temporary entitlement expects an array of string values), but that didn’t help – the same denial and console output occurred. On a hunch, I tried using …mach-register.global-name instead of …mach-lookup.global-name and – tada – it worked!

So I’m all set, right? Well…

Temporary Exception Entitlements

Apple offers a couple of temporary exception entitlements. They may or may not be granted to your app during Apple’s review process. But going through the list, it’s clear that …mach-register.global-name is nowhere to be found, so it’s kind of a private entitlement – which makes it even less likely for it to be granted to your app.

Digging Further

Seeing as the sandbox denial points explicitly to com.apple.screencapture.interactive, not just com.apple.screencapture generally, I tried creating a non-interactive screencapture session with NSTask. To my surprise, it worked – without the entitlement.

So I tried a different command line utility – which. (which will return the executable path to the given command line utility, for example, which screencapture would return /usr/sbin/screencapture). Again, it worked. And again, without the entitlement.

It makes me believe (and hope) that the behavior we see for com.apple.screencapture.interactive is not desired, so I’ve filed a bug report with Apple in the hopes that they can set the record straight soon.

For now, I hope ScreenFloat will be granted the temporary entitlement just so it is functional again on macOS Sierra for the time being. However, if this is in fact the desired behavior, I will have to write my own screencapture utility so ScreenFloat can remain on the Mac App Store.

Bug Reporting

For anyone who’s interested or in a position to view it, here’s the bug report I’ve filed with Apple: rdar://27610157. I do hope to get an answer soon.

Update August 2nd, 2016

As I stated above, com.apple.security.temporary-exception.mach-register.global-name isn’t documented anywhere. Which is also the reason you get an error when trying to submit an app with such an entitlement to iTunes Connect:

ERROR ITMS-90285

So, no dice on the temporary exception. Having to write my own screenshot utility seems more and more likely. I hope I can make it in time for macOS Sierra.

Update September 9th, 2016

The temporary exception is now valid and will go through to Apple’s App Review without a hitch. My own solution is not necessary at this time, but I’m still going to be working on it – you never know.

 

Eternal Storms Software Logo

– – – Do you enjoy my blog and/or my software? – – –

Stay up-to-date on all things Eternal Storms Software and join my low-frequency newsletter (one mail a month at most). Thank you 🙂

Read more

On twitter, the question was posed if the Ink System Preferences pane could be installed without having a supported graphics tablet.

I immediately jumped to answer: YES, there is!
I remembered because I’ve had a need for this myself, way back when the OS X sandbox was introduced.

Why I Know This

Every now and then, I get an eMail from a graphics tablet user, describing how they suddenly aren’t able to drag files out of Yoink anymore. No warning. No apparent signs to why Yoink wouldn’t do its duty anymore. And all the console would say is “sandbox: deny hid-control”.
Thankfully, now, I know what it means and I can give users directions on what to do. However, after all these years, Apple still hasn’t done anything (not one thing!) about this bug in the sandbox, and it’s insanely irritating.

For me to be able to confirm that it had in fact to do with OS X’s handwriting recognition, aka Ink, i had to find a way to activate it, without actually having a graphics tablet at my disposal.

I tried doing the obvious thing (navigating to /System/Library/PreferencePanes/ and double-clicking Ink), but that only resulted in this error message:

Ink Install Error

Install The Ink System Preferences Pane

If you, too, need to test some stuff with Ink, even though you currently don’t have a graphics tablet handy, here’s how to do it.

After a lot of trial and error, this is the working solution I came up with:

  1. In Finder, navigate to /System/Library/CoreServices/Menu Extras
  2. Double-click onto Ink.menu

This item will appear in the right part of your menu bar (notice how it’s perfectly updated for the dark appearance of the menu bar… NOT) :

Ink menu bar icon

Now, click on Ink Preferences… and it will launch System Preferences for you, installing the Ink preference pane:

Ink preference pane

A restart of System Preferences removes the preference pane again, though you’ll continue to be able to install it using the menu bar item.
Should you have the wish to remove Ink from your menu bar, hold down the command key (⌘) on your keyboard and drag the item off, then release the mouse button. The poof-animation will appear, indicating that the item has been successfully removed.

Eternal Storms Software Logo

– – – Do you enjoy my blog and/or my software? – – –

Stay up-to-date on all things Eternal Storms Software and join my low-frequency newsletter (one mail a month at most).
Thank you 🙂

Read more

In iOS Simulator, you can, via a menu item, quickly simulate memory pressure for the simulated device to see if your app behaves correctly under low memory conditions (releasing caches, cleaning up resources, and so on).

Recently, I had the need for it on the Mac (where such a menu item is not available), while working on an XPC service for Yoink, to see if it terminated properly under certain conditions.

Meet the memory_pressure tool

OS X comes with the Terminal, and with the Terminal come some awesome tools. Among them is memory_pressure. Its man page says it all:

Apply real or simulate memory pressure on the system.

Usage of memory_tool

sudo memory_pressure -S -l critical

What this does is simulate (-S) a memory pressure of a critical level (-l critical).
sudo is needed, otherwise it will probably fail with an “Operation not permitted” error.

memory_tool’s options

-l:   Two levels of pressure are supported: ‘warn’ and ‘critical’.
-p:  For real pressure, this lets you define how much memory should remain free, in percent of total memory.
-S:  Simulate memory pressure, don’t really allocate memory.
-s:   If applying real pressure, this is the duration to wait before allocating or freeing memory.
       If it’s simulated pressure, the system will be maintained at an artificial memory level for this duration.

Read more