65% of revenue in Apple's App Store comes via in app purchase (IAP). This system is a fantastic way to monetise your apps which provides a slick experience for both the user and the provider.
However, it is not as straight forward as you might hope.
There are one or two ambiguities to watch out for.
Based on my experiences developing an iPad app, here are some things to watch out for...
I frequently speak to clients about how to monetise their mobile strategies and actually see a ROI from their mobile endeavours.
We are now in a post app gold rush world, $1bn acquisitions of companies with no revenue aside. The days of publishing an app to make bathroom related noises or to add a few pounds to a photo of your friend, leading to a license to print money are dwindling.
Now is a time where your mobile strategy needs to have clear measurable goals, derived from actual business objectives, that lead to a real terms return on your investment.
Publish to the app store = license to print money is a myth that I spend a lot of my working hours dispelling.
There are a number of ways monitise a mobile app, and "In app purchase" (IAP) is proving to be very lucrative solution for many.
However, there are a number of potential pitfalls to negotiate if you are to successfully make the most of such an opportunity, particularly when considering publishing for iPhone or iPad as Apple have not made this as easy as they might.
I have been working with Simpl to develop a website-building iPad app aimed at those users for whom even the likes of Wordpress is a little too techy. The brief? Make it Simpl.
And this is something which we are very proud to say that we have achieved. After all, it's not easy to create something simple.
Keep it simple
The idea with the Simpl app was to tie this into 'in app purchasing' thus utilising the users existing iTunes account to managing the recurring payments for hosting and one off purchases of themes.
Altogether, a very simple process but here is where we hit a problem.
The rules surrounding IAP and subscriptions are a little on the grey side and consequently our initial attempt to publish the app failed.
As a result we had to systematically rip out and throw away a considerable amount of work and so I thought that it might be worth highlighting some of the issues that you might face if you are considering using in-app purchases as a means to generate revenue from your app.
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% 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%, especially when handling international payments.
This all sounds great but there are a couple of problems. The first is down to the way that 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 grey 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 grey areas, while restricting lesser known developers with red tape.
I actually don't mean to sound harsh here. I appreciate the way Apple controls 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 there are some things that you should be aware of.
It's all a bit grey
The ambiguity surrounds these sections of the apple developer guidelines.
- 11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected.
- 11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected.
To try and explain; you have to use in-app purchasing if you are making additional content or functionality available in-app. You are not allowed to use an external payment wall to enable such content or functionality.
Also, you are not allowed to use in-app purchasing to allow the user to pay for content or services which are external, used outside of, the app.
The trouble with Simpl was that it fits nicely between the cracks. App functionality and content (themes and publishing) need to be purchased using IAP according to 11.2.
However, as published websites, and applying themes to them, could be termed as physical goods or services, the use of IAP could be rejected in 11.3. The main problem is there is no way to confirm this without trying it out.
In-app subscriptions were made available to developers in iOS 4. However, a slight breakdown in the English language makes it a little unclear as to what a 'subscription' is. It seems that when Apple refers to such a thing it is specifically talking about digital content. i.e. a magazine subscription.
They do not allow a subscription to a service such as what Simpl was trying to provide. We are not the first to fall foul of this confusion. We recently came across this blog post by Instapaper creator Marco Arment.
The inconsistency of Apple's process
In the post we learn of Instapaper's frustrations but are also offered a window into the inconsistency of the process. Its end result was different to ours.
There is frustration in the inconsistency. It seems that IAP can be used by dropbox despite the fact that they are selling an external service. Instapaper is also selling a service via IAP, albeit via sightly different terminology.
There are also a number of other, lower profile apps, that are using IAP to do very similar things to what we were trying to do with Simpl. These seem to have just slipped through. T
he rules themselves are not a problem. Apple can, of course, do whatever they want in this regard. The problem is that they are grey and inconsistently applied. This leads not only to frustration but significant cost in terms of both time and money.
The first time that we attempted to publish Simpl we were rejected for using IAP to sell an external service or product. The second time we were rejected because of a problem with our meta data, which is fine, but the comment included a note suggesting we switch our sales from being based on the website to IAP!!! Two different reviewers I guess, but again, frustrating to say the least.
Broken apps
The net result of these rules is that apps lose out. For example, the Netflix app is broken; you have to go to the website to subscribe to the service (or at least you had to at the time of writing).
The Amazon Kindle app is also broken. Apple won't even let these apps 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. It's the user experience that ultimately suffers in these cases.
I can understand, although not condone, this approach. Apple offers videos via iTunes and eBooks via iBooks and doesn't want to make it easy for 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 have 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 things like donations to charities 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.
IAP Check-list
This is something to watch out for. To be safe you must consider the following:
- If you are selling content or functionality to be used within the app then you MUST you IAP.
- If you are selling content or functionality which can also be used outside of the app then you CANNOT use IAP.
- If you allow the user to view paid content from within the app, that is purchased outside the app, you CANNOT link to the means of purchasing the content from your app.
- You CANNOT use IAP to sell subscriptions to a service.
You will find exceptions to all of these rules and you might get lucky and be allow through. But you have been warned.
Rob Borley is Founder / Director at Dootrix Ltd and a guest blogger on Econsultancy.
No hay comentarios:
Publicar un comentario