We continue our series of articles dedicated to iOS in-app purchases. In the previous part, we have discussed the process of creating in-app purchases and their configuration. You can read all the tutorials following the links:
- iOS in-app purchases, part 1: configuration and adding to the project.
- iOS in-app purchases, part 2: initialization and purchases processing.
- iOS in-app purchases, part 3: testing purchases in XCode.
- iOS in-app purchases, part 4: server-side receipt validation.
- iOS in-app purchases, part 5: the list of SKError codes and how to handle them.
Now we are going to show you how to create a simple paywall (payment screen) as well as how to initialize and process purchases that we have configured.
Creating a subscription screen
Any app that uses in-app purchases has a paywall. There are some guidelines from Apple that determine must-have elements. At this step, we’ll implement just some of them to give you a sense of that to do next.
So, our screen will have the following:
- Header with premium description;
- Subscription activation buttons with local currency and title;
- Restore purchases button. This element is necessary for all the applications that use subscriptions or non-consumable purchases.
I've used Interface Builder Storyboard for layout, but you can use just coding. I've also moved UIActivityIndicatorView to ViewController to present the payment process.
Show purchase information
Let's build a core of our ViewController. It doesn't have any logic and we’ll add it later.
Let's see what's inside:
- Property class fields to link UI elements with our code.
- Launching asynchronous initialization process of purchases unit in viewDidLoad(). To make this process independent from the UI layer, it’s better to call it just right after the app launch. In this article, to make it easier, let's do it just right in the ViewController.
- Before launching the initialization, we'll show the loading bar and we'll remove it after the initialization finishes. I’ve written some helper functions for it, check them below.
- updateInterface() function that updates UI with purchase data such as trial duration and pricing.
- Buttons handlers for initialization and purchase restoration.
Pay attention to the usage (1) of SKProduct objects. We make an extension to easily extract the information. This implementation is more flexible then using SKProduct props directly:
I’ve slightly refined the Purchases class to make it possible to show the result of an asynchronous operation in the interface. I also cached SKProduct objects for further usage.
Purchase mechanism implementation
Let's add the Errors handling to our code. I created enum PurchaseError to implement Error protocol (or LocalizedError):
All errors on StoreKit level will be caught as a single error, get more information about the error types in the documentation.
purchaseProduct() function launches the purchase process of the selected product, and restorePurchases() function requests the list of the users' purchases from the system: auto renewable subscriptions or non-consumable purchases:
- Check that there's the only purchase process launched.
- Return the error when trying to purchase with nonexistent productId.
- Add the purchase to SKPaymentQueue.
- Make a request to SKPaymentQueue to restore purchases.
To process the result of the purchase, we need to implementSKPaymentTransactionObserver() protocol:
- Iterate on transaction body, processing each one individually
- In case the transaction is in the purchased or restored status, we need to do all the necessary actions to make the content/subscription available for the user. Then we need to close the transaction with the finishTransaction method. Important: if you work with consumable purchases it’s crucially important to ensure that the user has gained access to the content and close the transaction right after the check. Otherwise, it’s possible to lose the information about the purchase.
- The purchase process may finish with an error due to different reasons, so return this information.
- Provide the user with the purchased content in the function that we request on step 2: (for example, we remember the subscription expiry date for UI to interpret the user as premium)
- In this case, we have discussed some of the existent transaction statuses. There is also purchasing status (it means the transaction is being processed) and deferred status means the transaction is postponed indefinitely and will be finished later (for example, while waiting for the confirmation from parents). These statuses can be shown in UI if necessary.
Call in the interface
The core part is done, so we just need to call execute these functions in the ViewController.
This is it. In the next part, we will discuss the basic ways to test the purchase mechanism, and how to design a paywall to pass the App Store review.