So Dan Counsell kicked the hornets' nest again regarding MAS upgrades.

I know there's always been abandoned software and there always will be. It just feels like there's more of it now than ever before. Why is this?

One of the main culprits is the lack of paid upgrades on the Mac App Store.

Whoa. Any time you blame Apple, take a step back^[1].

Aren't there ways to provide paid upgrades? I mean, really, is it that complicated to dream up a way to include paid upgrades using In-App Purchases (IAPs)?

I understand that the MAS doesn't have a simple mechanism for making app upgrades, and is pretty clearly trying to, at least implicitly, encourage you to make software that your user buys only once and receives free upgrades forever. I understand that this isn't sustainable for indie devs, but I also know we're smart enough to work around it.

The problem's solution

So let's say I was, I don't know, writing an email client that I release just before or during 2016, and it costs you $55. It turns email from timesink to a thoughtless extension of your mind, and you can't stop yourself from clicking Buy.

During 2016, I code like mad and add a host of new features. Heck, let's get crazy and say I rewrite the entire app (btw, never do that). Now I want to release EmailClient 2017 for $55 for new folks, but only $10 for you, my loyal customer.

Seems easy on its face, doesn't it? I keep EmailClient on the MAS. It now has an IAP called, "Super Groovy 2017 features" that runs you $10. But, get this, if you never had the app installed, you get these features for free! Wait, what? Wacky, huh?

Implementation

The "only" problem is implementation, and yep, it's a problem^[2]. But isn't that what we do? We solve coding problems.

How could we do it? Well, if you have an email client, you have all sorts of methods, the most straightforward probably being to save a hash to a sandboxed folder with some user-identifying info, some salt, and the date of first use. And any app could do this reasonably safely, even without a simple web service, making the unlock of new features difficult, though obviously not impossible, to crack.^[3].

Poof. We have upgrade pricing. Right? I mean, it's a little code smelly, but we have it.

EDIT: I guess there's one issue -- we'll have an IAP those users don't need to buy. That's a tough call; I haven't played around with IAP on the MAS yet. Any context there? Can you hide an IAP inside of the app? Or direct folks directly to the IAP? I think the only IAP I've done is a tip for Pedometer++, and it seems like he had links to each option, which is very much like the prereq IAP stacking I mention, below.

The absolute worst case here is that we have to ship two apps painfully grafted into one. I've heard horror stories (particularly from the Core Intuition folk, if my memory serves) of moving from long untouched libraries to the recent ones, keeping old versions of XCode and OS X laying around to do emergency patches, and other related issues. I'm not sure you could ship some of this obsolete stuff easily in an app that's targeting 10.11.

Which brings me to the other upshot of this plan...

Eventually you're going to give it away for free

Maybe not in 2017, but at some point, maybe three releases later, I'm going to give everyone what's in EmailClient 2017, and give it to them for free. That is, you don't want an IAP list that says, "EmailClient 2017 Features, $10 -- EmailClient 2018 Features $10 -- EmailClient 2019 Features $10". If they didn't upgrade in 2017 or 2018, sort of like the license crackers, are they really in your market? They paid once. Why not give them a two year-old set of features?

And there are going to be times when it doesn't make sense to keep bundling together Frankenstein with the original parts. Occasionally, you might need to update EmailClient Y-1 to keep the tech stack in line with this year's EmailClient Y, but now that releasing grafted upgrades is your actual strategy, you can code defensively so that you minimize code that goes obsolete next year. Sometimes it's not going to be worth the trouble to make Y-1 play nicely with Y, and you'll be stuck. Let's just hope that, for the most part, your code from last year doesn't go obsolete within 24 months in impossible to fix ways too often.^[4]

I'm not sure if you can "stack" IAPs^[2] -- that is, require that users have EmailClient IAP 2017 before they can see EmailClient IAP 2018. I'm guessing you can't create "prerequisite IAPs", or I would've heard of a game doing it somewhere. "Want 400 gems for $5? You can, but first you've gotta buy 100 for $10!" Or worse: "$20 to unlock 1000 gem packs for $1!"

But not having IAP prerequisites isn't that bad, is it? And if things ever get so gnarly that you don't want to give something away for free, well, you have other options.

• You can pretend you're right back where we started, which is the worst it gets, and decide to release a new "EmailClient 2019" SKU.
• You can get clever and ensure that the features from 2019 can be used independently of features in 2018 (throwing in the subset of '18 features required for '19), and let users buy either. Which is to say that...
• You can have an IAP list that looks like instructions to a Rube Goldberg machine.
• You can get even more clever and hold back some features unless both 2018 and 2019 IAPs have been purchased. (Make sure your remind your 2018 & '19-only folks that's the case!)

There are nearly limitless ways to approach this problem. And, again, that's what brings us to the keyboards each morning, right? Fun, clever solutions to real-world problems. I mean, heck, Overcast already figured out how to perform an end-run around trial apps. Why can't we do the same for paid upgrades?

Reviews

Which is not to say the MAS doesn't still stink for new releases. This ycombinator comment in particular pains me:

But on the Mac App Store it takes months for an average application (read: one that is not permanently featured by Apple) to acquire said 5 ratings.

So you think twice about pushing out an update to your app when the current average rating is 4 or 5 stars. Because once your average stars are gone, your app doesn't look very different from any other 0 rating app... and it's pure luck if the user likes your icon enough to click on it. (Which measurably impacts sales numbers).

I see this with my own software... I once made the mistake to update a well rated app and sales plummeted over the next few months until the app could re-acquire 5 ratings to show an average.

I can see that. I wonder what percentage of folks review what kinds of apps. I have no idea.

I guess this just gives more weight to the lesson I hear everywhere: You have to advertise outside of the MAS to sell MAS apps. The MAS is one and only one of your storefronts (was it Liscio who built up this metaphor? He's been everywhere (#70) recently). You send trucks full of software there, but you're still responsible for convincing people they want to buy. If you count on Wal-Mart's shelf placement to sell your goods, you're not doing enough to grow your business.

Which is not to say we shouldn't keep challenging Apple to make the stores better. Which was Counsell's point all along, I think.

(Btw, if this is the first time you've read my blog, there's a decent, just under 110%, chance you won't want to read everything, which is pretty heavy on "notes to self" style posts. You might prefer to watch just the indie tag instead.

Unless you're Sam Soffes, in which case, if you're not as laid back (in that good way) as you sound, you might take this post badly. But then you could destroy this site's beautiful design, basically unchanged since 2001, and make up for it pretty quickly.)

Yes, the parenthetical in the title is supposed to remind you of Loser.

^[1] I think it was Charles Perry's AltConf talk that had some number like 0.01% of surveyed iOS App Store authors considered their apps financial successes. If you ask me, that's a pretty good explanation for all the abandonware. That and the fact that as the store progresses, by definition there are going to be more abandoned apps. I'm guessing there are very few resurrections. So don't get too down on the app store yet! (Perry's slide is below. Go watch his talk, and then a few more from AltConf too!)

^[2] Now is as good as any to admit I'm a C# guy just starting to write for OS X. Yes, I'm using Xamarin in the hopes that makes going crossplatform much easier. That said, I've used Macs for years, and have even contributed to a few Mac sites and a [trivial] piece in the Mac Bible's 6th edition, but in many places here, I'm talking without platform-specific knowledge of what the implementation would require.

^[3] I've been told that a lock is designed to keep an honest [hu]man honest. I think that's fair. We're doing the same thing here, because, honestly, what percentage of crack-artists were going to pay for your app? It's not zero, but it's also not close to 100%.

^[4] If you find that your code is going obsolete every 18 months, you might need to reconsider your dev workflow. ;^)

Labels: app store, business, indie, long