iOS In-App Purchase Overview: Our Hands-On Experience

A lot has been written about In-App Purchase implementation in iOS apps, yet the issue throws us one curveball after another when it comes to practice. Today I’d like to share our experience of developing, testing and releasing an In-App Purchase app with auto-renewable subscription and avoiding the pitfalls we’ve met on the way. The terms of agreement with our client prevent me from giving the real name of the app, so let’s call it ABC digital encyclopedia.

iOS application business models

Before getting to the project itself, let me start with a description of iOS app business models — just a brisk overview, no details. For the sake of simplicity, I’ll use a metaphor that is simple and known to everyone — a chair. So, let’s assume we are producing and selling chairs.

1. The classical model — paid apps

A user buys a chair (application), having paid just once, and starts using it. The money goes to the furniture store (Apple’s App Store). The store subtracts 30% and pays the rest to the manufacturer (developer).

2. Free apps with ads

A user gets the chair for free, but one of the four chair legs is special — it shows commercials. The ad revenue goes to Apple leaving 30% there and then reaches the developer.

3. Freemium — free apps with In-App Purchase

A user, again, pays nothing for the chair and gets a nifty model… with just three legs. The chair is a bit shaky but still very usable. If the user decides that it would be nice to have the fourth leg, he could pay for it. The revenue from the fourth leg, minus Apple’s 30%, goes to the developer.

Today we’ll focus on the last model where the basic set of functions is free, while some great features can be additionally bought. An attentive reader could have noticed that the money icons in the model images differ in size. It’s no accident.

I’ll skip the in-depth conversation about the best way to monetize iOS apps here, just share the research results of 2012 showing that the In-App Purchase share in the whole revenue of developers increased from 28% in 2010 to 72% in 2011. It was less than 1/3 and became larger than ⅔, showing that In-App Purchase is all about good money.

It’s a common misconception that the price for In-App Purchase products and services could be set randomly by developers. Truth is, it couldn’t. The price can be chosen from a list of options provided by Apple. The lowest price is $0.99, the highest — $999.99.

What are the In-App Purchase types?

There are five types of In-App Purchase products and services and they fall into three groups: consumable, non-consumable, and subscriptions.

1. Consumable

Resources in games are one of the most common examples: gold, wood, food. A user buys it, uses it and then it’s gone forever, encouraging user to buy some more, much to the developer’s and Apple’s joy.

2. Non-consumable

These products or services are bought by users just once and become available whenever a user needs them on all user’s registered devices. For example, take The Mighty Eagle from Angry Birds. Besides, there are numerous apps distributed free, offering pro features at a price paid once.

3. Subscriptions

Subscriptions can be free, auto-renewable and non-renewing.

• Non-renewable subscriptions are initiated by users, last a certain period of time (set by their developers) and stop when the period ends. To subscribe again, a user should initiate the subscription manually and it’s the developer’s task to mildly remind the user.
• Auto-renewable subscriptions are a very attractive option from the business point of view since after the first successful purchase, they are prolonging themselves automatically if the users’ credit cards are valid and if the user hasn’t stopped it manually. Sounds like a goldmine.
• Free subscriptions have been added after Apple introduced the Newsstand — a special folder storing Mass Media applications. Free subscriptions are used by applications that offer issues for free.

Now, having looked over all types of In-App-Purchases, you might wonder if a developer or a company could choose which type to use at their own discretion. Nope, they can’t. Apple has its own vision along with a set of requirements for each type.

In-App Purchase type requirements

1. General rule: Through In-App Purchase only digital products or services can be sold, no material values.
2. Mass Media apps only: The use of auto-renewable subscription is limited only to applications falling in the Mass Media category. Such apps could feature digital versions of newspapers and magazines or streaming TV. All other services such as scanning and recognizing business cards, booking tickets and tons of others could only be bought on terms of non-renewing subscription.

The same requirements apply to free subscription: it can’t be used for demo versions distributed with commercial purposes. If an app ignores Apple’s requirements on In-App Purchase use and limitations, it will be banned from AppStore.

The ABC app: getting started

Now back to our ABC app. Our client wanted a goldmine app — the one with an auto-renewable subscription. How it works: once the installation is complete, a user gets access to a part of the ABC content with the full access available after he/she pays the subscription fee. Since the application type doesn’t 100% meet Apple’s requirements, we warned the client of the potential risk being rejected by the Apple team. The client decided to take the risk and proceed anyway.

In-App Purchase implementation models

Having decided on the app type, the implementation method was left to choose. There are two main approaches.

The first one relies on the user’s device and Apple’s infrastructure (for sake of simplicity, the image pictures it as AppStore). The second one has one more element — a server, that can be owned by developers or rented from a third-party company.

What are the pros of the second approach?

1. Flexibility. We can change the list of products and services on a server without changing the app in AppStore.
2. Transaction validation. It’s highly recommended that the important function of transaction validation should be moved to a remote server, which inevitably leads to higher costs of development and maintenance of the whole infrastructure.

In our case the client chose the first model to reduce the project cost and we had to find out how to develop In-App Purchase auto-renewable subscription without a server.

Below you’ll find In-App Purchase types and recommendations on their implementation.

• Consumable — Doesn’t need a server.
• Non-consumable — Using server is recommended.
• Free subscription — Using server is recommended.
• Auto-renewable subscription — Using server is recommended.
• Non-renewable subscription — Using server is a must.

Thus, it turned out that the server was not obligatory in our case, so we started the development process.

In-App Purchase implementation stages

The In-App Purchase implementation process can be divided into three main stages.

The app sends a transaction request to an AppStore server. If the payment has been processed successfully, the server returns information on the transaction — a specially formed data block — and the date when the subscription expires. If the payment processing fails, the app preserves the initial limitations of use.

Stage 2. Checking the subscription status

Two situations are possible:

• Internet connection is available — great!
• Internet connection is not available — it happens…

In the first case the application forms a request to AppStore based on the receipt — this process should be implemented on a separate server. Then, an Apple server returns the payment result that can be either positive or negative. Positive results mean that everything is OK and subscription is being prolonged, at negative result subscription stops.

For the cases when there is no Internet connection the following scheme has been elaborated: we preserve full access till the subscription expire date and, when the device calendar tells that the date has gone, we add an additional check on so-called a privileged period of 10 days. If the period hasn’t expired yet, we preserve the access.

This scheme has been implemented to prevent situations when a user for some reason can’t connect to the Internet but would like to prolong subscription. Preserving access for 10 additional days we hope that within this period the user will get connected, so we can check the real status of the subscription.

This scheme has one vulnerability: the system could be outsmarted if a user disables Internet access and set the wrong date manually. But our client was satisfied with the solution as he believed there would be just a few people who would want to cheat.

Stage 3. Retrieving subscription

This is probably the most important stage. If a user reinstalls the application or has changed the device, you should give the full access to the app content. To do this, the application sends a special query to the Apple server and receives all user’s finished transactions for this app. Then it validates the transactions received and depending on the results grants or restricts the access.

Testing

Testing is an essential part of any development process. Testing of apps with In-App Purchase has its own peculiarities.

1. Sandbox and production environments

There are two types of environment:

• Test environment — the sandbox, till the moment the application is submitted to AppStore;
• Production environment — starts right after the app has reached AppStore.

If your app utilizes transaction validation, you should keep in mind that sandbox and production have different links to the validator. So you need to differentiate the links, using one link for a sandbox and another link for production — after the app has been released.

What link should be used on the stage of the Apple review? The production link. Otherwise, if you do not use a server, the transaction validation will fail.

You can try using the following algorithm: always send validation requests to the production-server and if reply states that the transaction status equals 21007, which means that the app works in a sandbox and the link is wrong, resend the query this time to the sandbox validator.

2. Time machine

As I’ve mentioned before, subscription periods vary from a week to a year and it would be troublesome to test apps in real time. For this purpose, any sandbox has a time machine. It makes a week “last” for 3 minutes, a year — for an hour. These are more comfortable conditions, aren’t these?

3. Subscription statuses

The third issue deals with the subscription statuses. Bought/active, prolonged, canceled (by a user or because of an invalid bank card). In the testing environment, it’s impossible to manually cancel a subscription or imitate an invalid card. How can we test these situations? The answer is simple: in testing, environment subscription can be prolonged only six times and then is canceled automatically. Moreover, if you subscribe again, the subscription would not be prolonged automatically.

4. Test accounts

To avoid the above-mentioned limitation, we need to use a new test user account. It is a special account with Apple ID created in iTunes Connect administration pane — where all the app controls, statistics, etc are located.

Similar to a real Apple ID, the login of a test account is an email. In this case, it can be any email and even a fake one. What is important, when one sets a country in AppStore configuring a test account, this country should be the same on the device on which you plan to test it.

Apple review

When the development and testing of an app are finished, here comes the moment of truth: submitting the application to App Store for review.

Let me remind you, we felt that the ABC app had a high likelihood to be not approved, as this app didn’t strictly meet Apple’s requirements. And it turned out so. Apple’s decision was that we couldn’t use auto-renewable subscription but had to choose non-renewing instead. That meant we not only had to add a server but also to develop the full factional auto-reviewing mechanism by ourselves.

All’s well that ends well

In this less than ideal situation, there was still a way out — to submit an appeal. I know cases when appeals succeeded and Apple team changed their decision. That is why if you feel that Apple’s decision is not the right one, appeal — you might win.

At least we did. Not knowing all the details, I can just suppose that the Encyclopedia category might have played its role. Besides, the subscription period in the final version of the app was defined as a year and the client guaranteed that during this time the content would be updated at least once.

To finish up, one more important tip for your app debut in AppStore — never mention that your app is a beta version neither in name or description, even if you rightly assume it is. Make it just the first version with somehow limited functionality. Post your expectations and future plan on the support site and go on developing the updates, making sure that each update brings you one step closer to the ideal app you wished for.