The official company blog, used for update announcements, new products and general communication. If you want to keep up with posts here you can subscribe to the RSS feed or follow the Twitter account.
Update: Crisis averted :)
Earlier today Erica Sadun at TUAW posted an article about Apple potentially rejecting applications from the Mac App Store that use “global hotkeys”.
As Codepoints for Mac makes good use of global hotkeys, and ships on the Mac App Store, naturally I'm a bit concerned about how to handle the situation, if true.
Codepoints uses an optional global hotkey so you can access it from anywhere, even if you're typing in a word processor or writing code in an IDE, or writing an email. The alternative (or one of them, see end) is to use the mouse and manually hit the Menu Bar icon each time.
Codepoints doesn’t set this hotkey on its own, it ships with the hotkey disabled and presents the user with a message in a small box noting this capability:
The assumption being made is that this potential change is related to the Sandbox, due to become mandatory on June 1st.
However, Codepoints is already sandboxed, and has been since the day it became available on the store, so that doesn’t make much sense to me unless Apple simply hadn’t got around to excluding this public API (see below) from being used by sandboxed apps.
More likely, if true, Apple just doesn’t want Mac App Store software to let users override the keyboard commands of other applications or system actions. For instance the default keyboard commands for copy and paste are cmd-C and cmd-V, respectively. However, applications that allow the user to set global hotkeys can override both of those actions if the user accidentally picks those key sequences to do something else, which may cause confusion.
Global hotkeys can also conflict with local hotkeys, those that have a specific action attached to them within an application. For instance, Sparrow uses cmd-N to open a new mail dialog, however if cmd-N is set to be a global hotkey elsewhere, that action is the one that will actually take place when the user presses that key sequence, even if Sparrow has focus.
It’s also possible that Apple simply doesn’t want Mac App Store software altering global behavior of the system, and global hotkeys definitely qualify there.
If you don’t know what global hotkeys are, they allow an application and the person using it to designate a specific key sequence that can be attached to a specific action in that application, which works even when the application isn’t in focus. OS X also allows you to set global hotkeys for some OS level actions, you can see those in System Preferences under the Keyboard area.
Global hotkeys aren’t new on OS X, nor are they part of a private Apple API. The one Codepoints uses for this purpose is part of Carbon and is specifically made available in the public header files, which note that it has been there through the entire life of OS X, from 10.0 forward:
extern OSStatus RegisterEventHotKey( UInt32 inHotKeyCode, UInt32 inHotKeyModifiers, EventHotKeyID inHotKeyID, EventTargetRef inTarget, OptionBits inOptions, EventHotKeyRef * outRef) AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER;
As this API is part of Carbon, my guess is this functionality predates OS X entirely and was available in Mac OS 9 and earlier.
The API is not deprecated in Lion, and so far as I know it isn’t deprecated in Mountain Lion either, but it seems if Erica is correct, Apple does not want Mac App Store applications to use it anymore going forward.
As for Codepoints, it’s likely that it will remain on the Mac App Store and I can still issue bugfixes, but the first time I go to add a feature, Apple is likely to reject the update until I remove that global hotkey box.
There may be alternatives I can look in to, other APIs to use that don’t strictly involve setting a global hotkey but still provide the same functionality, I'll certainly check and update Codepoints if I find a good solution.