Archive for May 17, 2012

Thursday, May 17, 2012

Hotkeys and the Mac App Store

Erica Sadun (via Christopher Forsythe and Mark Munz):

TUAW has been told that Apple will be rejecting all apps with hotkey functionality starting June 1, regardless of whether the new features are hotkey related or not. Basically, if you’re developing one of those apps, an app that assumes you can still add hotkeys, don’t bother submitting it to the Mac App Store.

My understanding was that hotkeys (e.g. created by RegisterEventHotKey) were allowed but that simulating keypresses and the accessibility APIs were not. I’ve found no official statement to the contrary. Tons of applications use hotkeys, from iTunes controllers and Twitter clients to OmniFocus, EagleFiler, and Acorn.

It doesn’t make sense that Apple would want to ban this popular and (seemingly) safe feature. Thus, my first reaction was that this story is probably incorrect. However, it was written by Erica Sadun with feedback from Gwynne Raskind, two writers/developers with reputations for knowing what they’re talking about. So I’m afraid that I must take it seriously.

Incidentally, one of the problems with the Mac App Store and sandboxing is that we don’t know what’s intended to work. When building an application that is to be compatible with Mac OS X 10.6, you can set Xcode to warn you about using APIs that were not available in Snow Leopard. (Unfortunately, Apple has been scaling back this “SDK” functionality so that now it only works for targeting the previous OS release. Good luck maintaining 10.5 or 10.4 compatibility when using Xcode 4 on 10.7.)

In theory, there could be a similar feature for the compiler to warn about using APIs that are not allowed in the Mac App Store. The headers for a method could be annotated to say that it requires Mac OS X 10.6 or later, or 10.8 or later when sandboxed. However, Apple has not even marked in the documentation which APIs (are supposed to) work in the sandbox. My guess is that they may not know. Thus, the process has been backwards compared with previous major transitions. Instead of Apple saying which features it intends to support or drop, developers are told to run their apps and file bugs when things don’t work.

Update (2012-05-17): Lex Friedman:

Macworld can confirm that no such hotkey ban is coming to the Mac App Store. In fact, Apple offers developers several public APIs that make simple work of creating global keyboard shortcuts, and those APIs aren’t going away.

TUAW’s editor:

I stand behind this story due to the evidence we received, but unfortunately it is evidence we cannot share publicly. While many have claimed our story is untrue, I can tell you that due diligence was practiced and, based on the evidence we received, what was indicated by Apple stands as written. Several clarifications have been added to this story, but all I can tell people is that either Apple is unsure of what hotkey functionality is in this case, or something has changed very recently in such a way as to negate what was said previously by Apple.

Apple is not on the record yet, and Macworld wouldn’t identify its sources or say whether they were at Apple, so I still see this as inconclusive. I would also point out that the existence of a public API means nothing. There are plenty of public APIs that are forbidden from the Mac App Store by policy or that don’t work under sandboxing, either by design or due to bugs. (Currently, it looks to me like RegisterEventHotKey does work in the sandbox.)

More curious, Friedman tweets:

If I had @ericasadun’s source for her initial story, I would have written the same one.

Update (2012-05-18): It’s not yet been revealed how both TUAW and Macworld had reliable sources with conflicting information. My guess is that TUAW really did have a solid story and that Apple changed its policies yesterday. I predict that we’ll see a follow up from TUAW saying that its source’s app is no longer being rejected due to using hotkeys.

Here are the takeaway points for me:

  1. There was little surprise that Apple might change its policies in this way, even though that would mean throwing many popular apps out of the store.
  2. People don’t seem to realize just how many (and how wide a variety of) applications use hotkeys.
  3. Non-technical users were fully willing to believe that banning hotkeys would protect them from malware; some even expressed surprise that hotkeys had been allowed thus far.
  4. After the Macworld story, many were inclined to believe that the original story was based on an unfounded rumor.
  5. Lots of people thought that banning hotkeys wasn’t a big deal because users could just download apps from outside the store. It’s not clear how many realize that Gatekeeper apps cannot use iCloud and some other APIs.
  6. Developers feel duped by Apple. They gave the benefit of the doubt and accepted the 30% cut assuming that Apple would work out the kinks. Instead, Apple made its policies more hostile to developers and mandated the use of buggy and incomplete APIs.
  7. Sadun and others assume that “dumbing down” Mac OS X will help sell more Macs.
  8. Neither TUAW’s nor Macworld’s sources would go on the record.
  9. Apple chose not to nip this story in the bud; it has yet to go on the record.
  10. The real story is still unknown. It could be:
    1. Sadun or her original source was mistaken, perhaps confusing hotkeys with a lower level mechanism such as event taps (which are known not to work in the sandbox). This was my first thought on seeing the headline, but I considered it unlikely that Sadun and Raskind would make this mistake.
    2. Friedman’s source is mistaken, and hotkeys are in fact now banned. I’m inclined to trust Macworld, though.
    3. Apple’s policy was always to allow hotkeys, but it mistakenly told Sadun’s source that they were forbidden. In other words, the people in charge of enforcing the rules don’t understand them.
    4. Apple changed its policy to ban hotkeys and then changed it again to allow them. You can decide for yourself whether this would show that Apple doesn’t think before it acts or that it quickly responds to criticism.

Update (2012-05-21): I had asked Apple to clarify whether hotkeys would continue to be allowed and just got the response that I expected:

You should be testing and developing your apps in line with the Mac Developer Program License Agreement and the Mac App Store Review Guidelines and I am not able to provide you with any information pertaining to RegisterEventHotkey. You may wish to develop your app exactly as you would like it to function and submit it for review. If during the review process the app gets rejected, you will be able to review the reason for rejection by visiting the Resolution Center within iTunes Connect.

Restoring Mail Keyboard Shortcuts

I’ve long used the Keyboard pane in System Preferences to assign shortcuts for the items in “From” pop-up menu in Mail’s “New Message” window. This lets me send the message from a different account just by pressing a key.

(Interestingly, this same technique works for the standard “Save as PDF…” menu item when printing, but not for user-supplied PDF services.)

Mac OS X 10.7 Lion introduced a bug whereby editing a keyboard shortcut for any application would render the Mail keyboard shortcuts inoperable. If you examine Mail’s preferences file, you can see that a non-printable character is inserted on either side of the menu item title. Preferences for other applications are unaffected; I think some part of the OS doesn’t like that the titles of these menu items contain angle brackets.

Before editing a shortcut in System Preferences, you can use this Terminal command to save your Mail keyboard shortcuts:

defaults read NSUserKeyEquivalents

Copy everything in curly braces, which for me is:

    "Add Sender to Address Book" = "@~^$y";
    "Michael Tsai <>" = "@^$d";
    "Michael Tsai <>" = "@^$e";
    "Michael Tsai <>" = "@^$c";
    "Michael Tsai <>" = "@^$m";
    "Michael Tsai <>" = "@^$a";
    "Michael Tsai <>" = "@^$s";

To restore the Mail keyboard shortcuts, type:

defaults write NSUserKeyEquivalents '

Then paste, enter the closing ', and press Return.

Update (2012-07-31): This bug seems to be fixed in Mountain Lion.