Right now developers selling through the Mac App Store face a lose/lose choice: either provide all major upgrades to existing customers for free (thus losing a quarter of our revenue), or create a “new” product for each major version (creating customer confusion) and charge existing customers full price again (creating customer anger).
Why The Mac App Store is NiceThe Mac App Store has been a great new source of revenue for Delicious Monster — we’ve seen almost double total sales of “Delicious Library 2” through it. And although paying ~⅓ of our gross to Apple is pretty steep, if Apple’s finding new customers who wouldn't have found us before the Mac App Store, we can’t argue with the results. Delicious Monster also still sells ”Delicious Library 2” directly from delicious-monster.com; we assume customers who learn about Delicious Library from our site probably buy it from our site, so customers who buy from Apple probably found out about us through Apple — and Apple deserves a cut.
One unexpected result from the Mac App Store is curve-fitting our direct sales from before its introduction shows only a little cannibalization of our direct sales by Apple's channel (but you can’t prove a contrapositive, of course). This chart shows the monthly sales of ”Delicious Library 2” since its launch in May, 2008 (the y axis is in the US dollars we take home, but the magnitudes have been removed).
You’ll notice a huge pointy green tower the month we launched, followed by the typical “long tail” logarithmic sales falloff as “Delicious Library 2” gets older (which I’ve seen in every software product I’ve known). You can also see that if we removed the yellow “App Store” sales, the green “Direct” curve wouldn’t show very much of a divot.
[Notice also that January is always an awesome month for us, and February is always horrible, for reasons I can only guess at. Christmas Macs mean post-Christmas software purchases? Nobody buys Delicious Library for their Valentines?]
Finally, the outsized yellow spike in January 2011 (the month the Mac App Store launched) may be because we were one of a handful of applications with banners on the top of Mac App Store’s “Featured” tab at launch — thanks Apple!
The “No-Win” Upgrade DecisionsThe Mac App Store not providing for paid upgrades puts developers in an untenable situation. To illustrate, let’s say (hypothetically) Delicious Monster is about to release “Delicious Library ∞,” which is the most amazing thing since the invention of spit and makes “Delicious Library 1” and “2” look like old doggy poop.
What we would like to do charge $20 for version “2” customers upgrade to “Delicious Library ∞,” but still charge $40 for new customers. In this way we could make both upgrade revenue and new sales revenue like we did when we launched version “2,” since they both spike when we do a major release. To show these spikes, here’s a chart showing our actual weekly direct sales from two weeks before the launch of “Delicious Library 2” until twenty months after it, for both new sales (at around $40 a pop) and upgrades from version “1” (at around $20). (Again, the y axis is the dollars we pocket.)
Or, more simply:
Now, if only upgrade sales spiked on a major release (and new sales stayed the same), it might be reasonable for us to just discount “Delicious Library ∞” for all users for a little while. (Of course, we’d cut our profits from new sales in half, which would still hurt.)
And if only new sales spiked for a major release (and upgrade sales were negligible), it might be reasonable for us not to worry so much about upgrading existing customers at a special price — we could just say, “Pay full price again, suckers!” (Of course, our customers would feel betrayed.)
Neither of those is the case. We see a huge spike in both new and upgrade sales, and we need both spikes. Those spikes are where we build up our war chest to survive the lean months of working on a new product and watching the long tail of the old product dwindle.
But on the current Mac App Store, we can’t do upgrade sales, and there’s also no reasonable workaround. The way the Mac App Store is set up we have five decisions to make:
- Should we offer a special upgrade price on our website for existing direct customers of “2?”
- If we DO offer an upgrade price on our website, should we try to allow upgrades from customers who bought “2” from the Mac App Store?
- On the Mac App Store, should we create a new product for “Delicious Library ∞,” or release it as a revision of “2”?
- And, if we release “Delicious Library ∞” as a new product, should we pull “Delicious Library 2” from sale?
- On the Mac App Store, what should “Delicious Library ∞” cost?
Starting with question ⑴: of course we want to offer a discount price to existing customers. But what will we do about ⑵: everyone who bought “Delicious Library 2” from the Mac App Store? They’re going to be angry if we don’t offer them the same upgrade price that our direct customers would get. I mean, really angry. Ending-of-Mass-Effect-3 angry.
But maybe we could offer to upgrade Mac App Store customers to the direct-from-us version of “Delicious Library ∞?” After all, it’s the same exact product, just with our licensing code instead of Apple’s…
Except, we can’t do this. First off, we don’t even know who’s bought our app from the Mac App Store. Apple doesn’t ever give us a list of our customers. So we have no way of knowing whom to upgrade. Except, maybe we could have the customer send us their Mac App Store receipt, and we could run some magic signature checking code to see if it’s legit? Except this brings up a second, bigger problem: Apple would be furious if we upgraded Mac App Store customers to direct customers. Never mind that Apple doesn’t allow us to upgrade customers inside their store — I have no doubt they’d throw us out of the Mac App Store for even appearing to do an end-run around them.
So questions ⑴ and ⑵ are unresolved and unresolvable. So, let’s move on to question ⑶: if we release version “∞” as an update to version “2” on the Mac App Store, all our Mac App Store customers will be upgraded for free. And, if Mac App Store Customers are upgraded for free, we’ll have to upgrade direct customers for free as well, or, again… the anger. So we’d end up losing a ton of money (see green area in the charts above) if “∞” is just an update to “2.”
But if we release “∞” as a new application on the Mac App Store, we have a bunch of problems. One is, there’s still no way for people who bought “2” on the Mac App Store to upgrade. Also, now we have to decide question ⑷: whether to pull the old “2” product from the Mac App Store – if we don’t, some users will mistakenly buy it (even though “∞” is out and infinitely better), and then they’ll be mad when they found out they don’t have the latest version. (And, again, we can’t upgrade them ourselves, because we don’t have Apple’s customer list and we can’t manually issue licenses from their store; nor do we have any control over giving refunds from the Mac App Store.)
But if we do pull “2” as a product from the Mac App Store (leaving just “∞”), we can never release bug fixes for existing customers of “2” who don’t upgrade: the product is gone! As well, there would be no way for us to reach Mac App Store customers of “2” and tell them that there’s a new version available to buy.
So, there are no good answers to questions ⑶ and ⑷, just as there weren’t any to questions ⑴ and ⑵. Somebody loses no matter what we decide.
Finally, on question ⑸: if we price “Delicious Library ∞” any differently on the Mac App Store than on our site some set of customers will be unhappy (whether it’s less or more). But assuming we price “∞” the same direct and on the Mac App Store, what price should it be? If we set it to $40 all our existing “2” customers will be angry, and if we set it to $20 we’ll lose a ton of money we could have made from new customers, and some existing “2” customers will still be angry, because we’re not giving them a special deal for being loyal, we’re just lowering our price for everyone.
So, we can’t win on ⑸, either. Rats.
Developers Need Upgrade RevenueSome might say, “The App Store’s current model of free upgrades forever is great! You should just adopt it.”
Well, it seems great, but for any software which has major versions that replace the old ones (this excludes games), forcing new versions to be free is harmful to both software developers and our customers. (Let me be clear that I fully believe minor updates — for bug fixes — should stay free.)
For developers, upgrades fund the new software we’re writing, not the current stuff. Think of upgrade revenue as the Kickstarter project for our next product, whether it’s a major version of an existing product or something totally new. We live for those upgrade humps. They keep us warm in the cold months.
For customers, paying for major revisions of the software you’ve bought is the only thing that ensures there will ever be any. Consider this scenario: you’ve bought Delicious Library 2 (and of course you love it) but there’s some things you want us to add to make it even cooler. And we, in turn, would love to do this for you! So far, so good.
But, with free major upgrades, we have this unhappy choice: for the next two years we can work on a brand-new product (call it “Delicious D”) or we can work the next version of “Delicious Library ∞”. If we write “Delicious D” we know you’re going to give us another $40 of your money, because it’ll be so awesome. But if we write “Delicious Library ∞” (and we give away major upgrades) then we’re going to get $0 of your money when we’re done.
So, it would be a choice between us working for two years to get $0 or working for two years to get $40 (from existing customers). Which would you choose? We’re not being selfish, here — we’re trying to survive. Every small developer will choose to create one-off products, or die.
Without paid upgrades developers are strongly dis-incented from writing new major versions of existing products. Which stinks for us, and for customers.
You can even see this effect with Apple right now: iWork for OS X is still called “iWork ’09.” From three years ago. Now, some of this is doubtless because Apple’s been working on the great iOS version of iWork… but if iWork for OS X were a major revenue source, do you think they’d ignore it? I mean, Lighthouse Design was a much tinier company than Apple and still managed to come out with upgrades to this suite. (Apple’s iLife ’11 is more recent, but since the latest iLife always ships with new machines they don’t depend on upgrades of iLife to survive, since the iLife team is incented when machines are upgraded.)
Apple’s not keeping iWork up-to-date despite sitting on one hundred billion dollars. I’m a lot poorer than them; I simply can’t afford to write new code and not charge for it. I wish I could! It’d be great if I could say to my beloved customers, “Look, you gave me $40 six years ago, you’re set for life, here’s my latest work for free!” but my employees unfortunately don’t like it when I say to them, “Look, I paid you six years ago…”
Worse yet, if a developer is creating a product that she knows she won’t be able to afford to update, she’s going to write it differently. She’s going to think, “I’m going to make this seem all flashy and cool but not really worry about it doing much of anything or working particularly well, because customer loyalty means nothing to me. I’ll just write a different app next month that looks cool… there’s always new customers!” You can already see this mind-set in many apps on the App Store today — I call this “crapware,” and unfortunately the current Mac App Store accidentally encourages crapware by not allowing paid upgrades.
The SolutionThe Mac App Store should allow developers to submit, with our applications, a list of our other applications from which the user can upgrade, along with a separate price we’d charge people who already own those applications.
So, for instance, as a developer I could say to the Mac App Store, “When someone buys ‘Delicious Library ∞’ who has bought ‘Delicious Library 2,’ it should cost them them $15. Leave our version ‘2’ page up but don’t allow any new sales of it, and mark it as obsolete.” (In this way existing version “2” customers can still be updated (for free) with bug fixes even if they don’t upgrade to “∞.”)
For customers, the Mac App Store application would notice when a product they’ve bought has an upgrade path to another application, and show this in the App Store application’s existing “Updates” tab. This alone would be a huge boon to developers, because users would have a single, wonderful place to find out about new paid upgrades, which we can’t have right now because we don’t have a list of our customers! (And, again, we’re not Apple: when we release a new version of Delicious Library it doesn’t make international headlines. Yet.)
As a nice side-effect, this solution would also allow the Mac App Store application to notice when a customer has both an old and a new version of an app installed, and provide an easy way (again, from the existing “Updates” tab) for the customer to delete the old version (and its old data if it’s a “shoebox” app) when she’s gotten confident that the new version is meeting her needs. This solves an issue every customer and developer wrangles with: how to gently keep customers from running outdated versions of their apps (and how to free up the customer’s disk space from the old version) after they’ve upgraded.
There are obviously lots of cool bells and whistles Apple could add on top of basic upgrades (different prices from different apps, cross-grades from competitors, side-grades to allow for building simple bundles, etc), but even the most basic of paid upgrade paths would be an absolute godsend for all developers.