Mac App Store: Sandboxing Update
By Steve on June 29, 2012
A few months ago, I discussed how new sandboxing requirements have prompted us to move away from the Mac App Store for future releases. Since that blog post, a few things happened:
- The deadline was delayed to 1st June, giving everyone some extra time
- Apple made some changes to OS X to allow more behaviours to be supported within the sandbox
- Apple decided that they would still allow bugfix updates to non-sandboxed apps that were already available in the Mac App Store prior to 1st June
All these moves were welcome, and we thank Apple for making them. We have subsequently been able to publish SourceTree 1.4 to the App Store. We even had an expedited bug fix approved after the 1st June deadline, which was very useful.
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.
[This update is just to clarify the questions we’ve had from people who have seen the recent 1.4 updates on the Mac App Store. We have already started using the new Developer ID code signatures since 1.4.4, which means the direct download version is compatible with Gatekeeper on Mountain Lion — Apple’s recommended method to distribute apps outside the Mac App Store.]
Update December 2012:
We decided to speculatively submit further 1.5 updates to the Mac App Store anyway, and so far, reviewers have allowed the updates to be approved. Given the official line from Apple that only bugfix releases will be allowed on the Mac App Store without sandboxing, we cannot guarantee that further updates will be accepted. We will continue to submit them as a convenience for our users who still wish to use the Mac App Store version, for as long as they continue to be approved, but must warn you that this situation may not continue indefinitely – we’re basically at Apple’s mercy here. We continue to recommend using the direct version from sourcetreeapp.com which receives updates much faster (review delays on MAS are running at several weeks) and is also able to support some features which MAS does not allow.
Update January 2013:
Apple has now stopped accepting updates to SourceTree in the Mac App Store, as we expected, although a little later than we thought. Therefore SourceTree 1.5.6 will be the last version available on the Mac App Store, you should switch to the direct version from http://sourcetreeapp.com if you want future updates (and why wouldn’t you? 😉 ).
22 Comments
Pixelmator is sandboxed in the Mac App Store and it _DOES_ send AppleEvents to iPhoto/Mail/Aperture, it also has full access to the hard drive and some other entitlements. Why can’t you do that?
To do that requires using temporary exceptions that Apple have said they’ll take away later, so this is a delaying tactic only. And Pixelmator doesn’t really have a choice, they made the decision to go solely with the App Store a while back – we didn’t so we have more flexibility.
Pixelmator is also a typical document-based app, which is a lot easier to sandbox. It doesn’t doesn’t share system tool configuration like SSH, nor does it have cases using defaultdestination paths etc – it’s a typical single-file, document-based app where using simple save dialogs all the time makes sense. That’s not the case with SourceTree.
As I’ve said, we *could* sandbox, but we’d have to take away a bunch of useful behaviours (SSH that just works with your existing configuration, default project folders, needing to force people to rebuild their entire bookmarks list when porting over). It’s just not justified to annoy users when we have an alternative that already works.
Well, we will simply use temporary exceptions, also to tell Apple why we need them. The whole Sandboxing thing is also new for Apple and they have to learn all the usage cases, e.g. of file system access. I expect that the transition will take another 2 years or so, but then it is easier for everybody.
There are not even temporary exceptions for everything we need, though. The other 2 things listed there are not avoidable with exceptions and would require downgrades to the app *immediately*.
Is this still accurate? You say “SourceTree 1.5 onwards will only be distributed via sourcetreeapp.com” but the Mac App Store seems to have version 1.5.6.
I’ve added an update to the blog post above reflecting the current situation.
Apple Y u no like developers?
It’s all about the user experience for them. Sometimes that just isn’t very good for developers.
This is unfortunate. I’ve really enjoyed SourceTree, but I refuse to go outside of the AppStore for utilties.
Hi Cameron,
Regardless of whether you get it from the MAS or not from the MAS, it still uses the same updating framework (Sparkle). There’s no difference between the two other than where the updated dmg gets sent to and where your copy picks it up from. Other than that, both are pretty much identical.
Hope that helps
And in my mind that was a downside of your handling of updates. The updating through Sparkle was not ideal, but at least it is in the MAS. This situation is terribly disappointing.
BTW I have been evaluating HipChat as a replacement for Campfire, but at least Campfire has 3rd party clients in the MAS.
Your willingness to accept software that is less than it could/should be is why Apple continues to get away with these types of decisions. The claim that such decisions are for user experience seem to be a veil for developer conformance instead.
SourceTree is one piece of software I have advocated for quite some time. I’m a mobile developer for both Android and iOS and consider myself a fairly early adopter of Git. SourceTree has represented a piece of software that really differentiates Windows and the Mac experience from a development standpoint. Windows has been plagued by terrible source control tools for Git. However, I don’t believe for one minute that the user experience on Mac will be severely diminished by sandboxing. SourceTree, as it stands today, is a perfectly capable client, it is free, it supports GitFlow and it was in the MAS. Now, Atlassian has decided to pull their client from the MAS because they don’t want sandbox. You could argue that the user experience is solely based upon features provided and if the sandbox gets in the way we should go outside the sandbox. I’m sure, if some had their way, we would be able to install anything we want on our iPhone or iPad and damn the consequences. Sounds great, until you deal with the consequences of that decision. I personally am willing to take a lesser user experience, which I feel is both overstated by some developers, and the real sandboxing issues will ultimately be resolved in time. In any case, sandboxing is the right thing for the user in the same way app signing is the right thing for the user. In neither case would the average Mac user understand why this is beneficial, but it is.
I stand corrected then. You, obviously, have thought about it from more than one angle. I am far too used to dealing with fan boys and took you for one that thinks Apple is always right, and damn those consequences. Thank you for the civility in your response.
Perhaps, Atlassian will go back to the MAS once the issues are worked out. I use this client mostly on Windows for the same reasons you specified; lack of good tooling for source control (Git more so than Hg).
On the Mac, I wish you luck finding a suitable replacement.
We’re far from alone in taking this route when it comes to developer tools and other ‘power’ utilities. Gatekeeper was introduced in 10.8 partly as a response to the clear need for tools which required more flexibility than the new MAS rules allowed while still providing user security, and for that reason we’re not expecting Apple to change their stance to a more flexible position in future. As a consumer of Mac software I use MAS all the time but often choose non-MAS options for some tools when they’re available in both places, because there are often limitations in the MAS versions. I agree with Apple’s stance for general apps, but I also think there’s a percentage of tools that are incompatible with that general stance, which is why Gatekeeper was added. It’s just a shame that these MAS rules weren’t in place from day 1 instead of being introduced retrospectively, putting a lot of developers in an awkward position.
Sorry, I’m mistaken on that front anyway, we just use the MAS update process rather than Sparkle when on the MAS.
Reading the rest of your comments, there are a good few features in SourceTree which users absolutely rely on (some people solely use it for these features) which would be impossible whilst using the MAS for distribution due to the constraints/limitations imposed.
It’s not to in any speak badly of the MAS, these constraints are there for a good reason. If Apple could deal with it on a case-by-case basis then it wouldn’t be so problematic, but from a resource-perspective I can see why that’s not possible.
If in the future Apple were more lenient then of course we would return as many people use the MAS solely for their method of obtaining software.
I do hope us being out of the MAS won’t deter you from using our product. The safety and security of your system and data are always of our upmost priority, everything is just as safe as it was beforehand. In our case we hadn’t changed anything from a sandbox perspective, it’s just Apple decided to no longer accept updates. As the articles written by Steve say, we were outside of the sandbox long before we were no longer able to publish to the MAS meaning even Apple themselves considered us safe to deploy.
Because it is cumbersome to change, because of the Apple!
Veryvery sad… Sourcetree is a wonderful app! Still using appstore version on everyday basis… somewhat slow UX, while refreshing status of sshfs-mapped paths or large repos. If you have a pill, update that appstore branch, please 🙂
SourceTree is a great app and there is no way I could possibly manage using git without it.
I’m still using 1.5.6 from MAS and I’m not sure what I am missing from the latest version from outside the MAS.
I would encourage you to still put out a version on MAS. I don’t understand what features would suffer because of the restrictions of sandboxing and it makes me wary not knowing what SourceTree is doing that it requires uncontrolled access.
If the restrictions of sandboxing would cause some minor inconvenience (such as a separate SSH configuration within SourceTree.app) then my preference would be for the security of sandboxing.
What features of SourceTree are impeded by sandboxing?
We covered this in the previous blog post: http://blog.sourcetreeapp.com/2012/02/16/abandoning-the-mac-app-store/ – things haven’t materially changed since then despite giving Apple feedback on the things they were preventing. One UX thing is that sandboxing forces you to operate in a ‘per-document mode’ where the user must explicitly open a ‘document’ through File > Open and the OS blocks all other kinds of file access. Given that SourceTree doesn’t operate in that mode, and we need to integrate with & configure other non-sandboxed tools, primarily git and hg, in a way which is prevented by sandboxing, there’s just basically lots of little UX breakages that add up to a huge support headache and it’s just not worth it.
I’ll add my voice to those complaining about a lack of updates on the MAS. MAS sandboxing restrictions aren’t harsh enough to prevent the other development tools I use from accessing whole directory trees. Textastic, a nice little cross-platform (iOS/Mac) editor with iCloud support doesn’t have a problem with this.
FTA: “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.”
From a comment: “…there are a good few features in SourceTree which users absolutely rely on (some people solely use it for these features) which would be impossible whilst using the MAS for distribution due to the constraints/limitations imposed.”
You have been intentionally nebulous as to what the problems actually are. In one comment you misrepresented sandboxing as a per-file model for access; this is simply not true. Like several other tools (i.e. Texpad) you can bundle the command-line tools you require within your application bundle, compiled and signed using the same developer certificate. This will allow you to execute them unhindered from within the application while they inherit your sandboxing restrictions. Yes, you’d have to have the user “manually select” the SSH key to use (if using that git communication method) to grant access… the first time. Use environment variables to define the rc file paths for each of the tools as within your Application Support folder: your app always has access to that.
Text editors actually fit perfectly into the document style model that sandboxing defines. And ‘command line tools’ isn’t referring to including tools in the app bundle & calling them from the app (we do that already), it’s about installing those tools so they can be used from the terminal. As for your point about App Support – that’s fine, but this requires redefining things like HOME in order for SSH / Git / GPG etc etc not to go looking in your main HOME directory, which means configurations don’t stay in sync between your command line tools and SourceTree, and a hundred other little niggles that break existing expectations.
Supporting sandboxing in ST is like a hundred little cuts – on their own a bit annoying, but together a major inconvenience when you’re used to things just working. I wish Apple had launched MAS with the current rules, because we would probably have never joined it in the first place (adhering to the original rules took some work too), like pretty much all the other Git tools out there, hardly any of which are on MAS so competing with them is harder if we take on extra limitations. Our view is it’s more important to keep focussing our efforts on making the best dev tool we can for the majority of our users who aren’t on MAS. Apologies if that isn’t what you want to hear, but that’s the call we have to make.