Archive for September 27, 2016

Tuesday, September 27, 2016

AppleScript and Code Signing in Sierra

Shane Stanley:

If you have moved to macOS 10.12 Sierra, you will probably have noticed that the AppleScript version is 2.5, unchanged from that in El Capitan. That doesn’t mean nothing has changed for scripters, though; there are at least a couple of things we have noticed.


In Sierra, the rules on what can be in a signed bundle have been tightened, and resource forks are no longer allowed. AppleScript has been saving information in resource forks forever, although that information has been unused for a long time. With Sierra, when you save a script, this resource fork information will no longer be saved.

So how will this affect scripters? If you don’t sign your code, it obviously doesn’t matter. And if you have applets written and codesigned under previous versions of the OS, they’ll still work fine. But it means you cannot codesign a script that was last saved in a version before Sierra; you have to save in Sierra to be able to sign in Sierra.

SpamSieve supports some e-mail clients that require AppleScripts to have resource forks. Newfangled data fork scripts are not recognized. With Sierra, it’s no longer possible to include those scripts in my app because then it can’t be signed:

resource fork, Finder information, or similar detritus not allowed. Command /usr/bin/codesign failed with exit code 1.

So I am instead packaging the scripts in a .tar archive and having the app expand it to access the scripts when needed. In order to complete the code signing, I also had to get rid of some unimportant metadata that was attached to some of my HTML and CSS files. The easiest way to do this was to delete the affected folders and restore them from Git (which only stores basic Unix metadata). You can also use the xattr tool.

If you’re code signing with Sierra, also beware of having duplicate identities.

Back to Stanley:

[A] lot of applications that did not have tabbed windows will when running under 10.12, and how that effects scripting them might not be obvious. […] The trick is that, as far as these applications are concerned, they are still opening separate windows for each document the same as before. The system then makes the windows all the same size and position, and only actually draws the frontmost one to the screen, along with a tab bar.

So when you script such an application, you too should treat the tabs as separate windows.

Unfortunate App Store Rejections

One of the less discussed problems with App Review is that apps get rejected for using private API when they are not actually doing so. Peter Steinberger’s PSPDFKit:

These are in fact not calls to private API, just simple selector name clashes, where PSPDFKit has named a method internally the same as one that Apple uses internally. Since these internal names are not documented and this also cannot be verified offline, there is no way for us to anticipate what names are supposedly reserved.


This review seems to be both arbitrary and applied at random. We also got reports that they submitted the exact same app binary, just changed the build number to allow a re-submission, and it went through without any issues.

Sometimes this happens in reverse. Daniel Jalkut:

A major App Store frustration is you can never know when a precision bug fix update will be blocked by reconsidered review criteria.

And then there are the no-win situations. Jalkut again:

Interesting edge case: latest version of @blackinkapp (a bug fix for Sierra) rejected because I link to subscription info pages for puzzles.

Advice from Apple is to use in-app purchase, but I don’t control or profit from them. Have to stop encouraging 3rd party purchases. :-\

Glenn Fleishman:

So you can’t link to a product page for the app which has info?

Daniel Jalkut:

I’m overt about it in the app: I offer a login screen for the affected services. I can see why they’re grumpy, but what can I do?

Glenn Fleishman:

They rejected my The Magazine archives after several months for sale because the book had some Amazon book links in it.

Which was ridiculous. It’s a 1,200-“page” ebook with Amazon links that generate $0. i’m not fixing it.

Sierra Drops HiDPI Scaling on External Displays

Tim Hardwick (via Mike Rundle):

Several MacRumors readers using 4K displays have described the disappearance of scaled HiDPI resolutions beyond 1920x1080 since updating from OS X El Capitan, leaving their options reduced to 1080p or a non-scaled native resolution of 3840x2160. Monitors with native 1440p resolutions also seem to have had HiDPI scaling options removed.

Owners of larger displays often use Apple's scaled HiDPI resolutions offered in Display preferences to enjoy increased desktop space without reducing the legibility of text.


This command in Terminal and a reboot fixed it for me on Sierra.

See also: Super User.

Update (2016-09-27): Ian Sutherland:

I was having this problem with my 4K display in Sierra. Plugged it in today and it worked perfectly at 2560x1440. No idea why.

DreamHost’s New Mail Filtering

I’ve long recommended DreamHost as a mail provider because they allowed full user control. Alas, that is no longer the case. It started with the creation of Promotion and Social mailboxes, which could not be turned off. There was an outcry, so the feature was temporarily removed until a setting could be added.

However, a new spam filter was also introduced, and unlike DreamHost’s previous offering, there is no way to disable it. This is an issue for several reasons. First, I already use a more accurate spam filter and some Mail rules to organize messages just the way I want. I don’t want the spam sprayed across different account mailboxes. Messages in server mailboxes are ineligible for processing with Mail rules, add IMAP syncing overhead, and can be difficult to deal with in Mail because it doesn’t always cache messages that did not arrive in the inbox.

Second, the new filter makes lots of mistakes. I had more than 1,000 false positives (good messages in the Spam mailbox) in the first few days. And this was despite creating whitelist rules that matched the vast majority of those messages, but which were for some reason ignored. The messages were almost all from the same domain, which I blanket whitelisted at the highest priority, so there’s no reason this shouldn’t have worked. The whitelist rules are also limited, so even if they worked you could not effectively disable the filter by creating a rule that whitelisted everything (or even everything from a particular mailing list).

Lastly, some of my accounts are monitored by FogBugz. I don’t check them from regular mail clients, so there is no opportunity to review the contents of the Spam mailboxes. FogBugz only checks for new messages in the inbox, so any falsely caught good messages will be silently ignored. I’ve temporarily worked around this by creating DreamHost forwarders to forward those addresses to a FastMail account. DreamHost does not apply its spam filter to forwarded messages, and FastMail’s own filter can be turned off. So this setup allows FogBugz to see all the messages.

What about the other accounts? It’s actually quite common for mail providers to have server junk filters that can’t be disabled. This is usually not a problem so long as they put the messages in the Spam mailbox rather than deleting them sight-unseen. There are a variety of ways to deal with this, whether or not you are using a client-side filter such as SpamSieve.

Update (2016-10-18): The DreamHost whitelist rules are still not working, and the support people have not been able to explain to me why.