Why In-App-Purchase is a Mistake
Thinking about using In-App-Purchase (IAP) instead of having separate free and paid apps? My advice: Don’t do it.
In the App Store, the original way to offer a demo was to have a free (“lite”) version of your app to convince people to buy the paid (“full”) version. Apple introduced In-App Payments (IAP) with iOS 3.0 for paid apps and a year ago (Oct 2009) allowed it to be used with free apps as well.
In theory, IAP sounds great. Users download a free app, and if they like it they can buy the full version right from within the app. And developers only have to deal with maintaining a single app instead of a free one and a paid one. Unfortunately, IAP is a disaster in practice. I have built two apps using IAP, so let me show you the scars.
Poor ranking
We all know that being highly ranked in the App Store is key for visibility and sales. The ranking algorithms are secret, but it’s clear that paid apps ranking is based on units sold and the gross sales over a period of time. For free apps it is simply units downloaded over a period of time. So, how are free apps with IAP ranked? Unless you have a 100% conversion rate, you will be at a disadvantage being compared with the other paid apps. And since your app isn’t a fully free app in the traditional sense (ad supported or is subsidized by another business e.g. skype, twitter) it will have limited functionality and probably won’t have same number of downloads. So you are disadvantaged in the free rankings as well. Look at the top 25 free apps, how many use IAP? (At the time of writing, I see 5.)
Less “shelf space”
With a free and a paid app, you have two products - and each one shows up on the free and paid lists. The App Store defaults to showing “paid” apps, so with IAP, you are only on one list and you’re not on the default list.
Wrong kind of customers
Yes, you need customers, but you also need the right kind of customers. From my experience, people who only download free apps are more likely to gripe that $1.99 is expensive or demand features x,y,z before they pay. But they’ll never pay. Downloading and installing apps is just something to do, like flipping through channels on the TV.
The freebie folks also have no real investment in the app. If they download it and don’t see the immediate use in 3 seconds, they will delete it and leave a 1-star rating. This would still happen with the free and paid app scenario, but then at least the 1-star ratings wouldn’t drag down the average rating of your paid app.
No gifting
You can’t give an IAP as a gift. Don’t expect a bump in sales at Christmas.
(Gifting is also a handy promo code substitute for developers outside of the US.)
IAP is more complicated for users
Even if the IAP interface is just some text, a buy button, a busy indicator, and a status message, users will have to learn how to use each developer’s IAP interface. Why introduce this friction when they already know how to buy in the App Store?
IAP is added complexity for developers
Apple provides a nice StoreKit API and lots of boilerplate sample code you can just paste into your app, but it still adds complexity. First, as mentioned above, you need to build a little interface to show the description and some status messages and find a place for it in your app. You also have to store the fact that they’ve upgraded (e.g. isPro=1) and elegantly handle the transition from free and the paid states (e.g. add items to toolbars). Testing is also extra work, since you need to create iTunes test accounts and you definitely want to make sure you that the upgrade process still works after any major code changes.
You also want to make sure that you actually sell the upgrade. If you aren’t making it blindingly obvious how to upgrade (and what you get) then it is too subtle.
IAP lock-in
Once you’ve gone the IAP route, you are stuck. You can’t rip out IAP and start charging for your app without giving it away to all the people who downloaded it for free. And you can’t make a new paid app without abandoning the people who already paid via IAP.
The only reasonable path away from IAP that I can think of is to make a paid version, remove IAP from the free version (but continue to provide the pro features to those who have paid) and then continue developing and supporting both apps. The main drawback is that once an IAP customer deletes the app, they wouldn’t be able to use IAP to upgrade and would be forced to purchase the paid version to get pro features. And hopefully Apple won’t consider the storing pro status (isPro=1) a forbidden easter egg.
Less control over IAP descriptions
You can update an app description anytime, however there are some odd restrictions around updating an IAP product description. In iTunes Connect, you can edit the text, but it awaits approval - and approval only comes when a new version of the app is released. End result: You can’t tweak the description to see which is more effective at driving sales (until you push out a full update).
• • •
Well, I think that about covers it.
If you like this post, why don’t you download my photo montage tool Montager [itunes] (it’s free!) and give it 5-stars.
Permanent link to this post: http://xinsight.ca/blog/why-in-app-purchase-is-a-mistake/
Older: Xcode Trick - Shortcut to duplicate a line of code
Newer: Reflections on Porting an iOS app to Android
View Comments
Related Posts
- 05 Sep 2015 » Calabash Tips
- 29 Nov 2013 » Launch Images and Splash Screens
- 15 Oct 2013 » Implications of Free In-App Purchases