Scrivener and the Mac App Store

The big Mac-related news of the past week has been the release of the shiny new Mac App Store, which got plonked into the Dock of anybody who upgraded to OS X 10.6.6. Accordingly, we've been receiving a number of enquiries about our plans: some potential customers want to know if we'll be coming to the App Store because they would rather buy from this central app hub; others, and some existing customers, are concerned that we will move to the App Store and stop selling via our own site, as a couple of high-profile apps have done, and about what the ramifications of such a move would be in terms of upgrades.

So, those questions answered in full:

Will You Be Putting Scrivener on the Mac App Store?

Hopefully, yes; that's certainly our plan. Who wouldn't want to be in a store that sits on every Mac? (Or at least every Mac running 10.6.6 and onwards…)

When?

I'm hoping to submit Scrivener to the Mac App Store once 2.0.3 is finished. There are still some bugs lurking and my first priority is to ensure existing customers are happy. I'm hoping to have 2.0.3 ready by the end of this month, or early February (but don't quote me on that; I have a Douglas Adams approach to deadlines). Of course, once I submit Scrivener to the App Store, there is still no telling how long it will take to get on there. I'm hearing about lots of apps that have been sitting in review since November and aren't on there yet, and there's no way of knowing in advance whether Scrivener will even be accepted first time or not - to a certain extent it depends on how they are approaching the review process. Things like the block cursor and certain HUD controls in Scrivener might not be allowed - I may yet have to strip certain features out for the App Store version just to get it on there. We'll see.

Will You Still Be Selling Via Your Site?

Absolutely. We most certainly will *not* be moving exclusively to the App Store. Anyone who owns Scrivener 1.x should upgrade directly via us, too, because the App Store doesn't allow upgrade pricing, and even if it did there would be no way of validating the update because Apple maintain complete control over the App Store customer database. There's also no way of offering trial versions via the App Store, so if you want to try out Scrivener it will always be best to come here first. Even if we eventually get more sales via the App Store, our plan is that our site and our own (eSellerate-run) web store will remain our own central hub for selling both the Mac and Windows versions of Scrivener. The Mac App Store will just be another option for our customers.

Will the App Store Version Be Cheaper?

No. Or, if so, not by much. I'll be choosing whichever price tier is closest to $45. As Ken Case of the Omni Group said recently, the App Store doesn't change the value of our software, so it won't affect the price. A lot of people talk about a "race to the bottom" in terms of price, but that's not a race we want to win! There's no way of knowing right now whether all quality apps will thrive on the App Store or whether it will be a place people go predominantly to look for cheap apps for quick entertainment. We already sell Scrivener at a very reasonable price that students and struggling writers can afford. And although there's a chance that dropping the price in the App Store could lead to enough of a volume increase to more than make up for the price drop, it's not all about the money. It's *partly* about the money, of course - or we wouldn't be bothering with the App Store at all. We need to eat, after all. But I like the fact that our customers have generally come to Scrivener out of a need for software like it; I don't necessarily want to encourage impulse purchases in the App Store by dropping the price significantly and then find that we have unhappy customers who bought based on a single screenshot or a two-line review. Instead, what I hope is that the Mac App Store either brings Scrivener to more potential users' attention, who then research it in more detail to see if it is the tool for them, or that it makes Scrivener easier to find by people who have heard about Scrivener and automatically look for it on the App Store. So, we're approaching the App Store as a nice way of getting "out there" to more potential users who haven't heard of Scrivener, but who would have bought it had they known about it; we won't be trying to draw in people who don't think Scrivener is worth $45.

That was a very long-winded way of saying, no, the price will stay the same, wasn't it?

What's All This About Piracy and Receipt Validation?

Okay, we're not getting any questions about this at all, I just wanted to mention it anyway. :)

I spent a couple of days last week getting Scrivener 2.0.3 App Store-ready so that I can just click the "Submit" button in Xcode's Organizer when 2.0.3 is finished. I still have the receipt validation code to deal with, though. There was a minor furore last week when it transpired that within the first day of the App Store trading, the popular game Angry Birds had been hacked and pirated. This caused the usual to-and-fro'ing: on one side, there were accusations that Apple had been careless and had exposed developers using the App Store to piracy; on the other, there were rebuttals that Apple had made it very clear that developers should use a process called "receipt validation" to avoid piracy, and that it was entirely the fault of developers for not implementing this properly if their programs got hacked. I think the reality is somewhere in between, but I'm surprised that I can't find more discussion from developers about this - perhaps it's my lack of a computer science degree showing.

It is true that in their Mac App Store guidelines, Apple tell developers to use "receipt validation", and they link to a document explaining it. The document (which although part of the password-protected developer site has been pasted all over the internet, so I'm not leaking anything that isn't publicly available here), begins thus:

"Receipt validation requires an understanding of cryptography and a variety of secure coding techniques. It’s important that you employ a solution that is unique to your application."

And herein lies the rub. While the Mac App Store seems a wonderful way for indie developers to get their products "out there", I doubt there are many indie developers with cryptography experts on their team. If you're not a coder, it's understandable that you might think all developers probably have a good understanding of this stuff, and that therefore the Apple document gives developers everything they need to protect their software. But no single developer can be an expert in every aspect of computer science or code. (Bear in mind that I'm a self-taught coder, but on the other hand I bet so are a lot of developers trying to get into the App Store; that's part of the beauty of Cocoa.) Half of Apple's receipt validation document may as well be written in ancient Hebrew for all the sense it makes to me: "The outermost portion is a PKCS #7 container, as defined by RFC 2315, with its payload encoded using ASN.1 (Abstract Syntax Notation One), as defined by ITU-T X.690…" Are these droid names? So, I'm not entirely surprised that other developers have had issues here too (and for the record, it seems that Angry Birds did follow some of those instructions, but unfortunately Apple give some shaky advice in their document that does leave programs open to hacking, as pointed out here with a solution: http://www.craftymind.com/2011/01/06/mac-app-store-hacked-how-developers-can-better-protect-themselves/ )

Fortunately, there seem to be a couple of good receipt validation examples and source code snippets on the internet that I am hoping will steer me right. (If you come across any sites featuring great, clear tutorials on the subject, though, please do feel free to steer me towards them.) The fact remains, however, that the whole point of indie software such as Scrivener using third-party serial-number schemes such as that of eSellerate (which we use), is that they are the cryptography experts so we don't need to be; we can leave them to worry about serial number validation, encryption and so on while we get on with adding features and fixing bugs. We hand over 8 or 9% or however much and in return get a serial number and activation scheme, a web store handled by eSellerate, and full control over our customer database. Apple, meanwhile, take 30%, do not give developers any access to their own customer databases, and place the burden of a copy-protection scheme squarely on the developer. There's no way you would choose Apple's scheme over eSellerate, Kagi or any of the others were it not for the fact that they offer you a place on a store that resides on every Mac desktop. So, I can live with the 30% in return for being placed in a store known of by every potential user, but I am a little disappointed that Apple insist on applications in the Mac App Store not using application-specific protection schemes when they haven't put in place a mandatory anti-piracy scheme that doesn't require the developer to have a firm understanding of cryptography.

Hopefully these are just teething troubles, though, and that over the coming months we will see Apple introduce trial modes, upgrade pricing and easier copy-protection schemes. And hopefully, too, I'll be able to figure out the sample source code out there and get my head around receipt validation…

(I'd be interested to hear from other developers - whether you are using Roddi's source code from GitHub, whether you had no problems with Apple's docs and therefore think it's just me, etc.)

Oh, and I nearly forgot:

Happy New Year!