When I purchase a new mobile phone on a contract, one of the little footnotes so handily provided is a minimum total cost disclaimer. For instance, in February, the document I signed for a new phone stated “Minimum cost over 24 months … is $1,920”.
It’s easy to enter into a contract with regular payment options clearly stated, especially when the total amount to be paid is spelled out. It’s equally easy to enter into regular payment options for regular, recurring charges. For instance, I pay $12.99 US per month for my CrashPlan backups; I pay $12 AU per month for Microsoft Office Live – and the list goes on.
Even easier though is the unknown contract, especially if it starts with the ‘free’ carrot. It’s what has been for some time been called freemium:
Freemium is a business model by which a proprietary product or service (typically a digital offering such as software, media, games or web services) is provided free of charge, but money (premium) is charged for advanced features, functionality or virtual goods.
(Wikipedia, “Freemium” – see link above.)
Perhaps no-where else has the freemium model been so popular, and so successful, as Apple’s in-app purchase system. (NB: I hope to never have to use ‘freemium’ again, after I’m done with this article.)
This is often lambasted in the press. Periodically there’ll a near-histrionic article in the media about parents who let their kids go wild with their iPad or iPhone and ran up a huge bill – yet realistically, these days, parents need to understand that handing over their iTunes account password is the same as handing over their credit card. I.e., that’s about user education.
While the rest of this article uses Apple as the example, let me be clear: it should apply to all systems where in-app purchases are permitted. It’s just Apple needs to lead the way.
As the in-app purchase model grows, we need to also grow the maturity in the payment system to something business-appropriate. At the moment, it’s not – it’s wild west, hell for leather; whatever analogy for chaos and lawlessness you want to use, it’s that.
The solution is requiring full disclosure when there are in-app purchases.
There’s three types of apps we need to consider here, and two different ways of dealing with full disclosure.
The good guys in the in-app purchase model are usually of the type where a single payment (or breakdown thereof) is required to enable full functionality. An art app, for instance, may come with minimal options, but you might buy different brushes and effects for $1.99 each, or a $9.99 pack that enables everything. Or, you might have an app that uses ads, and you can turn them off for a $1.99 in-app purchase.
These are the good guys.
For these cases, the easiest way to achieve full disclosure is to have the developer state the minimum spend required to achieve full (permanent) application functionality, without advertising. This should be listed not as “top in-app purchases”, but as part of the general information, such as category, rating and intended age group.
The bad and the ugly
The ugly category is typically full of games where you need to periodically purchase upgrades and new options. “Armour” for $0.99, “Super Armour” for $1.99, “Super Duper Armour” for $2.99, and so on.
The bad category is reserved pretty much exclusively for any game where the user has to buy money: a carton of cash, a pot of gold, a bucket of gems, a pile of crap. In the end, they’re designed to encourage regular, on-going payments to the developers.
Full disclosure here won’t be achieved by application developers – while some will undoubtedly be honest about it, the nature of the purchase options provided in-app demonstrate to us that many will be substantially inclined to downplay the amount of money spent in-app. For example, left to their own devices, many game developers might say their game could be completed without any in-app purchases … even if that takes 10x longer than regular game play.
So for the bad, and the ugly, there needs to be a mix of developer supplied disclosure and Apple supplied disclosure, being:
From the developer
- Any initial spend required to achieve minimum app/game functionality.
- A manifest of all in-app purchases that can be made. All.
Apple facilitates the purchases and collects information already – we know this from the “Top In-App Purchases” section in iTunes for any such app. Apple needs to expand on this and provide Day/Week/Month/Year tables of:
- The most money spent by an individual user over that time period;
- The average money spent by an individual user making in-app purchases over that time period.
Arguably, Apple also needs to enable the setting of per-app limits, or per-account limits, similar to proposed gambling reforms, viz.:
- Allow the account holder to specify the maximum spend allowed for a given application over a period of time (e.g., 1 month);
- Allow the account holder to specify the maximum spend allowed across all in-app purchases over a given period of time.
There’s a bunch of great apps out there, and there’s a bunch of great apps that are using the in-app purchase system honestly and ethically. But not all of them, and without regulation of some kind, it’s only going to get worse. Requiring the user to enter the account password every time there’s an in-app purchase just isn’t sufficient. It’s the equivalent of the Windows UAC.
As the store provider making the most money from this model, it’s up to Apple to establish a more mature approach to the model – to set an example for the rest of the industry to follow.
And it’s up to Apple to do that now.