Igor has spent over 15 years helping business owners to navigate and achieve their strategic objectives using progressive technologies. Being a technology enthusiast, he has kick-started and has been involved in the development of hundreds of web and mobile applications, fintech platforms, and digital ecosystems. He specializes in artificial intelligence, cloud solutions, and future-ready fintech product development.

Mobile app development for business usually aims to create one more channel to serve clients and sell products and services, both physical and digital. To put it short, businesses earn money via mobile apps. Though monetization models may differ, when companies want to sell content within their apps, they will face the need to implement in-app purchases.

Today, nearly every app offers products or services a user can buy via an application as a feature. Our company has extensive expertise in mobile application development, and our sci-tech team of skillful developers has implemented payment solutions in a number of digital products. In this article, you will read what challenges we’ve faced while developing purchase functionality for iOS mobile applications and discover the reasons why we’ve decided to build our own solution for iOS in-app purchases. Additionally, we will share our experience of moving from third-party payment software to our own one within a system. You will learn how to create a custom dependency for managing payments, illustrated with real-life examples from two successful iOS business apps developed for our clients. Finally, we will highlight the benefits of developing a custom iOS in-app purchase library for a business app.

In-app purchases overview, terms, and definitions

An in-app purchase (IAP) for app users is any fee (in addition to the initial cost of downloading the app) that the software may request.

The IAP functionality can provide users with additional features, content, or digital products, while in other cases it serves as a subscription that requires users to pay for using the application. Subscription often goes after the free trial.

Creating an account on the App Store requires adding a credit or debit card to cover all the costs associated with downloading paid iOS applications.

Since applications are downloaded from the store, they can directly withdraw funds from the card associated with the account, making purchases within the iOS application very susceptible to hacker attacks, since there is no need to enter credit card information again or enter a password to book a transaction.

Types of iOS in-app purchases

As Apple states, there are four types of in-app purchases, that an iOS, macOS, or tvOS application can provide:

Consumable. This type of products and digital content can be purchased as many times, as a user wants it.

This type of products and digital content can be purchased as many times, as a user wants it. Non-Consumable. This type comprises non-consumable, premium app functionality. Those features that are purchased once and do not expire. Some content associated with a non-consumable purchase can be stored on Apple’s side.

This type comprises non-consumable, premium app functionality. Those features that are purchased once and do not expire. Some content associated with a non-consumable purchase can be stored on Apple’s side. Auto-Renewable Subscriptions. In this case, users are charged periodically for access to premium content. It is the recurring purchase and subscription can be canceled anytime in the App Store settings.

In this case, users are charged periodically for access to premium content. It is the recurring purchase and subscription can be canceled anytime in the App Store settings. Non-Renewing Subscriptions. This type is the ability to purchase access to some goods or content in an iOS app for a limited period of time. This subscription form is not repetitive, so app users need to buy a new membership each time they need it.

The Overview of the iOS in-app purchase lifecycle

In general, all iOS IAPs are realized the same way.

A software solution requests all available products from a server side and shows them to users; A user selects a product to purchase through UI; A system adds the purchase request to the App Store purchase queue; When a purchase is successfully processed, the application is notified; A purchase receipt is sent for validation to the app’s server side; As soon as the validity check is passed, user gets access to the requested products or content.

So, this is how a purchase circle looks in general, and it works perfectly in theory, but there are a lot of traps and pitfalls in practice.

iOS in-app purchase lifecycle in practice

In real life iOS in-app purchase flow is much more complicated than the infographics above. So what does actually happen when a user taps a “Purchase Now” button in iOS app? Let’s dive into the Apple’s StoreKit.

A user taps a purchase button on a screen of an iOS app. For every iOS application that makes purchase requests, StoreKit creates a SKPaymentQueue. Every queue has a listener that can respond to any modifications of the request queue. In other words, when the system sends a purchase request, it is added to quite a long cue. There can be several purchases at once, and all of them will be processed sequentially, one by one. After adding a purchase request to the queue, it is validated to determine whether a user is allowed to make it. Then a series of checks is performed, such as if a user has Apple ID account, if payment card is added, if there are any parental restrictions, and many other criterias. The results of these validations are sent to the queue. In practice, a user can see a dialog requesting to enter a username and password from his account before buying, as in the above-mentioned example. As soon as a purchase is settled and it has passed the validation successfully, a notification will be added to the queue awaiting processing again and initiate data re-processing. However, there can be several purchases, as well as validation checks in that queue. When the request is processed successfully, a local product receipt gets updated with purchase details. Then we should mark the transaction as finished. After those steps, user gets access to premium features or content in the iOS application.

All these factors, like asynchronous nature of requests and poor architecture, can lead to asynchronous purchases in business iOS applications, thus leading to negative user experience and customer attrition. So, choosing approaches to in-app purchase functionality in iOS applications, developers and stakeholders should keep in mind a bundle of asynchronous requests and responses, along with possible architecture-associated issues.

Business tasks and challenges of purchases in iOS apps

The first business case: an iOS app selling consumable products

One of our client’s business app provides its customers with a service of communication with psychic advisors and mediums to find answers and clarity in their lives. The app uses a freemium monetization model — some functionality is free for registered users, while for live communication a fee is charged. One of the payable features is a chat with an advisor. To offer this functionality to its users, the iOS app is using in-app purchases. Before the chat starts, an app user adds funds to their balance, and these funds can be charged for a chat with any available advisor.

If we turn business tasks of the mentioned app into the main requirements of IAP (in-app purchases) development, they would be the following:

Fetch the list of products, i.e. “Minutes bundles”, as the main action required for adding funds to a user account;

Check if a user’s Apple ID is allowed to make purchases and whether this ID corresponds to the region where the paid content is provided by the app;

Provide a consistent purchase flow, prone to network errors and disconnects.

The second case: an iOS business app offering services subscription

Another business case, we would like to mention as the example, offers users various astrological services. In-app purchases are implemented to provide a subscription feature. The app user can subscribe to a premium service and get more content compared to a standard offering. All premium content from the app is accessible across multiple devices by using Apple ID.

When starting an application, the system checks if a user’s subscription is still valid defines which content to show, and makes corresponding changes to the UI.

So, in this case the main development requirements for subscription purchases are:

Determine what types of subscriptions are available for purchase for every app user;

Confirm the ability of user’s Apple ID to make purchases;

Provide a subscription purchasing interface;

Validate current subscription state (a type of subscription, trial period, etc.).

Conclusion

In-app purchases in iOS application development are a challenging feature that requires hands-on experience, comprehensive approach, and a lot of hours to implement. Nevertheless, this functionality often serves as the main source of revenue for software products and games. Creating a custom in-app purchase library and allowing its free usage, our goal was to facilitate the embedding of in-app purchase functions for our clients and partners, thus shortening their time-to-market and cutting the development cost.

Dashdevs created its own purchase library that covers requirements and solves the most common pains, like asynchronous execution, availability of separate instances, local receipt validation, and more. The purchase library is available at GitHub under MIT license. Use it, enjoy, and tell us whether our custom in-app purchase library was helpful for your iOS development challenges in the feedback and comments section below the article.