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.

15 Comments RSS · Twitter


The reason nothing's been documented is that not all is known. That's my guess - there's a lot of parts of various lineages and vintages that have to communicate across the system for some things to work. They may just be working this out now with the Sandbox. The Sandbox edict probably came before everything was untangled anyway, and if you think not having documentation sucks, imagine them having to retract or restate some sandbox promise because they found a corner case that couldn't easily be resolved, or that would have to change in a minor OS update.


@Jesper Just to emphasize what you’re saying: they issued the edict that all applications must be sandboxed before they even knew which APIs would work in the sandbox.


Just to be clear I wasn't necessarily referring to malware. Personally I think if someone sneaks malware in an app there's not much you can do about it. The app store helps a little there but not much frankly.

Rather I think part of the point of the MAS is to eliminate surprises for naive users. For that I think the hotkey can do things users aren't prepared for - especially when there are conflicts. It's more about simplicity than just malware. I also wouldn't say I'm a non-technical user although I fully admit I'm not a Cocoa programmer yet. But I've made my living programming, including the Mac, most of my life. That said I fully admit I was conflating hotkeys via this method with lower level event trapping when I wrote my post.


@Clark I didn’t mean to imply that everything in (3) necessarily applied to you.

If Apple really were doing this to try to eliminate surprise, banning the entire API seems like a rather crude solution with lots of collateral damage. First, I’m not sure that this has really been a problem in the past; applications typically register hotkeys that the user is unlikely to be using for anything else. Conflicts are more common with the Services mechanism. Second, Apple already has policies for lots of usability-type issues; it could simply issue guidelines for how hotkeys should be used.

I like your follow-up post except that I’ve never heard of an application using the hotkey API only for non-global use. Why code it that way?


Here's what I believe happened. Erica's source at TUAW was good, and had good reason to believe that Apple would implement the described ban on hotkey usage.

But my source, which I trust without any doubt, reported after a couple hours of research that that was incorrect.

It's possible that, as you say, Erica's story prompted a review and policy change at Apple. We could both have been right at our respective press times. That's my best guess.

And yes, my sources say RegisterEventHotKey is the way to go.


> Conflicts are more common with the Services mechanism.

I may be misreading you, but this is what Apple's docs say: "Remember that your shortcuts are being added to the collection of shortcuts defined by each application as well as defined by the other services. When an application already has a shortcut with that key equivalent, the application’s shortcut wins. If multiple services define the same shortcut, which one gets invoked is undefined."

It makes sense that nice-to-have service shortcuts shouldn't clobber app shortcuts. Whether this actually works as documented, I don't know.

If you mean simply that a service shortcut is more likely to conflict with an app shortcut than is a hotkey, that's the reason why service shortcuts are restrained by default to command+shift, and why they may be redefined in the Keyboard preference pane.

Maybe this nicely illustrates that you'd have to jump through hoops to completely avoid confusion. If the menu item shortcut doesn't yield by default to registered hotkeys (they should; the system is in a good place to know that), that's up to you, and it's possible to get the right sort of information but the API stinks.

Whether conflicts occur is out of your purview. But then again, there are far worse ways of getting confused in Mac OS X; people who use shortcut keys (beyond Cmd+Tab, Cmd+H, Cmd+Q, Cmd+S and Cmd+ZXCVA) tend to understand the concept well enough that they can figure out both the problem and the solution.


"However, Apple has not even marked in the documentation which APIs (are supposed to) work in the sandbox."

and

"In other words, the people in charge of enforcing the rules don’t understand them."

I've long maintained that Cupertino's logic behind the App Store requires the real rules to always be unwritten. What the bouncer at the velvet rope sez in gestures are the real rules. Writing the real rules down would leave Cupertino both with less flexibility and more exposure to publicity and legal debacles.

So stuff like this bit o' mess are a natural (and to be endlessly repeated) aspect of the larger feature, not bug nature of the App Store, from Cupertino's POV. Can't document real rules if they must be left unwritten. (The hotkey bit o' mess seems to me to just be collateral damage, not part of any strategic plan.)

Pre-App Store, there was no issue in providing clear documentation. Post-App Store, there are issues in doing so.


@Jesper I mean that a service shortcut is more likely to conflict because services are choosing from a much smaller set of possibilities. There simply aren’t very many Command-Shift shortcuts that are not already taken by a command in a popular app or by another common service. Hotkeys are free to use the function keys and the Control key, which at least historically was a modifier that applications were supposed to avoid because it was for global use.


Michael, I don't know enough of how people have used that call to say much. My assumption was that it was a way to trap calls via a kind of call back without doing events. However the last time I did Mac UI programming was during the dark days of Sys8 and 9. I'm slowly teaching myself Cocoa at the moment so perhaps my brain is simply biased from the old ways of handling events in various frameworks. My ignorance lets me merely try and account for possibilities.

As for Apple taking a crude method - I hate to say it but I'm not sure they have much other choice. The problem is that they see where they want to go but don't have the infrastructure in place yet to offer developers. This is besetting many aspects of Apple. The transition to iCloud before iCloud is remotely finished is one obvious example. I think the whole MAS is clearly an other. Apple wants to revolutionize how we think about applications in a way far more radical than the Sys9 -> Cocoa transition. (And honestly in some ways the OSX transition wasn't as great as the Sys7 -> PowerPlant transition)

I disagree about conflicts though - although all the ones that come to mind afflict power users more than naive users. And power users are most apt to be able to figure out solutions. But I think Apple's stance is much more that applications shouldn't be doing global things period. That's the transition they are attempting to move people towards.


@Clark Yes, it’s clear that Apple is not content to make both cars and trucks. They also want the trucks to be more car-like.


I'm not sure the car/truck analogy works in that way. I think it's more akin to what happened when cars and trucks became so computerized requiring diagnostic equipment. Most engine tinkerers couldn't do what they wanted anymore. However there then arose new tinkerers who'd hack the computers and so forth. It was far more niche but tinkering never went away.

I think the problem is the market is shifting to the MAS. Even Adobe is offering much of their stuff there now. But Apple really wants a certain kind of experience from the MAS which isn't necessarily what sophisticated power users want. The problem is less that one could do all that stuff (limits with iCloud and potentially various kinds of messaging excluded) than it simply is the market moving. That is I think the problem of being unable to use iCloud is insignificant to most purchasers wanting you to be at MAS. But that's much more analogous to the type of tinkering in the car world that required being comfortable accessing the car computer - you could still do it but the market is much smaller than it used to be.


@Clark Analogies always break down somewhere. I’ve heard the car tinkerer one before, but I don’t think I know anyone who’s modded a car engine. On the other hand, nearly every Mac I see with third-party apps (MAS or otherwise) has one that uses hotkeys.

That is I think the problem of being unable to use iCloud is insignificant to most purchasers wanting you to be at MAS.

I don’t understand this sentence. Are you saying that users don’t (and won’t) care whether apps support iCloud? Is the market not shifting in that direction?


Sorry. That should have said, "insignificant relative to most purchasers wanting you to be at MAS." That is if one frames the issue as needing to be at MAS to use iCloud that's really not the main issue. The main issue is that more and more people are only buying software from the MAS.

To use an other analogy that will undoubtedly break down, it's akin to complaining that Walmart gets better credit card processing fees when the real issue is that most people go to Walmart rather than the corner grocery store.

All that said (and I promise this is my last comment on this) I think that the iPad will cannibalize the casual users and Apple will end up with Mac users who simply demand more not less.


"Apple will end up with Mac users who simply demand more not less."

Even if we stipulate this to be true, there's no guarantee Apple will pay attention to what its Mac customers want. They could well take the attitude that they've got bigger fish to fry.


@Clark I think you’re onto something there with the dual trends of direct downloads to Mac App Store and Mac to iPad. Once iPad growth stabilizes, do we end up with lots of iPad users owning Macs as secondary devices and only using Apple and MAS apps? Or are Macs mainly owned by more technical users who care more about features/power than MAS? Developers would like to be able to serve both sides of the market, but for some products this may not be possible without bifurcation.

Leave a Comment