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:
Better App User Experience: Non-sandboxed apps can auto-navigate the user to correct folders in Open/Save panels, run user-written AppleScripts, control iTunes* and install PDF Services automatically.
More features: Non-sandboxed BBEdit can directly edit files that require administrator privileges, non-sandboxed OmniFocus can automatically determine the selected document in the Finder when creating a clipping. There’s lots more.
Better Data Integrity: Document-based Core Data apps are incompatible with Sandboxing. One work-around is to disable disk-based journaling, increasing the risk of data corruption. It appears sandboxed Core Data Mac apps will need to switch to packages for a long-term solution, changing file formats for no good reason (and packages are less convenient for data sharing than flat files).
More and Faster Updates: Different developers follow different update schedules, but typically direct apps get updated more often and with less latency than Mac App Store apps. Some developers intentionally throttle down their direct update schedule to match Apple’s delays and avoid customer confusion, but that’s the developer’s decision.
Less Risk of Losing Your Software Investments: I bought Divvy via the Mac App Store. Unfortunately Divvy relies on Apple’s Accessibility APIs, which aren’t allowed for sandboxed apps. That means aside from minor bug fixes, I will no longer receive updates for the application I purchased.
Some developers are going out of their way to allow seamless cross-grading from Mac App Store versions of their apps to direct apps, which is commendable and helps alleviate somewhat the situation Apple has created.
Sandboxing is just the latest App Store rule change, I’m sure there’s more to come. All things being equal, it’s safer to buy directly instead of being cut off from your own software based on an arbitrary Apple policy change.
More Money Goes to the Developer: For a $10 application, only $7 goes to the developer when you buy it through the Mac App Store. For a direct purchase, it’s more on the order of $9.
The fact more developers weren’t encouraging customers to buy directly is a testament to how much Mac developers care about User Experience — they’re willing to forego the extra profit of selling direct to make things easier for their customers.
However, as alluded to above, there are downsides to buying directly. Buying through the Mac App Store offers these benefits:
Better Purchasing Experience: Apple probably already has the customer’s credit card on file. No .zip to unpackage and drag into the right place. It Just Works.
Better Maintenance Experience: Buy a new Mac, launch App Store.app and enter your Apple credentials. Ta-da, a list of the apps you purchased ready to reinstall. No trying to remember what apps you previously had installed, who wrote them, what the developer’s website is or what your license key was.
iCloud Access: Apple has decided only Mac App Store apps (and thus now sandboxed apps) can access iCloud. Fortunately this isn’t much of an issue since the smart folks at SmileOnMyMac have already demonstrated a work-around of having a “bridge” Mac App Store application which allows its directly-sold PDFPen to access iCloud as well.
Vetted By Apple: I don’t hold this benefit in very high regard, but it does add a safety net versus downloading and running arbitrary software off the web. For example, I’m looking forward to 10.8’s Gatekeeper as a way of limiting the software my mother downloads and attempts to run on her Mac (though this is apparently possible since 10.6).
The bottom line is that sandboxing has effectively collapsed the ambiguity and customers should now purchase their apps directly instead of through the Mac App Store.
* Update: Originally I wrote here “send Growl notifications”. I was corrected by Growl Project CEO Chris Forsythe that the version of Growl in the Mac App Store appears to now listen on a machine-local network port, which works around sandbox-disallowed Mach messaging.
You may recall Seth Willits, whose app QuickPick was rejected from the Mac App Store for being “confusingly similar” to 10.7’s Launchpad. Even though QuickPick has been shipping for years before Launchpad and also runs on 10.6.
While QuickPick stayed still available for sale on the Mac App Store, it was stuck on version 2.0.2 — Apple wouldn’t let him update it.
That didn’t stop Seth from continuing to fix bugs and add new features to the direct-sale version of his app, which now stands at 2.0.7.
Unfortunately once Lion was released, it uncovered a bug in QuickPick 2.0.2 on the new OS which prevents screen corner activation from working.
Facing a widening feature gap between his direct-sale version and a bug that Apple won’t allow him to fix, Seth has done the best thing he can do: remove QuickPick from the Mac App Store.
It’s safe to say everyone loses here: Seth, his customers, Apple and Apple’s developers.
On June 30 Twitter made good on their threat of requiring OAuth flow for third-party Twitter clients in order for them to receive Direct Messages.
Fortunately we submitted Hibari 1.1.4 to Apple on June 27.
Unfortunately it turns out that wasn’t nearly enough time.
Victoria received the rejection email the afternoon of June 30th. Within the hour she deleted the offending paragraph, resubmitted (no need to even upload a new binary) and filed an expedite request since Hibari users can no longer receive Direct Messages.
Here we are 11 days later and no word from Apple.
*Apple had no problem with mentioning the demo in previous versions. Word has it this “rule” is inconsistently applied. I’m taken aback by Apple’s anti-consumer anti-demo stance. But that’s nothing new.)
Jul 12 Update: A couple of anonymous Apple friends unwedged us from the queue and Hibari 1.1.4 is now available on the Mac App Store. If you find yourself in a similar circumstance I was told it may help to resubmit a new build — it forces a re-review and can get things moving.
Some developers have already begun to make the necessary changes. Last month, video-streaming provider Hulu updated its Hulu Plus iOS app, dropping a link that allowed users to visit the company’s website to sign up for a paid subscription. Others, such as Netflix, have exploited a loophole: The login screen for the video-streaming app tells users to “Visit netflix.com to sign up” but does not provide a tappable link.
Heck of a threat, that tappable link. I can see why Apple has to ban those.
QuickPick is being kicked out of the App Store.
It doesn’t matter that QuickPick existed years before Launchpad.
QuickPick is Seth’s application and document launcher. Apple has apparently decided to remove/retroactively-reject QuickPick as being too similar to 10.7’s Launchpad.
I’ve long wanted better application management on Mac OS X, so I applaud the Mac App Store. Application installation has always been a train-wreck on Mac OS X, but at least independent developers were able to make the application updating process reasonable enough thanks to Andy Matuschak’s Sparkle.
I’m also heartened that, unlike the iOS App Store, the Mac App Store is not the exclusive channel for Mac software. Apple could have locked it down, and choose not to. I like to think this indicates a flicker of hope that one day we’ll see Snell’s switch in a future iOS release.
However I’m dismayed with the direction Apple is taking with the Mac App Store. Studying the details of Apple’s current implementation, it becomes clear Apple crafted the Mac App Store policies primarily with its own interests in mind, not of its customers and certainly not its developers.
My fellow Mac developers are laughing at the Mac App Store guidelines. They’re reporting that apps they’ve been shipping for years — a number of them Apple Design Award-winning — would be rejected from the Mac App Store. These are proven apps, beloved by their users. The current guidelines are clearly out-of-touch.
Apple, a corporation with billions and billions of dollars in the bank, is taking 30% of small Mac developer’s revenue — an outrageously high fee, more than three times what popular high-end fulfillment provider FastSpring charges. Worse, Apple keeps customer data away from developers, standing in between developers and their users. Customer service and technical support suffer — Apple won’t even allow refunds to dissatisfied customers.
Software trials are loved by customers and developers alike. It’s easy to see why: customers get to try out first hand how an app works risk-free. Developers make their customers happier and reduce refunds. Yet, inexplicably, Apple doesn’t offer trials of any sort. In fact, their developer agreement forbids it. This is questionable policy for a $2.99 game, but inexcusable for a $60 Mac app.
For all its flaws, the Mac App Store is a step in the right direction. All Apple has to do is switch to policies which benefit Apple to policies that benefit its customers and developers.
The above is my complete response to Chris Foresman’s request for my thoughts on yesterday’s Mac App Store announcement. Chris kindly quoted parts of it as well as other developers in his Ars Technica article.
Today Apple added a new section dedicated to promoting free applications on the App Store. One of the subsections of this new feature is “Try Before You Buy.” This section features many of the popular “free” or “lite” editions of apps, but the section title is what makes this all interesting.
Apple willfully ignored 25+ years of commercial software distribution trial-and-error market experimentation and education.
Try Before You Buy won a long time ago, but for some inexplicable reason Apple seems to want to drag us back to the days of Egghead Software outlets.
Try Before You Buy is good for customers, and it’s good for developers. My best guess is that Apple somehow thinks it’s not good for Apple, and that was reason enough to disallow it.
There’s a new initiative from GSMA, which is a really big consortium of Carriers and operators mostly in Europe. They’ve come to Canada. They’re doing a pilot program and it’s a terrible name. It’s called oneAPI. And the idea is that you get access to [cell] network APIs, not just device APIs. And it’s pretty fascinating.
So what are the network APIs? Well the Carriers know your geolocation, not based on a device GPS but based on cell tower triangulation. They’ve got fantastic APIs for sending text messages, SMSs, push notifications. And the killer API they have is billing.
And so with billing, it goes straight onto your phone bill. It’s something that’s going to be exposed to all the Canadian operators very soon. From one single endpoint you can hit any device that’s in Canada. It’s a pilot, and if it goes well — and it looks like it’s going to — they’re going to branch it out to Europe, Asia and the rest of North America.
In case it’s not apparent, Brian is talking about web apps that allow payment via your Carrier. That is, website charges that land directly on your monthly phone bill.
Apple (rightfully) brags about the number of credit cards they have on file via the iTunes Store. But Apple’s absolute number of accounts and average monthly transaction amount is dwarfed by the Carriers.
In today’s world, you need a cell phone. Thus, you need a Carrier account. You don’t need an iTunes account. When money gets tight, iTunes transactions look frivolous while phone bills feature an aura of utility.
People are used to paying ~$50-$300/month for their cell phone. It’s even easier for small purchases to disappear into your phone bill than on a credit card you have on file with Apple. See: Ringtones.
Carrier executive management is dumb compared to Apple. Not Record Industry-level of stupidity, but Apple can easily out-think them and try to box them into a corner.
Even if/when the US Carriers figure out they can carve themselves a piece of the Webapp Store pie, they’re not going to execute well. Think fragmented billing support, usury percentage of sale prices and piss-poor developer+customer support.
Still, the Carriers have a lot of power with their customers locked into multi-year contracts, and most folks are more loyal to their Carrier than their phone’s manufacturer.
All said, I think webapps + Carrier billing are the most credible upcoming threat to the App Store so far.
7.3 No Other Distribution Authorized Under this Agreement
Except for the distribution of freely available Licensed Applications and the distribution of Applications for use on Registered Devices as set forth in Sections 7.1 and 7.2 above, no other distribution of programs or applications developed using the Apple Software is authorized or permitted hereunder. In the absence of a separate agreement with Apple, You agree not to distribute Your Application to third parties via other distribution methods or to enable or permit others to do so.
Apple’s developer tools license mandates use of their distribution channel.
Because, you know, Cydia is such a threat to Apple’s business model.
Imagine if gcc’s license required your resulting executables run solely on Linux.
I hope section 7.3 comes back to bite Apple during their Department of Justice investigation.