Tag Archives: sandboxing

Mac App Store developer survey

DevMate surveyed 679 Mac developers to put together a report on who is using the Mac App Store vs. selling direct, what concerns developers have, which tools they use, and more. On why developers leave the Mac App Store:

If you’re thinking giving away 30% of your hard-earned revenue is the deal-breaker, you’d be surprised. Revenue share is not the main reason developers flee. The main reason is the long and unclear App Review process, closely followed by revshare and the absence of trial versions.

While sandboxing does show up on the complaint list, it’s ranked low as a reason to not use the Mac App Store, even though it was why I pulled my app Clipstart from the Mac App Store 4 years ago. And not much has changed since I wrote about Sketch and other apps leaving the Mac App Store last year.

For anyone who has been following blog posts and conference talks about the Mac App Store, there won’t be many surprises in this new survey, but I found the details interesting. The survey appears to be a good snapshot of how the Mac community is feeling about selling software.

Sandbox iLife and iWork

Chad Sellers has a post comparing Mac App Store sandboxing to mistakes from Linux, with this very reasonable advice:

“I believe that Apple should have at least led the way by sandboxing all of their own apps sold through the Mac App Store (I believe they have not sandboxed a single one of their 17).”

This reminds me of Twitter. When Twitter forced third-party clients to move to OAuth, but didn’t change their own app to use it, many developers said it was a double standard. Twitter’s response: the official Twitter app was part of the service, not really a separate app, so it didn’t need to use OAuth.

Maybe Apple could make the same case for Mac OS X’s built-in apps: Address Book, iCal, and Mail don’t need to be sandboxed because they are part of the operating system. But that argument doesn’t work for Keynote or iMovie. Those apps should play by the same rules that all productivity and video software in the store does.

If Apple were to sandbox a few of these it would go a long way toward convincing developers to do the same. And it would also shake out bugs and missing APIs in the whole sandbox environment.

Sandboxing follow-up

The day after I “wrote about removing Clipstart from the Mac App Store”:http://www.manton.org/2012/02/sandboxing_and_clipstart.html, Apple announced that the sandboxing requirement would be delayed again. In that announcement was also a new twist: sandboxing would not be required for bug fix updates to existing apps.

This is welcome news, but I stand by my post. I still plan to transition Clipstart away from the MAS. The difference now is that I can do it at my own pace, providing a new version or two to MAS customers that will make the move easier.

I’ve already gotten started. Clipstart 1.4 just shipped with a few new features and better support for recognizing MAS receipt files. I’ve also submitted it to the Mac App Store, where it is waiting for review.

It’s not clear where we are going to end up with sandboxing. “Quoted in Macworld’s coverage”:http://www.macworld.com/article/165502/2012/02/sandbox_deadline_delayed_yet_again_to_june_1.html, Paul Kafasis suggests that sandboxing is so flawed that Apple should just scrap the whole thing.

“Michael Tsai talks about”:http://mjtsai.com/blog/2012/02/20/sandboxing-and-clipstart/ all the work that is required to stay in the store. He closes with something that I’ve been thinking about:

“At each step of the way, it looks like just a little more work to get into the Mac App Store, or to stay there. Until the next issue pops up. And then, if you’re successful, you’re sort of locked into it due to the reasonable expectations of your many customers.”

This lock-in creates two immediate problems with leaving the Mac App Store:

  • What about customers who may have originally bought the app directly from me, but decided to “upgrade” to the Mac App Store version? I’m sure I only have a few of these, but it’s still unfortunate if someone bought the app twice. I’m just glad I didn’t follow the lead of MAS-exclusive developers, such as “Pixelmator’s effort to encourage customers”:http://www.pixelmator.com/blog/2011/01/06/transition-to-the-mac-app-store/ to switch to the MAS.

  • How do current Mac App Store customers get notified that there is a new version available outside the store? Sparkle is not allowed in the MAS, but I think the right thing to do here is provide a similar notification in the app. It would link to a web page with instructions for downloading the app directly.

I’ll admit I have some regret leaving the Mac App Store. It’s just so convenient for purchasing and installation. If I’m going to make this work, I’ll have to redesign my own rather clunky purchase and activation experience. And I’ll have to do a much better job of marketing, something that has not been easy with Clipstart.

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.

But let’s take a step back, to a good blog post from Craig Hockenberry on moving xScope to use sandboxing. One of the most important things to keep in mind is that what works for one app may be unsuitable for another. Craig touches on this with an example from Panic’s Transmit:

“Of course there are some applications that have a harder time than others: primarily if those apps require access to all or part of the filesystem (think about syncing data with Transmit, for example.)”

Clipstart also falls into the same “needs to access the whole file system” category as Transmit. It’s not just one feature; the whole app is based on the fact that it can point to video files anywhere on the system, or manage your video library in a central location on any hard drive. These are things that are difficult to do in the sandbox, but even worse, I don’t see a clear path forward for existing customers to move into such a restrictive environment.

Maybe I could file bugs with Apple for exemptions, and reduce the functionality of my app to fit within the limits of the sandbox, but I’ve made the decision that it is just not worth it. I would much rather spend 100% of the time I have for Clipstart on new features only, not playing catch-up with Apple.

Atlassian has made a similar decision for their app SourceTree. On the sandboxing restrictions:

“The trouble is, the sandboxing implementation currently in place on Mac OS X Lion doesn’t allow for all the behaviours that real Mac applications do _right now_, behaviours which are not at all contentious, are approved in the Mac App Store already, and indeed are very much appreciated by users.”

Daniel Jalkut continues this argument, saying that sandboxing could be good for developers, if only the current entitlements weren’t so very incomplete. That’s true. But we can only make decisions based on what entitlements and APIs are there today, and today it’s not enough.

I will try to make this casualty of sandboxing as painless as possible for Clipstart customers. I will honor Mac App Store receipt files so that everyone can migrate to new versions of the app. And I’ll provide extra serial numbers to anyone who asks, for fresh installs on machines that never had the Mac App Store version.

Clipstart has turned out to not be a very good fit for the Mac App Store anyway. It’s the kind of app that you need to download and try out before committing your whole video library to it. Sandboxing is just the latest and most significant in a series of frustrations with the MAS.

For my customers, sandboxing isn’t actually a feature; it’s a bottleneck to getting work done. I can’t justify spending any time on it. I already have a product and platform (Tweet Library for iOS) where I can play the app review game. I want my Mac app to be a break from that, with a total focus on making the app better and a release schedule and feature set that I control.

So it was a relief to hear about Gatekeeper. I don’t want pulling Clipstart from the MAS to automatically doom the product, and now I don’t think it will. Instead of shying away from features that won’t work in the sandbox, I can even embrace them as a competitive advantage. I’m more excited than ever to get back to Mac development without this decision and chilling effect hanging over my head.