A Deep Dive into StoreKit 2 Capabilities

During WWDC21, Apple announced many exciting product features, and StoreKit 2 is one of the most significant updates. In-app subscriptions have become the most popular monetization method that generates billions of dollars in revenue for Apple and thousands of mobile app developers. Developers have earned $230 billion through the App Store since its launch, with the biggest chunk of that revenue coming in the last few years.That makes in-app purchases a particular focus of Apple and Google. Just last year WWDC20 presented StoreKitTransactionManager with a .storekit* *file that simplifies the process of in-app purchases testing. We have been waiting for this update since iOS3. And the next updates were not long in coming.

This article will cover what’s new in StoreKit 2 and discuss the difference between the updated framework and its previous version – StoreKit.

Before we jump into StoreKit 2 overview, let’s briefly cover what was wrong with the previous StoreKit.

---

Key Limitations of the Original StoreKit

Complexity

Compared with other native SDKs, StoreKit is difficult to understand (that’s great if this is not your case). Complicated system, products, transactions, payments, requests, receipts, refreshes, and on top of that, you also need a running server. This complexity led to the emergence of SaaS products which provide infrastructure for working with the StoreKit both on a client and server side.

• Requires a running server to handle these complexities.

• The system involves a lot of moving parts: products, transactions, receipts, etc.

Bad architecture

We are talking about the perplexed control flow with callbacks that one needs to implement in order to handle events from StoreKit. Specifically – delegate and observer patterns. The initialization of product loading happens in one place. Still, instead of receiving the response in a common completion block, you will get it in a completely different component from SKProductsRequestDelegate.A similar story with the purchase process. The response comes only from SKPaymentTransactionObserver, so you would have to store and correspond the data from the response, and hope that it will work well in the processing logic you implemented. It introduces a risk of dropping some purchases. It is less of an issue with subscriptions where we can call restore, but a big problem with expendable purchases represented as consumables – missing those would be very unfortunate.

• Risk of missing transactions, especially with consumables.

• Poor control flow between components (e.g., delegate vs. observer patterns).

No built-in purchase validation

There is no out-of-the-box solution. Yes, you could attempt to parse the receipt on the device, but that only solves part of the issue as it won’t protect from the users who would try to use your app for free. You might be surprised by the number of fraudsters who use jailbreak to get free access to the apps.

We witnessed it when our new customer flooded the bug tracker with reports of misbehaving SDK. Their analytics showed frequent restore requests that would always fail. Those requests were coming from the fraudsters, who got surprised by the loss of access to fake purchases they had forged on the device (as we also have receipt validation on Apple servers) and started to send multiple restore requests. As a result, access was denied as server validation didn’t confirm these user’s purchases.

• Developers must create custom solutions for receipt validation, making it easier for fraudsters to exploit the system.

Lack of Automatic Synchronization Across Devices

Imagine you have an iPhone and Ipad (or perhaps you are indeed the proud owner of both). You purchased something/product/access on your iPhone but didn’t receive the app access on your iPad, even though both of these devices share the same Apple ID. To access the purchase across all your devices, you would have to take additional steps, so consider the hassle.

There is no data about existing purchases

It is not that difficult to store it yourself, but it still counts as an effort. After a purchase or renewal of a subscription, you receive a transaction. The only way to restore this information from StoreKit again is to use the Restore API, which is not supposed to be used for this purpose. Thus you are left with an option of keeping this data yourself (in UserDefaults/your server) to provide a user with access to purchases which is an additional reliability risk. If you’re using UserDefaults there is a surprise for you cause once you reinstall the app, you will lose all data.

Lack of essential data

Let’s go through the most common cases. It’s a common practice to make discounts and free trial periods for some purchases. Naturally, you would want to offer discounts based on purchases that a user has already made, but you won’t be able to do so as StoreKit doesn’t provide the means to get the needed information. You also won’t tell whether your customer canceled (or is about to cancel) a subscription unless you have a server listening to App Store Server Notifications. Thus, you won’t be able to offer them a discount, ask for feedback, or retain them by some other means without making an extra effort to maintain additional server infrastructure.

Conclusion

To wrap things up, StoreKit 2 really makes life easier for developers handling in-app purchases and subscriptions. With simplified transaction processes, better purchase validation, and the ability to sync purchases across devices without any extra hassle, Apple has truly raised the bar. If you’ve ever felt bogged down by the complexities of the original StoreKit, our blog is here to help you out.