Hotkeys and the Mac App Store

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.