Jumping through Apple’s hoops to implement your IOS subscription business model

Your app is great, people love it. New users come every day. But what they desire is an ongoing flow of content. New content they haven’t seen, every day, week, month. They get tired of seeing the same static view. You want to provide it for them, but who will take care of the production costs that comes with the ongoing content creation? That’s where a subscription model comes into play. Make users support your app from within Apple’s own ecosystem.

Requirements

There are 3 requirements when trying to implement your own subscription business model within Apple’s services: Provide Apple the required information and agreements, set up your app to allow for In-App Purchases (IAP), and finally create your product.

Setting up how to cash out

In order to upload a paid application or having any kind of IAP within your app, you must first sign Apple’s Paid Applications Agreement which comes with a 99 USD annual fee. In order to do this, gather your bank, contact and tax information and log into https://itunesconnect.apple.com/ with your apple account. Once there, look for the Agreement, Tax and Banking icon and proceed to set up all the forms under the Paid Application contract type.

This is a crucial step. Not until all information is set up, Apple’s API will not provide any type of response when testing your IAP, so doing this as early as possible is mandatory to start development.

Making your App purchase-friendly

Once the above has been taken care of, you will now have to set up the metadata needed in order to allow Apple to identify that your app will feature IAP. Proceed to login into https://developer.apple.com with your apple account, and look Certificates, Identifiers, and Profiles. Once there, Select the App IDs option under the Identifiers section on the left. Select the AppID you desire to add IAP (if you have not created one yet, this is the time to do so) and open up the list. If your Bundle Identifier does not contain any wildcards (“*”), the In-App Purchase option should be enabled by default, if not, go ahead and enable it. Make sure to refresh your certificate from Xcode after doing this.

Now head up to Xcode. In your project settings, selecting the correct target, under the Capabilities tab, you should find an In-App Purchase Capability. Turning this on will not only allow your AppID to make IAP requests but also import StoreKit into your project, a key framework we will discuss later in this post.

Creating the goodies

Now it’s time to create the actual product users will consume when it is all completed. Head to https://itunesconnect.apple.com/ and log in. Once there, look for your App and select the Features tab. If you click the plus icon next to In-App Purchases, a prompt will appear with 4 options to choose from.

Consumable: In order to use again you must make another purchase. Your usual gems/coins/rubies of any free-to-play game.

Non-Consumable: Once purchased, it is unlocked forever and no further payment is required. An additional level, a Pro version of the app, etc

Subscriptions (Auto-Renewable and non-Renewing): A payment that will unlock features of your app for a limited amount of time. Auto-Renewable subscriptions will be charged to the user automatically at the end of each period.

We will focus on Auto-renewable subscriptions, but following this guide, we will get you on the right track with any other IAP as well.

Each product must have a ProductID and It must be unique for the whole app. Input in a reference name and make sure that the cleared for sale option is enabled as it is necessary for testing.

If the auto-renewable option was chosen, the following step is to create a subscription group. Subscription Group is a set of auto-renewable subscriptions which users cannot subscribe to two or more of them at the same time. For example, a monthly subscription to a fishing magazine and a yearly subscription to that same magazine are mutually exclusive. But if the user wants to subscribe yearly to a hunting magazine, he should be able to without leaving his monthly fishing doses. Users can change between subscriptions on the same group at any moment they desire, as it should only change the payment method.

The doom of the In-App Purchase states

This section here is the one you will probably bump into walls more often than not because of Apple’s ambiguous reviewing methods. Your IAP must be validated by Apple, and we as IOS developers understand what that implicates. Some of the more common states you will face are:

Missing Metadata: The product is missing some information. Make sure all these are set up:

Reference Name

Price

Localized description

Review Notes

Review ScreenShot

Ready to Submit: Ready to send to Apple for review

Rejected: Rejected by Apple review, you should now contact Apple through the Contact Us option and work it out with them

Developer Action Needed: The developer must edit the information in order to re-submit the IAP for review

Approved: Ready to test environment and production

Unless your IAP is in an approved state, you will not be able to fetch or test them in your app, so getting this to be approved should be your first move. However, that’s easier said than done. As an IOS developer, you should know by now Apple is quite picky when it comes to what they approve and what they reject. Luckily you can learn from my tedious process and know exactly what you need to reach this instance.

Getting that sweet approved state

The first step to have an IAP approved is to have a build approved. Apple will never approve and IAP unless it sees what it will be used for. The only way to proceed is to upload a build to Itunes Connect and make sure it passes the automatic review. Next step is making an Appstore review. Go ahead and add your build. Don’t worry if your app is not ready yet as you can make a review without releasing it, just make sure the “Manually release this version” option is set in before submitting. Scroll down to the In-App Purchases section and select all the IAP that qualifies for this build.

Now that you are all set, this should be all Apple needs. However, for AutoRenewable Subscriptions, Apple requires for you to express the Term of Services (ToS) inside your app description. If you fail to do so, the IAP will be rejected. An example of an approved description is as follows:

MyApp is a new way of perceiving the Universe With MyApp you will get: * A bunch of cool stuff * A special stuff once a week PRICE AND TERMS: MyApp offers the following subscriptions options: * 1 month: $2.99 (USD) * 1 year: $29.99 (USD) These prices apply to United States residents. Prices may vary in other countries respecting your local currency exchange rate. Your subscription will be charged to your iTunes account. At the end of the term, unless auto-renewables subscriptions are disabled, your subscription will automatically renew in your iTunes account. You will be charged for the regular price of your subscription within 24 hours prior to the end of the current term. You can turn off automatic renewal in your iTunes account settings at any time, but you must do so at least 24 hours before the end of the current term. Refunds will not be provided for the unused portion of any term. Privacy policy, terms, and conditions: http://myApp.com/PrivacyAndTOS

Make sure all of the points made in that small paragraph as well as explicitly telling the benefits and prices of the different models are present in the description. At the bottom, you must add a privacy policy and ToS link, and make it match it with the one set in iTunes Connect to your app, under the App Information category. Also, you must have to display a brief version of this, with the ToS link somewhere inside the app.

Now everything is done, you should hear back from them in a few days with your IAP approved. If not, feel free to use the contact me option inside iTunes Connect to address the issue with them personally.

Finally some code

You know this is an Apple’s tutorial when it’s been over a thousand words and not a single line of code had been written. Let’s get down to work now. We will be using the StoreKit framework provided by Apple which is surprisingly easy to implement, although tricky to understand. Fundamentally, there is a PaymentQueue where all transactions will end up. You will have then to listen to this queue and act accordingly. The flow should look like this.