In App Purchase - A Bag Of Hurt
With the latest iPhone OS update has come a raft of great new features and improvements, including a particularly interesting one for developers who’d like to offer services which previously didn’t fit with the App Store’s one time purchase model: In App Purchase.
This gives developers a way of charging users for content and consumables though a users existing iTunes Account, with Apple acting as payment processor (for a not insignificant 30% cut). In the In App Purchase system, Apple are not responsible for delivering that additional content, they simply approve and handle the payment, developers do the rest.
One of the things Apple has stressed with this new system, is that they don’t impose a business model on developers.
But there’s an elephant in the room, and it’s trumpeting, and occasionally showing people with mud and water. It seems Apple have made a habit out of either ignoring or overlooking these elephants recently.
The rule of In App Purchase is that it is ONLY available from within paid apps. So lets see, that rules out perhaps the most common business model for software ever! Free to download and test, pay to continue using (try before you buy, shareware). A curious caveat given Apple’s masterful leveraging of this exact strategy, in an extremely successful way. Apple retail stores are founded on this try before you buy strategy. They load up their stores with as many products as possible, all tricked out with unlimited versions of their pro apps for anyone to come in and try out in all their glory, before taking the plunge and purchasing. Yet iPhone developers have no way of implementing any sort of demo or try before you buy scheme in the App Store. Apple go even further, seemingly going out of their way to prohibit it with this latest In App Purchase requirement. So much for not imposing a business model.
So what about subscriptions, that’s another popular business model, especially for content and service oriented apps. Developers have been asking for this capability from day 1 of the App Store. Let’s see how the new In App Payments options work for this. The first thing to note is that there is no concept of a subscription in the In App Payment API. As far as Apple are concerned it’s up to developers to implement tracking and re billing if they want to offer subscriptions. Sounds like a great customer experience so far: they sign up on a per month cycle, and developers have to keep annoying them with alerts to manually renew before they lose access every month. That may suit some customers perfectly, but a lot of customers just want set and forget: just bill me at regular intervals until I tell you to stop, ie a true subscription. Really what they mean by subscription, is that they make it possible to pay for an item more than once.
But don’t forget with subscriptions, developers are still required by Apple to have a paid app in order to offer this. This is where things get really dangerous. This is guaranteed to be a huge source of complaints and malicious customer feedback. Apple have been touting “free apps will always remain free”, arguing that when a customer downloads a free app, that they expect to be able to use it for free permanently, hence they will not allow In App Purchase in free apps. They’ve got this wrong. 100% wrong. In fact it’s the total opposite of the reality. iTunes store customers are accustom to purchasing apps at a one-off price. When they see an app priced at $0.99 they expect that the app is just that, $0.99 and they expect to be able to use the app in the same way in a year from now as the day they purchased it, without paying anything else.
So lets take a look at just one specific example of a typical subscription based app. Our latest app “Tweet Push”. It takes advantage of push notifications to provide Twitter users with alerts on their iPhone / iPod when they have new mentions or direct messages waiting. As this sort of service has an ongoing hosting cost for us, we offer it as a subscription, $0.99 per 30 days per Twitter account. Ideally we’d give the app away for free, users could then see and play with it before handing over any money. Once they decide they want to setup their twitter account to start receiving notifications, they’d be prompted to select how much credit they wanted to purchase. At this point, if they hadn’t already realised that this was a subscription based service (everyone reads the iTunes description right?), they’d now clearly know, before they actually hand over any money, that this was a subscription service, and could either continue, or delete the app if they so chose. If they do delete it, they’re not out of pocket, no harm done. But Apple require that this app be paid, not free, in order for us to offer In App Purchase. So lets look at that again, the same user downloads the app for $0.99 assuming it’s a one time payment, then launches the app to find that he only gets 30 days of service for the $0.99 he just paid. Furious he leave one star reviews all over the place even though we went to great lengths in the iTunes description to spell out the exact nature of the subscription and costs (but no one actually ever reads that stuff). The customer feels cheated out of his $0.99. Contrast that to the hypothetical customer who downloaded the app for free, and later discovered that it’s subscription based, he isn’t really that concerned because he’s not out of pocket.
This is just one of a few scenarios where the In App Purchase in paid apps only policy is just plain dangerous. Apple is forcing developers to dance precariously on the bait and switch line, with this totally artificial constraint. So much for not imposing a business model.
It’s clear from the vocal reactions at WWDC developers think this is ridiculous. Hopefully Apple rectify this quickly. This really is a bag of hurt waiting to happen, and everyone but Apple can see it.
All of this boils down to this point: Apple seriously need to consider their approach to the App Store, and urgently need to get developer input into how the store is shaped. I’m not talking about design by committee here, but we’re out here living and breathing the business around the App Store, and are begging to provide constructive and valuable feedback from a perspective which Apple simply does not have. We analyse this stuff to the nth degree because it’s our livelihood. Apple: you’ve assumed total control of app distribution, just remember with great power comes great responsibility.