Menu
Get the latest news and updates! Sign up for our mailing list!
First off, I should state up front here that I have not actually tried this myself, nor have I had any indication from Apple that they would actually allow this in the App Store. Consider this more or less a thought experiment that I think is useful to share with you, gentle reader, in the hopes of expanding both our minds, and in the hope that someone, somewhere, will try it, and see what happens!
So, that said, your mileage may vary. Offer void where prohibited. This post contains chemicals known by the state of California to cause cancer. Wear protective clothing when handling.
Now… to the meat.
A common discussion point among App Store developers is the point that one can’t do paid upgrades of your application without releasing a totally new version, which has, in some cases caused strife and complaints from end users.
“Why,” they ask, “must I pay full price for the new version when I already own the older version?”
Some have rightfully pointed out that this is a little bit absurd, considering the low price point of most iPhone apps. But nonetheless, the issue is there. And indeed, I would agree, that at the least, it sure would be convenient if the App Store provided some mechanism that at least let developers give a discount to existing customers while providing full functionality to new purchasers.
I should probably explain what I mean here, to make it clear exactly what I am talking about.
Traditionally, desktop software has followed a model of charging for upgrades. Indeed, arguably, this is the only way most software businesses stay in business. However, in order to encourage customer loyalty, they normally give a discount to existing customers in the form of “Upgrade Pricing”. Thus, the user, when purchasing the software for the first time, pays full price, but when upgrading, say, from 1.0 to 2.0, they pay a discounted upgrade price.
The App Store has not had this sort of capability, and in fact, I think this is one of the things that many iPhone devs have nighttime sweats about.
In-App purchasing has seemed to be a possible solution to this conundrum. It has promised the ability to “up sell” content in apps. But it still forces you to treat all your customers at the same level. There’s no “built-in” mechanism that enables you to say “This customer has had this software since version 1.0, I’m going to offer them a discount on this upgrade.” Or, conversely, “This is a brand new customer, I’m going to unlock all functionality, because they just paid the full price on this version.”
The second statement may sound confusing, so I am going to explain it in slightly more detail before I proceed to make sure it’s clear.
What I think developers really want is to have the ability when releasing a new version of their app to charge new customers and existing customers different prices. For new customers buying the app fresh, they get all the features in the app and pay the “full current price.” For existing customers, who purchased a prior version of the app, they want to provide a way for them to “upgrade” at a discounted price and get the all the same features of the person who just bought the full version.
This business model allows a developer to release a version of their app that is less functional (due to less time spent developing it initially) in the beginning, then, over time, add more features to the software, and release an upgrade that perhaps even raises the price of the app, while crediting existing loyal customers for their previous purchase.
In other words, imagine an app which ships with feature A on version 1.0. Perhaps that feature is worth $.99 to begin with. They sell a few thousand copies.
Eventually, they release version 2.0, with features B and C. The addition of these features makes the app now worth, say $2.99.
The developer now has two choices. He can release version 2.0 as a new app, which means all his customers will have to pay full price for it. Or, he can give version 2.0 to his old customers basically for free, even if the customers might have been happy to pay the difference in price for the new functionality. Thus, leaving money on the table.
To be clear, if the developer is thinking he will make 2.0 a new app, existing customers will wind up paying the full $2.99 for the new app! This is in addition to the $.99 they already paid! This basically penalizes loyal users and is exactly the problem that Tweetie ran into. If the developer chooses to just give away all upgrades for free forever, he will probably eventually go out of business, which also penalizes users since they’ll no longer be able to get great software from this developer.
What’s a developer to do?
There is a possible third scenario, however. One that matches the traditional model very closely.
What the developer in our previous example wants to do is to charge $2.99 to new users, but for existing users charge say, only another $.99. Thus, the existing, loyal user is only paying a total of $1.99 (a nice discount for getting in early) and new users are paying the full amount.
With the In-App purchase system, developers can charge users for the “new features” in their apps. How those features are unlocked is entirely up to the developer. Additionally, what the developer sells is entirely developer-defined as well. Meaning, you absolutely CAN charge existing customers an upgrade fee if you can somehow determine, reliably, if a customer has been running you app prior to this new version or not.
I talk about this a bit in my book , but I’ll reiterate it here for the purpose of discussion. Unlocking paid content in applications is entirely implementation defined. Most developers, I imagine, will use something like NSUserDefaults to set boolean values that are checked at runtime to allow or disallow content that has been purchased to be displayed.
Given this knowledge, you CAN ship a new version of an app with new capabilities in the application, and if you can determine if the user has only just now purchased the app, you can choose to set the flag that enables all functionality. If the user is an existing customer, you can offer to sell them the “upgrade” (at a discounted price) and if they choose not to take the offer, simply leave them with the same features they had before.
This is sort of a weird, backwards way of looking at how In-App purchased content is typically enabled, but in this case, it works.
In this way, you both reward the existing customers with a lower price for the new features as well as charge new customers the full price for all the features. This is, basically, the traditional model in App Store form.
The key then to understanding the problem we need to solve is this: How do you reliably determine if a user is new or not? The naive response might be simply to set a flag, again in NSUserDefaults, but the problem with this approach is that the user could wipe out the defaults by simply uninstalling the app before downloading the update. What is really needed is an external storage mechanism which stores information about when the user originally installed the app, and the device it was installed on. In short, it needs activation.
Now, I should take a small side trip here, and just point out, I hate activation as much as the next guy, and I’m not really sure I’m advocating this. Again, this is a thought experiment. The fact is, however, this would work to solve the problem.
To implement activation, you could simply have your app ping your server (with user permission) when it is initially started. As part of this ping, you could have the app
send the UDID of the device and the version of the app that is installed. This information is then stored. When new versions of the app come out, the app can ping again, and the server can respond with whether or not this user has previously activated the software on this device. If they have, then you can consider them an existing customer, and offer them the upgrade pricing, If they have not previously activated on this device, you can consider them a new user, and unlock full functionality.
Using this mechanism, you can accomplish discounted upgrade pricing for existing users, and full paid pricing for new users. Exactly the way existing software businesses work.
Again – would Apple allow this? No idea. Hoping someone will try it and see.
You could possibly also leave a KeyChain entry. I think that'll survive the uninstall, but I'm not 100% sure.