Swift — StoreKit

Thank you Artem Beliaikin

Working for a great company to build applications is fun and all, but once you go deeper you truly understand the purpose behind an application (or most of them) is to make money, like any other product being sold to us.

With Apple’s App Store you can sell products or subscriptions in your applications by using one of the four options available:

• Consumable.
• Non-Consumable.
• Auto-Renewable Subscription.
• Non-Renewable Subscription.

Through this article, I’ll explain how to use and implement an Auto-Renewable Subscription, but they all answer the same rules.

Before we dive deep into implementing the StoreKit API and creating products, that are a few things we need beforehand:

• An Apple developer account.
• Filling up the form in the Payments and Financial Reports section.
• Have an app on the App Store Connect.
• Create a sandbox account for debugging here.

To get started we won't be going to the Xcode and start coding, we’ll start by creating our products on the App Store Connect website.
Once you log in to the website go to “My Apps” and select the wanted app, go to “Manage” under “In-App Purchases”.

If followed the steps I mentioned you should be looking at the following screen.
That’s where we manage all the app subscriptions, consumables, and non-consumables.
Let’s create our first app purchase, click the blue + next to In-App Purchases(0).

You’ll be prompted with the following screen, where you can select what type of in-app purchase you want to create.
I’ll create a new Auto-Renewable Subscription, they all basically answer the same terms and have the same requirements, select the option you like and click the “Create” button on the bottom right of the dialog.

You’ll be prompt with the following dialog where we need to enter a “Reference name” and “Product ID”
Reference name — for developers, a name to describe the in-app purchase such as: “Black Friday promotion”
Product ID — The product id we’ll be using in the app code.
Enter yours and click the “Next” button.

In the next dialog, we need to select a “Subscription Group”.
As explained in the dialog, a subscription group allows the user to select different content offerings. So if a group hold multiple subscriptions a user can change between the subscription in that group, a user can have only one active subscription.
Choose your group (or if you don't have one create a group) and click the “Create” button.

We have successfully created our first in-app purchase, the new in-app purchase is currently in a “Missing MetaData” state, we have a few more settings we need to enter for the in-app purchase to be active.

Let’s start by selecting the subscription duration, a subscription can last between 1 week to 1 year, feel free to browse the options Apple gives you.

Once we selected the duration we can decide if to enable Family share or not, Family Sharing Allows members of the same family to share the in-app purchase without the need to share their apple account.

Moving forward to “Subscription Prices”, click the + button next to the title.

Select your price and currency, you’ll then get a list of all countries and the available price.

On the next screen, you can set more options like “Introductory Offers” which can set a different price for the subscription for a certain time or give users a free trial before they subscribe (for a certain amount of days), this screen also offers “Offer Codes” and “Promotional Offers”.
Once done be sure to save, go back to the previous screen.

Now we need to set the Localization.

Subscription Display Name — will be displayed for users on the app App Store page.
Description — Depending on your settings it can also be displayed for users.

As you can see our in-app purchase is still in missing metadata state, which means we cant debug yet.

The last thing we need to add is the “Review Information”, this part is being reviewed by Apple when the in-app purchase is submitted to their review.

Add a png that shows the screen selling this in-app purchase and add “Review Notes” for the reviewer explaining what are you selling and what is the price.

Once we save our in-app purchase should change its mode to “Ready to Submit”.

This is where we part ways with the App Store Connect website and go to Xcode.

Before we start coding we need to add the In-App Purchase capability to our app.
By clicking your app on Xcode, selecting the target, Signing & Capabilities, and adding the In-App Purchase capability.

Time to do some coding (finally!), we start by defining a new class StoreKitManager to order and manage our in-app purchases.
The first action we going to take is pulling the products from Apple’s API:

Import Storekit is a must here since we’re using the StoreKit framework
We then define our class, StoreKitManager .
We define our product ID, the one we created before in the App Store Connect web.
An array of SKProduct objects to hold our products once the getProducts request is successful.

Our first function is getProducts we create a request with our product ID (can have more than one product), we set the delegate to our StoreKitManager (will explain about the delegate later on) and we start the request.

We’ll implement the delegate next to handle the getProducts request result:

We implement the SKProductsRequestDelegate which requires the didReceive function, this means the request was successful and we can use the result.
Now that we have the products let us make a purchase request.

We added the purchase function after the getProducts in the StoreKitManager, we first make sure we have the products available for us and we have at least one product, we then take the product to create a SKPayment object and add it to the SKPaymentQueue .

Now that we made the purchase we need to handle its result:

We implement the SKPaymentTransactionObserver delegate to handle the purchase request we made.
We go over all the transactions returning from the queue, and check the state of each transaction, the states are:

• purchasing — A transaction that is being processed by the App Store.
• purchased — A successfully processed transaction.
• restored — A transaction that restores content previously purchased by the user.
• failed — A failed transaction.
• deferred — A transaction that is in the queue, but its final status is pending external action such as Ask to Buy.

Since we are using an Auto-Renewable subscription we’ll also want to add the option to restore an existing purchase, to do that we’ll add the following function to our StoreKitManager class:

The following function will also trigger the SKPaymentTransactionObserver delegate with either restored or failed states.

Lastly, for our StoreKitManager to work we need to define it and tell the StoreKit API to know that we are the ones who’ll be handling the StoreKit calls, add the following function in the AppDelegate and make sure to call it from the didFinishLaunchingWithOptions function.

Conclusion

StoreKit is a must in every application that wants to make money from in-app purchases, the implementation can be a bit scary at first but as you can see it’s not that tricky.
We must remember all phases, to create our products according to Apple’s rules, add the capability, make the products request, purchase using the StoreKit framework and add the restore option if needed, don't forget to let StoreKit know you’re the observer (usually on the AppDelegate)
If you would like to read more follow this link.