Remember the wails about Apple turning OS X into a "walled garden" when news of GateKeeper emerged? The tool, which allows OS X users to restrict where their apps come from, was announced in February 2012 and was included with Mountain Lion when it was released in July. The controversy hinged on Apple's attempt to guide users toward installing only those apps downloaded from the Mac App Store, or at least settling for a middle ground wherein users could also install apps "signed" by the developer—an action that still costs the developer $99 per year and pads Apple's bank account.

The goal was to increase security on the Mac—especially in light of the recent Flashback scare—but power users bristled. GateKeeper does allow Mac users to install apps from any source they'd like, but it's not as easy as it used to be. The OS throws up flags that warn users about unsigned applications, which can easily discourage people from trying new software.

On the developer side, however, there was a cautious optimism that GateKeeper could mean good things for Mac users. Before GateKeeper was released to the public, Ars interviewed a number of developers who told us they generally felt comfortable with the tiers of control, even if things weren't perfect. Some acknowledged that Apple was indeed stepping up its level of control over users' computers, however, and expressed concern that Apple could change its default settings at any time to limit software distribution even further.

So has the apocalypse come? Two months post-Mountain Lion, are developers suffering from GateKeeper's new restrictions? We reached out to a handful of Mac developers for their perspective, and to see how their work has been impacted by the change.

This update from the Droplr team is particularly interesting as, back in May, speculation arose as to whether Apple would start rejecting any app with “global hotkey functionality” on June 1, when the company began enforcing its new Sandboxing policies for Mac App Store apps. As it turned out, the rumor didn’t specify which kind of apps would fall under Apple’s ban, but several third-party developers confirmed their applications carrying similar functionality went through Apple’s approval process.

However, it appears the “issue” with Droplr 3.0 and the Mac App Store is simply related to standard Sandboxing practices, not strictly hotkeys. It is safe to assume that, per Apple’s Sandboxing implementation, an app like Droplr can’t benefit from unrestricted access to the Finder to automatically upload a file in the background.

Perhaps, at this point, you’re wondering what you should do. The first step is concluding how you feel about the Mac App Store and Apple’s increasingly strict rules regarding the apps that can be sold there. If you don’t mind them, keep contentedly shopping in the store.

But take pause. When we talk about the importance of backing up, we often say that it’s a question of when, not if, your hard drive will fail. With the Mac App Store, it’s nearing certainty that if you haven’t yet been stymied by the impact of one of Apple’s Mac App Store rules, you will be soon.

That stymieing might take one of several forms: A developer of an app you love might release a brand new version with a brand new price tag, since there’s no option to offer upgrade pricing. An app you love may be forced to strip out features you depend upon to comply with Apple’s rules. Or developers behind an app you love may find that they simply can’t keep the app in the Mac App Store anymore, and pull it (see Postbox, Alfred, TextExpander, and Moom, each of which has been forced to move out of the App Store and return to a direct sales only model). Whether you’ll be able to “cross-grade” from your Mac App Store version of that app to a standalone, external version will be at the whim (and maybe even technical expertise) of the developer in question.

While the Mac App Store remains a fine place to buy certain software titles today, the issues are real, and Apple thus far has displayed its characteristic determination to stick to its current plan. If you’re concerned, you have two tools you can use: The first is to stop shopping at the Mac App Store when possible, and buy apps direct from developers instead. And the second is to share your feedback with Apple directly.

It’s definitely too soon to panic about the future of the Mac App Store and OS X. But it’s not too soon to be concerned.

However, most developers have taken the past few months to update their apps according to Apple's new standards — which for some developers means checking a few boxes, and for others means sacrificing features users love. Since Mountain Lion was announced, many top apps like Fantastical, Sparrow, and 1Password have prepared for a Mac world that looks more like iOS's perceived "walled garden." For better or for worse, most developers seem to agree that adding support for Mountain Lion seems to be a do or die.

"Any developer who wants to build for Apple's products typically stays as on pace with the curve as possible, because that's what a significant portion of Apple's customers do," says 1Password's David Chartier. Developers now have two choices: sell unrestricted apps independent of the Mac App Store, or abide by Apple's rules to gain access to the App Store, its enormous distribution power, and new features in OS X like iCloud document syncing for apps and iOS-style push notifications from the cloud in Notification Center.

This isn’t about a few geeks being inconvenienced. It’s about a very large number of Mac users, far beyond geeks, being discouraged from buying (or being unable to buy) the software they need from the Mac App Store, and why that’s not in Apple’s best long-term interests.

But now, I’ve lost all confidence that the apps I buy in the App Store today will still be there next month or next year. The advantages of buying from the App Store are mostly gone now. My confidence in the App Store, as a customer, has evaporated.

Next time I buy an app that’s available both in and out of the Store, I’ll probably choose to buy it directly from the vendor.

However, we eventually determined that the Mac App Store wasn’t the best fit for Postbox. We had already established our own online store and purchase policies prior to the Mac App Store release. Additionally, the Mac App Store was not evolving quickly enough, and in the direction we needed it to go, to support the Postbox 3 release in a manner consistent with Postbox Store policies.

Roustem Karimov of AgileBits tweeted that the latest 1Password update was rejected for sandboxing entitlements. The direct purchase version was set as end of life about nine months ago. I recall the massive forum discussion about the decision to take 1Password MAS only. I converted to the MAS version in March to get on-board with their product roadmap. Now I see that it is available again as a direct download purchase and @roustem confirms it will receive the next update soon.

Going forward with future releases, however, the changes that have been made to the sandbox still do not quite address all of the issues we have with it. While we could work around them, it would downgrade the user experience, which has always been a red line for us. We also have to consider the fact that the main alternatives to SourceTree are not distributed on the Mac App Store and are therefore not constrained by these rules.

Therefore our position has not materially changed since the original decision: SourceTree 1.5 onwards will only be distributed via sourcetreeapp.com. We advise all users on the Mac App Store to migrate to the direct download version, either now or when 1.5 is released, so you can benefit from the awesome new stuff we have in store for you.

That’s what many Mac developers are dealing with right now. An app does syncing through MobileMe. Now, it needs to do it through iCloud. Fine. But Apple won’t let an app use iCloud unless it’s sold in the App Store. Fine. But Apple won’t approve an app for the App Store unless it’s sandboxed. And for many developers, sandboxing means that half of their app’s features will either no longer work at all, or will need to be dumbed way, way down. Selling your app there also means being cut off from any kind of simple and direct line of communication with your users.

The knock-forward list of problems here is a long one. My initial “what’s the harm?” reaction to the App Store’s requirements was based on the idea that a developer could still sell their apps outside of the Store if he or she wanted to. My attitude has changed. iCloud is just one example of a larger (and kind of nasty) problem: Apple is making the newest and most desirable features of the OS exclusively available to App Store software. How does that encourage developers to create the best apps possible?

Since the launch of the Mac App Store, a common question potential customers ask developers is “Should I buy your app directly or through the Mac App Store?”
Developers have been remarkably cagey, mostly replying with the non-answer “choose whichever is better for you”.
Fortunately Apple now only accepts sandboxed Mac apps, clarifying the situation: customers should buy Mac apps directly unless there’s a good reason not to.
Here are some reasons why it’s preferable to buy non-sandboxed apps directly from developers:

Whatever mistakes they make in the devising of high-level entitlements can be theoretically undone after-the-fact by supplying developers with special Big Red Button entitlements that pass along specific permissions to the lower-level sandbox, liberating the application to do whatever important task it needs to do.

I wrote a draft of this post a few weeks ago, before Mac OS X Mountain Lion was announced. It was pretty critical of Apple's aggressive approach to sandboxing, and I've kept most of that, but the new Gatekeeper feature for Mountain Lion at least gives me a way out. I don't think Apple would have created Gatekeeper if they planned to abandon apps sold outside of the Mac App Store.

For the next release of my app Clipstart, I will be removing it from the Mac App Store and only selling directly from my web site. With Gatekeeper I hope to have some confidence that my customers will still be able to run the app on future versions of the OS.

At its best sandboxing is a means for app developers to faithfully state their intentions in a manner that can be evaluated by users, and also be reliably enforced by the operating system. So if your new “Fun on Facebook” app declares its intention is to connect to the web, you might judiciously allow it. If it says it needs to write files to the root of the filesystem, you’d be wise to search for another app.

Sandboxing on the Mac works by providing developers with a standardized list of “entitlements” which are clear descriptions of things it would like to do on your Mac. Examples include: access the internet, read files from your Pictures folder, print things on your printer.

The number one broken thing about sandboxing as it stands today, is the list of entitlements is simply too limited. Many apps on the App Store, including my own, will need to have their functionality considerably diminished, or in some cases made outright useless, in order to accommodate the available list of entitlements that sandboxing offers.

On March 1st, Apple will change the rules of the Mac App Store to require all applications to run inside of a ‘sandbox’. Unfortunately, this will disallow important SourceTree functionality that was previously acceptable under store rules. Complying with the sandboxing rules would force us to change SourceTree in ways that would remove features, damage the usability of the app, and hurt our users; therefore, we will no longer submit SourceTree updates to the Mac App Store after March 1st, 2012. New updates will be available, for free, directly from sourcetreeapp.com (and via the in-app update). We will continue to monitor the situation in case Apple improve their sandboxing implementation or revise their rules. Note that we will still be signing SourceTree with our Apple developer certificate so SourceTree should work fine with the default settings of Mac OS X 10.8 Mountain Lion when it’s released.

For the full story of what forced us to take this disappointing decision, keep reading.

Speaking of Radar, we encountered a fairly nasty problem after launching xScope. Many of our customers are designers and developers who love SSDs. It’s common to use a symlink in your Home folder to put big datasets like Pictures, Music and Movies on a separate hard drive. When you do this, folder access in the application sandbox container breaks. A small number of users who use symlinks are also getting crashes after launching the app that was downloaded from the Mac App Store:

Next, consider a program like Phone Amego which doesn't download media from untrusted web sites. Its reason for being is to provide Mac to phone integration by working with many other tools. It wants to integrate with Apple's Address Book, Daylite, Contactizer Pro, Launch Bar, Finder, Dropbox, FileMaker, EagleFiler, and be scriptable. Forcing an application like Phone Amego to be sandboxed puts the developer in the awkward position of choosing between dumbing down the application by removing features, or abandoning the Mac App Store version including the thousands of customers who have already paid for the application and expect future updates and support.

Again, I must emphasize that many apps that are already in the store cannot be sandboxed at all, even with entitlements, without severely reducing their functionality. Many more would need to rely on temporary entitlements, which Apple emphasizes are “granted on a short-term basis and will be phased out over time.” And, secondly, there is the fear that Apple will withhold iCloud and other future APIs from apps that are not in the store, effectively making sandboxing mandatory.

The Mac App Store is currently in transition. From March 2012, all new submissions / updates need to be sandboxed.

Sandboxing is a way of protecting users from malicious or naughty software by severely restricting the access an application has to underlying resources. It also makes the app approval process easier for Apple as sandboxed apps simply cannot do things outside their own resources. While this works remarkably well on iOS (I am personally happy to be in the “walled garden” on my phone), it really changes the landscape for OS X applications.

As you know, Alfred isn’t a self-contained application like a game, graphics package or todo list. Many of the things Alfred does are to do with OS X itself… he searches, navigates and opens files and apps on your Mac, he runs AppleScript to interact with other applications, he even allows you to create and run lower-level shell or AppleScript extensions… he is basically your quick interface into the heart of OS X. This is where Alfred starts to throw his toys out of the [sand]box.

The Mac needs to be as secure as the iPhone. The good news is Apple already has the tools. The bad news is they are forcing developers to use the wrong ones.

There are three primary ways Apple increases security of applications running on the Mac and the iPhone: Sandboxing, Code Auditing, and Certification. While all these are incrementally valuable, none is perfect on its own.

The problem Mac developers are facing is that the two that Apple is enforcing on the Mac App Store (Sandboxing and Code Auditing) are implemented currently to be actively bad for developers and not particularly good for users. And the method that would provide the most benefit for developers and users (Certification) isn’t enforced broadly enough to be useful.

Change is coming to the Mac App Store. On Wednesday Apple announced that as of March 1, 2012, all apps submitted to the Mac App Store will have to implement a security system called sandboxing in order to gain approval. The result will be safer apps, but some developers fear that sandboxing may force them to strip out certain features.

Wednesday’s announcement to developers is actually a reprieve: When Apple first unveiled the sandboxing requirement at June’s Worldwide Developer Conference, it was supposed to go into effect this month.

Sandboxing is a security system that regulates the power individual apps can wield on your Mac. More technically, “sandboxing” means limiting an individual application’s access to your computer; rather than allowing it full access to, say, your Mac’s memory or file structure, a sandboxed app is instead confined to its own dedicated space.