Five Good Reasons NOT to Implement In-App Purchase

I’m writing this in light of my recent experience with the Oz Weather iPhone app.

In mid-December I issued an update to the app, immediately after which there was a major app store glitch which caused a huge problem in its own right. But having already documented that previously, I will here discuss the new in-app purchase which was introduced to allow users to enable a set of “Pro” level weather features. In addition to this, I provided a 7 day free trial of the Pro features. As a result of these changes I’ve had a significant number of sales of those Pro features, but I’ve also had a spate of awful (even vitriolic) user reviews, which have significantly lowered the app’s average star rating, and the app’s ranking and new app sales levels have been adversely affected ever since. 😦

Reason 1 – It is not trivial to implement it well

There is plenty of sample code available that you can use to implement the in-app purchase process, but you still need to design and implement your own “storefront” which displays information about the purchase, how much it costs etc. You also need to make sure your app logic works correctly both with and without the purchased items having been activated, and although this might be straightforward in apps where the content is already well compartmentalized, it is much trickier in other types of app where different app features typically have some integration, and need to be separated out carefully when split into standard/purchased functionality.

Testing that the purchase process works correctly and that the purchased content is made available correctly, and if necessary also registers on your own server, is also much slower and more difficult than ordinary app debugging, as it requires using a test sandbox accounts and server interactions. You also ought to test what happens if the purchase process is interrupted, or the server connection is interrupted during purchase or after purchase confirmation, but before you have saved the app purchase status to your own server. All these things can and will happen sooner or later if you have any significant number of users, and you will want to make sure you can deal with them all, and at least recover gracefully later if they can’t be dealt with up-front.

Reason 2 – The developer must take full responsibility for correct delivery of the purchased item

With a normal app purchase the developer can wash their hands of the sale process. Apple deals with the entire sale process and installation of your app, and if something goes wrong with that, and a user loses or needs to restore their purchase, install it on a separate device, or has any other issue, then it is Apple’s responsibility, and you are within your rights to refer any complaints about this back to Apple.

However, with an in-app purchase you suddenly take on much more responsibility. Although Apple does keep track of in-app purchases itself, and can restore these to the user, you will probably also want to keep track of purchases too – at the very least a database of app ids which have made the purchase, so that if the user simply re-installs their app, the app can determine on startup whether the purchase was already made previously, so they won’t have to go through the in-app purchase process again to get it back. Of course if you want to offer a trial, as I did, then you will have to maintain a similar database to keep track of that too.

The most difficult scenario, though, is if your in-app purchase is a time-limited subscription. In that case, Apple has no record of whether or not the subscription has expired, and it is totally up to you to maintain correct reliable records which can be used to restore each users app state. If anything goes wrong with your implementation of this, then it is you who will be responsible for refunding your users! Will you be able to sleep at night knowing this?

Reason 3 – A lot more user support and interaction is required

Although most users will already be familiar with app purchasing paradigms, many users have not used in-app purchase before, and this means that you will likely get a lot of queries due to their inexperience with the process and its quirks and implications.

Here is a list of some of the types of new user issues I’ve had to deal with as a direct result of the in-app purchase, for example:

• Questions about why they get a message saying purchases are disabled on their device
• Questions about why they get a message about a “Test User” account when they try to purchase (jailbroken devices)
• Questions about why they get a message about “Sandbox Account” when they try to purchase (jailbroken devices)
• Questions about why the in-app purchase apparently did not register on their device
• Questions about how to restore the purchase if they load the app onto a different device
• Questions about why they are told they have to purchase the original app before they can buy the in-app item
• Questions about why the in-app purchase items are not free to them, given that they already paid for the app

And then there were more issues relating to the trial, rather than to the purchase per-se, for example:

• Questions about exactly what the new features contain, after their trial has finished
• Questions/complaints about why they have lost trial features they believed were part of the standard app

Reason 4 – Users who don’t/won’t pay for the in-app purchase can still leave a bad review about it

In my own case, this is the hardest one to deal with – and should give other developers plenty of pause for thought.

Apple has gone to some lengths to tidy up the user review system, and it has certainly improved a lot since the early days. However, there remains a glaring hole in the system – although users can no longer leave reviews for apps that they haven’t purchased they can still leave reviews relating to in-app purchase items that they have not (and obviously will not) purchase.

In my own case, most of the bad reviews are apparently due to misunderstandings by the user about the nature of the in-app purchase. Some people obviously thought that they were losing what they had previously paid for, and had to pay again just to keep the app.

Of course I have to take responsibility for any lack of clarity in how the in-app purchase has been presented to the user, and I have indeed attempted to tweak this. I suspect that the worst reactions have come from people who for one reason or another, did not see the message that appears at the start of trial, explaining what was happening, after which they assumed that the trail features were theirs to keep. I’ll continue to work on this, and this might help, but the basic issue will remain as a major potential problem for anyone implementing in-app purchases, and wants to maintain a strong app rating in the store.

Reason 5 – Some users have the impression that all app “upgrades” must be free

Quite apart from users who misunderstood the trial and in-app purchase structure, there are also a number who simply seem to feel entitled to any additions to the app for free, perhaps having misconstrued Apple’s free update system as meaning that all types of app updates in functionality must necessarily also be free.

In a way it a compliment of course – the fact that they are so upset about not having the extra functionality must mean that they really do want and value it. However, the fact remains that these people also leave bad reviews, and there is no shortage of others who find those bad reviews “useful” and vote accordingly, thus pushing them to the top of the review list.

In Summary

In-app purchase may well be a useful and rewarding system for some developers and for certain types of apps, but it comes with some disadvantages, not all of which are immediately apparent. In particular, if you have a high profile/high visibility app which relies heavily on having good user ratings, you should think carefully about the possible drawbacks before you add in-app purchase to it. So now I’ve warned you. The rest is up to you. Good luck!