Having recently done a whole bunch of work with in-app purchases that had to be systematically ripped out and binned, I thought that it might be worth highlighting some of the issues that you might face if you are considering using in-app purchases (IAP) as means to generate revenue from your app.
The Current State of Play
The current state of IAP is both confusing and limiting. On the surface it is an excellent method for generating revenue. The user is not confronted with any kind of payment wall, they don’t need to enter additional login details or credit card numbers, and the transactions all go via a provider that they already know and trust with their money. As a seller you don’t need to be concerned with payment gateways or billing systems; If you are happy to let Apple, Amazon or whoever take their 30 percent cut of your IAP revenue then it makes good sense. It also compares favourably to PayPal and other online payment providers who often take more than 30 percent, especially when handling international payments.
So, what’s the problem?
Well, there are at least two. The first is down to the way Apple tightly control what you can and can’t do through IAP. There are rules of course. You can look them up. But they are quite gray around the edges and either the reviewers have a hard time interpreting those rules or Apple favour some of the big players, letting them exploit the gray areas, while restricting lesser known developers with red tape. I actually don’t mean to sound harsh here. I appreciate the way Apple control the user experience and I can genuinely see why the majority of rules are there. However if you want to use IAP for subscription based products and services then you should definitely pay attention…
In-App Purchases and SaaS
One major problem with IAP, and particularly subscriptions, is that they are restricted to offering content that has to be ‘in the app’. This rules out every single software as a service offering. It’s a frustrating limitation meaning that you can’t use IAP to purchase subscriptions to anything other than…well mainly digital magazines and newspapers. The two, rather confusing rules in question are stated as follows:
- Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected
- Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected
So, the first rule says that you can’t use any other system except IAP to purchase a service. But the second rule prohibits the use of IAP to purchase a service (or physical goods)…? Ah! but this exceptionally confusing vicious circle does have a break out clause. If you look carefully at the second rule it says “used outside of the application”. Which is just as well. Otherwise every type of ‘service’, such as a digital magazine subscription, would be prohibited. Still, surely there has to be a way to make this clearer…or maybe I’m just not getting it? I certainly wish I had come across this blog post by Instapaper creator Marco Arment before we had submitted our last app.
The net result of these rules is that apps lose out. The Netflix app is broken; you have to go to the website to subscribe (or at least you had to at the time of writing). The Amazon Kindle app too is broken. Apple won’t even let these app’s link to the corresponding website. They must have a plain text message that tells the user to visit the site to download content and/or subscribe.
I can understand, although not condone, this approach. Apple offer videos via iTunes and eBooks via iBooks. They don’t want to make it easy for their competitors. But there are plenty of services that don’t compete with Apple that are forced to make use of ‘broken’ apps. As an app developer this is even more painful when you get reviews coming back from users complaining that they can’t subscribe from within the app. Just read some of the reviews for the Kindle app. The thing is, it’s not the apps fault. It’s Apple’s fault. But the users can’t be expected to understand this.
These kind of restrictions prevent e.g charities from sponsoring X,Y or Z from within an app using IAP or in our case, website hosting companies from charging for monthly hosting. The alternative is to use third party payment systems, degrading the user experience and, bizarrely, taking money away from Apple (not that they will miss it!).
The other problem I wanted to mention is tax. On this issue Apple does well; it makes sure the correct tax is charged in relation to all the markets the app appears in. However, Google does not seem to offer any assurances on this matter. I get the feeling quite a few people assume that Google deals with the tax on IAPs but this does not seem to be the case. In-fact, quite a few people either don’t release apps via Google’s store or simply make them free to avoid having to cope with the tax headache that ensues from selling your product in a global marketplace.
So all in all, IAP can be a bit of a mine field unless you are developing a game or some kind of digital publication. I would dearly love Apple to allow IAPs to be used with the software as a service model…but I don’t see that happening anytime soon.
Whats Your Experience?
What about you? I would love to hear other peoples experiences of IAP for more business focused type apps. Did you slip through the net? Did you have to grapple with the submission process and the confusing rules? Did you have to deal with unwanted tax issues? Did you groan at the loss of time and money spent removing large chunks of code from your app? I know I did. Why not share the pain?