Aetles + sandboxing   24

Two months later, developers (mostly) positive about OS X’s GateKeeper | Ars Technica
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.
apple  developers  macappstore  sandboxing  gatekeeper  osx 
october 2012 by Aetles
Droplr, Mac App Store, and Sandboxing
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.
sandboxing  macappstore 
august 2012 by Aetles
Why developers, customers should be wary of the Mac App Store | Macworld
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.
apple  macappstore  sandboxing  mac  developers 
august 2012 by Aetles
Sandbox of frustration: Apple's walled garden closes in on Mac developers | The Verge
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.
sandboxing  developers  macappstore  mac  apple 
august 2012 by Aetles
It’s not just the geeks like us –
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.
apple  macappstore  sandboxing  mac 
august 2012 by Aetles
The Mac App Store’s future of irrelevance –
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.
apple  mac  macappstore  sandboxing 
august 2012 by Aetles
Postbox and the Mac App Store — Postbox
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.
masexodus  sandboxing  macappstore 
july 2012 by Aetles
1Password on the Mac App Store « Macdrifter
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.
mac  osx  macappstore  sandboxing  masexodus 
july 2012 by Aetles
Apple’s Sandboxing…One Month In | Ted Landau's User Friendly View | The Mac Observer
It’s now been over a month since Apple began enforcing its sandboxing policies for the Mac App Store. With the dust beginning to settle, what can we conclude?
mac  osx  macappstore  masexodus  sandboxing 
july 2012 by Aetles
Mac App Store: Sandboxing Update – SourceTree by Atlassian
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 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.
macappstore  sandboxing  mac  osx  masexodus 
june 2012 by Aetles
iCloud and App Store Transition: Yojimbo – Andy Ihnatko's Celestial Waste of Bandwidth (BETA)
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?
appstore  apple  mac  macappstore  sandboxing 
june 2012 by Aetles Mac App Store vs Buying Direct
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:
apple  macappstore  sandboxing 
june 2012 by Aetles
Red Sweater Blog – The Sandbox’s Big Red Button
In short: the Big Red Button gives Apple an out.

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.
app  apple  development  mac  sandboxing  macappstore 
june 2012 by Aetles Daniel on Fixing the Sandbox
I toss all my Mac app ideas that require more than the default sandboxing rules — no matter how cool the idea is.

The sandbox has a chilling effect on at least one developer. I’d be surprised if it were just me.
apple  sandboxing  macappstore 
february 2012 by Aetles
Manton Reece: Sandboxing and Clipstart
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.
sandboxing  macappstore  mac  osx 
february 2012 by Aetles
Red Sweater Blog – Fix The Sandbox
The Broken Sandbox

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.
sandboxing  security  macappstore 
february 2012 by Aetles
Fix The Sandbox –
Sandboxing is a great idea. But if too few developers can use it, most users will never be able to run a sandboxed-apps-only setup, removing much of the purpose of sandboxing in the first place.

And if Mac users perpetually remain accustomed to looking outside the App Store for robust software, it hinders everyone in the App Store ecosystem, including Apple.
february 2012 by Aetles
Between a rock and a hard place – our decision to abandon the Mac App Store – SourceTree by Atlassian
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 (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.
sandboxing  macappstore  mac  osx 
february 2012 by Aetles · Sandboxing
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:

xpchelper reply message validation: sandbox creation failed: 1002
Container object initialization failed: The file couldn’t be opened.
apple  development  mac  osx  sandboxing 
january 2012 by Aetles
Sustainable Softworks Blog: Understanding the Controversy Around Sandboxing
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.
macappstore  sandboxing  mac  osx 
november 2011 by Aetles
Michael Tsai - Blog - Why the Mac App Sandbox Makes Me Sad
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.
macappstore  sandboxing  osx 
november 2011 by Aetles
Alfred Powerpack and the Mac App Store (or not) « Alfred App – Mac OS X Quicklaunch Application
The Mac App Store and Sandboxing

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.
macappstore  sandboxing  osx  alfred 
november 2011 by Aetles
Call Me Fishmeal.: Real Security in Mac OS X Requires Apple-Signed Certificates
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.
apple  sandboxing  osx  mac  macappstore 
november 2011 by Aetles
App Store sandboxing coming in March; developers wary | Macworld
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.
macappstore  sandboxing  mac  osx 
november 2011 by Aetles

Copy this bookmark: