Polar Bear Farm

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.

Layton Duncan

5 Responses to “In App Purchase - A Bag Of Hurt”

  1. Caleb Says:

    Amen, I still can’t believe with the add-ons Apple still gets 30% but they no longer take care of all the things that made it a great deal before all the hosting and such of the content. It’s causing me to reevaluate an application that I have that accesses data online, soon I’ll be able to bundle the data with the application. It’s almost better to make an entirely new app that charges a higher price for the convenience than to build this functionality into the existing app as a paid upgrade.

    Though I could see so many developers who are short sighted about things turning everything into a scummy add-on if the rate were any less. Apple would do well to have interviewed developers and learn what sort of business models they want. The business models in place and being encouraged have the stink of too much MBA and not enough of the interests of the developers and users.

  2. shanec Says:

    I think if free apps are allowed in-app purchase the entire economics of the store will change to the traditional shareware model, the quality of the apps on the store will rise, and customers will generally be happier. However, I also think that Apple may be concerned with this model since they still have to pay for all the download bandwidth for what would become a predominantly free store. Not to mention that in-app purchase adds some overhead to developers when adding it to an app (coding logic plus tracking of purchases) and this would tend to hinder some devs ability to publish on the store. In the end I think allowing free apps to do in-app purchase would be a good thing but that Apple will take a go-it-slow approach as they do with many things.

  3. bugeye Says:

    Thanks for the post. My partner and I are having a similar dilemma with our forthcoming app, which uses push notifications. Luckily, our app is still somewhat useful without the notifications, so I think we could manage to sell it for a small price and then offer the push service as an add-on.

    I think Apple is afraid that if people could try before they buy, even with 1 or 2 dollar apps, that they would lose the benefit of impulse purchases. I have bought many apps that I rarely, if ever, use today. Would I have spent the money if I could have tried them first (I’m looking at you, super monkey ball)?

  4. Redth Says:

    I agree completely. I’ve been saying this from day 1. I’m most annoyed at how they handle subscriptions though. Or don’t. It would have been way easier for them to put right in the app store $0.99/month so the customer knows rate away what they’re getting. Let’s not forget we’re not allowed to put pricing info in the app store description, so we can’t really even say more to potential customers other than “this is a subscription based app”, which who knows how effective that will be.

    I too have a push notifications app, and a business model of selling an app for a one time price and then supporting it with ongoing costs just doesn’t make sense.

    So now, I need to nag users every so often to ‘purchase’ more time, I need to incur more costs by tracking subscriptions myself, and the user by no fault of my own, is not very well warned what they’re getting into when they pay for the app in the first place, since I HAVE to charge them for it.

    Apple screwed this one up big time.

  5. App Store: 1.5 Billion Apps Served - Blog - 148Apps - iPhone App and Game Reviews and News Says:

    [...] there are many discussed problems with the app store from a developer prospective, it has really taken off with consumers. The word [...]