In 2015, in-app purchases through iOS applications raked in more than $14000 million from users worldwide. The figure consolidates the position of in-app purchases as the most profitable channel of app monetization (in-app ads, on average, work better on Android apps though). It has already been forecasted that the value of in-app purchases will inch towards $37000 million by the end of 2017. Learning how to include in-app purchase options in mobile apps is an essential skill for iOS developers, and here’s an overview of how you should go about it:
- Get the latest version of Xcode – That would be Xcode 7.2. For working with in-app purchases, you will have to use StoreKitSuite 3.0 – and that is supported on Xcode 7 (with the SDK of iOS 9). For monetization tracking and managing affiliate campaigns too, the StoreKitSuite is necessary. Invest some time to learn your way around it.
- Use the official API – It is mandatory for iPhone app developers to use the official In-App Purchases (or IAP) API that Apple provides. No other systems or unregistered methods/tools can be used to add in-app purchase options in an application. Failure to abide by this regulation invariably results in app rejections at the store.
- Know the categories – Wish to sell furniture through in-app purchases? Well, you are not allowed to do so! Make sure that the stuff you offer for sale in your app falls under one of these 4 categories – Functionality, Content, Subscriptions and Services. Things like coins for ‘buying’ hints/help in gaming apps and unlocking additional levels/features within an app come under the head of ‘Functionality’. ‘Content’ refers to stuff in digital form – like additional ebooks in mobile reading apps for kids, or VoIP minutes for travelers (app developers need to bundle the digital content with the binary of the application). ‘Subscriptions’ and ‘Services’ are somewhat similar, with one major difference – the former are generally auto-renewable (television streaming, newspaper, voice-based services), while the latter usually come with a time-limit, and have to be renewed after that (for instance, card scanning services for six months).
- Nothing within the Apple ecosystem can feature in in-app purchases – Physical goods (like Apple TV, Apple Pencil and Apple Keyboard) are not allowed to feature as in-app purchases in any way. However, Apple also strictly prohibits third-party iOS app developers to stay away from trying to sneak in access to any Apple peripheral, ranging from tVOS and OS X, to iOS, within the line of in-app purchase items. Any thing available on another app cannot be included either. All purchases from an app must be limited to that application only.
- Register the product identifiers – Understanding ‘Product Identifiers’ properly is important for for those who are new to iPhone app development. It is easy to confuse them with the ‘Bundle ID’ or the ‘App ID’ (particularly the former). A unique string identifier with alphanumeric characters serve as the ‘Product Identifier’ – the reference through which Apple accesses and inspects any particular app. After creating a Product Identifier, pass it through the initWithProductIdentifiers method (a separate SKProductsRequest object has to be created for this). Once registered and initiated, ‘Product Identifiers’ will help you retrieve data related to your app, as and when required.
Note: All in-app purchases have to be initiated in a new version of an app.
- Enabling IAP in your project – Assuming that you already have an iOS developer account, let’s turn our attentions to the (fairly simple) task of enabling the In-App Purchases API. On the Project Navigator window, click on Capabilities → In-App Purchase, and toggle the button to ON (by default, the tabs above it are set to OFF). If you wish to make the purchase options in your app dynamic, make sure that the Product Identifiers are being accessed directly from the web server.
- Types of purchases – We have already mentioned the allowed categories for in-app purchase. Apple also clearly instructs iOS developers to make their in-app purchases belong to any of these 4 types – Consumables (Coins, points, health; have to be purchased multiple times), Non-consumables (extra game levels/rounds, ad-removal, upgradation to free edition of app; needs to be purchased once), Auto-renewing Subscriptions (magazines, newspapers in digital format) and Non-renewing Subscriptions (e.g., passes for a single basketball season). Barring a few exceptions, none of the above types of in-app purchase can be used with Family Sharing.
- Include a receipt validation code – This is not a must, but most mobile app developers prefer adding a receipt validation code in their freemium applications, to do away with the risks of unauthorized purchases. The code generates a receipt with detailed information about the app and each of the purchases made from it. Those who make apps can validate the receipt either in the Apple App Store or locally (the first option is preferable). For local validation, a PKCS#7 signature is required.
- Availability of content subscriptions – If you are allowing users to purchase digital content from your iOS application, make sure that the content remains available for a minimum of one week (7 days). Note that the purchased content has to be accessible on all the iOS devices of the user – and not only on the device (say, iPhone) on which the purchase has been made.
- Describe your in-app purchase well – All the coding within the StoreKit framework takes care of the payments from the in-app purchases. However, the onus is on you to explain exactly what is available in your app that the users can buy. Be very clear about the type of item available for purchase, why users should be motivated to buy it, all the features of the item, and other related factors. Mention whether the purchasable item is consumable or not – and if yes, share information on the validity periods of the same. The StoreKit API pulls the localized information of the in-app purchase options you provide – from descriptions to the pricing.
- Need for a View Controller – Although common knowledge for most app developers, it is worth reiterating the importance of View Controllers in freemium apps here. Buyers actually make the purchase through the View Controller – and you, the developer, need to create and add one that is in sync with the overall layout of your application. All codes that are added to make the purchasing process simpler and more convenient should be placed inside the View Controllers. There is no specified format that has to be followed by developers while making the View Controller.
- Restoring in-app purchases – How often have you heard smartphone users complain about losing purchased content on an app, after accidentally deleting and reinstalling it? The problem of losing data can also crop up when a person switches from one iOS device to another. In the restoreCompletedTransactions() method, an extra line has to be added (SKPaymentQueue.defaultQueue().restoreCompletedTransactions() ). Glossing over this step would enhance the chances of your app getting rejected significantly.
- Determining the price factor – This is a tricky affair. Charge too much for your in-app purchase items, and users will stay away from buying anything (they’ll probably get rid of your app too!). On the other hand, if the purchases are too cheap. your share in the returns won’t be good enough. Estimate how much the non-digital versions of your in-app purchase items would cost, along with the frequency at which the purchases will be made. The manner in which items will be used within the app is also a factor. Similar items (for example, a monthly magazine subscription) should be priced at the same level. Consider these factors, and decide on your pricing strategy accordingly.
- Test the offered products – Testing an iPhone app thoroughly before store submission is vital. The items being offered under in-app purchases have to be separately tested too. You can do the testing from your Test User Account (create one if you don’t have it already) in iTunes Connect. Keep in mind that separate test accounts are required for every territory where the in-app items will be available. Yet another factor that iOS developers need to keep in mind is that, the duration times are compressed for ‘Auto-renewable Subscriptions’. For example, a one-year subscription has a test duration of 60 minutes.
Note: Before initiating app testing in sandbox, you need to logout of the Settings application.
15. Other requirements – Before getting down to the actual process of adding IAP, mobile app developers need to fulfill certain requirements (as spelt out by Apple). For starters, personal banking and tax information have to be provided, and the Developer Program License Agreement have to be agreed to. Those who code for apps must also use explicit App IDs for including the in-app purchase features.
Bonus Tip: Insurance applications cannot have IAP in any form.
On average, in-app purchases yield around 43% more revenue on the iOS platform, when compared to the Android platform. The share of revenues from the purchases is 70:30 in favour of the developers (as it is for overall apps). Given the high profit-making potential of freemium apps, it’s hardly a surprise that most iOS developers prefer adding in-app purchases in their software.