According to TUAW, Apple will start rejecting Mac apps with “hotkey functionality” starting June 1, when the deadline for Sandboxing will become active for Mac App Store developers.
Apparently, Apple will allow hotkey apps that are already in the Mac App Store before June to offer only bug fixes. New apps and any apps that add features (i.e. non-bugfix releases) will not be allowed to support hotkeys.
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.
While TUAW doesn’t specifically mention any Mac app that would be subject to this new restriction, it is safe to assume that by “hotkey functionality” they mean desktop applications that allow users to set up keyboard shortcuts to activate other apps or system locations (such as Apptivate), or an app’s specific functionality (such as Alfred’s hotkey to show a search box, or OmniFocus’ hotkey-based Quick Entry panel).
I spoke to various developers of Mac apps with system-wide hotkey functionality, and they were unaware of the changes that Apple may begin to enforce on June 1. Currently, there is no mention of such specific change in the Mac App Store Review Guidelines (or Sandboxing FAQs), and the APIs used by the developers I contacted aren’t deprecated in the latest Mountain Lion Developer Preview, updated yesterday. Some developers told me Apple may have rejected some apps that registered hotkeys without a user’s explicit consent, but according to TUAW the issue is different, and related to the kind of control and experience that Apple wants on the Mac App Store, rather than technical limitations or APIs.
Initially pushed back from November 2011 to March 2012, and then again to June 1, 2012, Sandboxing for Mac apps has found a considerable amount of skepticism in the Apple developer community, as it would pose a threat to existing Mac apps that would have to rework their functionalities around the limitations of sandboxing.
As I wrote in February:
Sandboxing is a new technology in OS X Lion that limits the functionalities of Mac App Store applications to a list of “entitlements” that cover various areas of the operating system an app can access, such as networking, printing, or a user’s files. A sandboxed application would be unable to harm the system outside of its operational scope (managed by the entitlements), and this has caused some concerns as apps would lose access to the Mac’s entire filesystem, which is required by some functionalities of certain applications that aren’t necessary malicious or “compromised”. Similarly, inter-app communication would be a technical issue with sandboxing, as apps like TextExpander, Keyboard Maestro and CoverSutra — utilities that perform actions in the background without asking for user’s interaction in some cases (user-initiated actions can override the sandbox) — couldn’t get past the sandboxing requirement for the Mac App Store.
In the past months, a number of notable Mac developers have voiced their concerns in regards to sandboxing: Daniel Jalkut of Red Sweater Software wrote that “to increase adoption, Apple should expand the current list of entitlements until it covers every reasonable behavior that users expect from Mac apps”; following his decision to stop selling Clipstart on the Mac App Store, Riverfold’s Manton Reece noted how, rather than playing “catch-up” with Apple to work around the list of entitlements for sandboxed apps, he’d prefer to keep selling his apps on his own website – something that the upcoming Mountain Lion will keep supporting thanks to GateKeeper.
Over at TUAW, Erica Sadun says we should say goodbye to “hotkeys, macro programs, end-user customization”. While I can’t confirm the kind of apps and “hotkey functionalities” that Apple has apparently already rejected or will start rejecting in two weeks (I’ve only seen some discussions about clipboard managers and keyboard shortcuts on the Mac Dev Forums), it would surely be unfortunate to lose software like Alfred, Apptivate, or Keyboard Maestro (just to name a few) to an updated Mac App Store policy. Erica Sadun refers to these hotkey-enabled apps as “all those great little hotkey shortcuts that used to let us bring an app to the forefront and do something”.
That sandboxing would be a technical issue for apps based on AppleScript technologies is nothing new; however, Apple also specifically asked developers to get in touch with the company if technical issues were preventing them from sandboxing an app, suggesting that the company was actively working on getting developers of existing great Mac software on board with sandboxing, without limitations. This week, the Pixelmator team updated their application with support for sandboxing; other developers of “power-user” applications like Keyboard Maestro, however, still haven’t found a proper way to work around sandboxing entitlements, going as far as writing “Keyboard Maestro requires access to other applications to perform your macros and so is not, and cannot, be sandboxed” on the app’s Mac App Store page.
According to Apple’s notice from February, developers of existing apps on the Mac App Store that are not sandboxed may still submit bug fix updates without sandboxing their apps. In theory, this should mean that apps like Alfred or Shortcuts (with hotkey functionality) or Keyboard Maestro (for general incompatibility) should stay on the Mac App Store as long as their developers don’t include new features, but only bug fixes for existing customers. But what’s going to happen when developers of hotkey-enabled apps or already-approved macro programs like KM will decide to update their apps with new features?
Just like in February, the future of sandboxing and Mac App Store apps is uncertain, but it’s looking worse if Apple really has decided to ban hotkey functionality – a common trait of keyboard-based software, such as Mac apps – from the Mac App Store. With the WWDC ‘12 scheduled to kick off 10 days after the proposed sandboxing deadline, here’s to hoping Apple will, once again, be more flexible, and offer third-party developers new ways to work around sandboxing – the Mac App Store deserves all kinds of OS X software, from simple single-purpose utilities, to more complex, power user-oriented applications.
Update: Throughout the day, several developers I spoke to confirmed my earlier reports that the APIs to implement global hotkeys and keyboard shortcuts haven’t been deprecated (not even in Mountain Lion), and aren’t going away any time soon. Two developers I spoke to, in particular, confirmed that recent updates to their Mac apps with “hotkey functionality” were approved without issues by Apple.
Furthermore, developers confirmed they couldn’t find any new mention of hotkey-related entitlements in today’s updated documentation for Gatekeeper and Sandboxing. So while more “complex” utilities like Keyboard Maestro and TextExpander may still have to find a way to work around Sandboxing, other apps that incorporate hotkey functionality – like OmniFocus, Alfred, or just about any app that offers a systemwide shortcut – should still be fine for the Mac App Store.
Lex Friedman at Macworld confirmed with his own sources that a ban for general “hotkey functionality” isn’t coming to the Mac App Store, writing that “so long as developers use Apple’s officially supported APIs to register systemwide global hotkeys, their apps will remain eligible for inclusion in the Mac App Store”.
