StoreKit is Broken

Apple's framework is fundamentally flawed.

StoreKit is Broken
Jacob Eiting

Jacob Eiting

November 29, 2017

StoreKit is Apple’s framework for doing in-app purchases that was introduced in iPhone OS 3.0 in July of 2009. It provided developers with a way of monetizing their apps besides charging to download. This was a game changer. Despite its success, the framework has a very flawed design that has existed unchanged since iPhone OS 3.0.

An Observational Approach

The StoreKit API uses a queue and an observer. A developer requests a purchase be added to the queue and the observer is notified when that request changes state. Typically you have a method that looks something like this:

1func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction]) {
2        for transaction in transactions {
3            switch(transaction.transactionState) {
4            case .purchasing:
5                break;
6            case .purchased:
7            case .restored:
8                handlePurchase(transaction);
9            case .failed:
10                handleFailure(transaction);
11            case .deferred:
12                break;
13            }
14        }
15    }

‍‍Have a look at the following diagram from Apple’s IAP programming guide.

Apple in-app purchase diagram
How Apple expects you to integrate StoreKit

The problem lies in connecting the “Makes payment request” and the “Observer is called” steps of Apple’s diagram. For a good user experience, your app needs to react correctly to purchases that it initiates, but you can’t.

StoreKit’s design makes reacting correctly impossible.

SKPayment is delivered to the payment queue with addPayment(), the return type is void. StoreKit returns nothing for you to track your payment. When your transaction appears in the payment queue observer method, it has lost all connection to the SKPayment that generated it. This makes it impossible to associate payments with the transactions they generate.

Guessing Around The Issue

So how do developers get around this limitation? Many dive into the CocoaPods library and grab for some of the very popular wrappers like SwiftyStoreKit. It provides a very nice block based wrapper around StoreKit, transforming addPayment into addPaymentWithCallback. How awesome!

But it is a fraud.

SwiftyStoreKit and any of the other StoreKit convenience frameworks, will call the callback block of the first transaction with a matching productIdentifier. This doesn’t work. If there are failed transactions on the queue that weren’t finished they could show up on the queue as soon as a user types in their App Store credentials. This causes SwiftyStoreKit to call your callback with a failed transaction when you may actually have a successful transaction waiting on the queue. This leads to a frustrating experience for the user at the worst time that will likely incur you review problems and customer support costs.

So how do you do it correctly? You can’t. If you are disabling the UI for your application you need to listen for any failed transactions and assume those were generated by your request and re-enable your UI. This means that a good transaction following a failed transaction will create a very confusing user experience.

How to Fix StoreKit

The fix is simple. Returning the SKPaymentTransaction (or something related to it) from addPayment would fix the problem. This would allow block based wrappers to be written and make implementing UI for IAP much simpler. This improved API would pass on its benefits to users, resulting in higher customer satisfaction and fewer customer service tickets for Apple.

But after 8 years of almost no changes to StoreKit, I’m not holding my breath.

RevenueCat is the best way to implement subscriptions in your mobile app. We handle all the complicated parts so you can get back to building. Request an invite today at

In-App Subscriptions Made Easy

See why thousands of the world's tops apps use RevenueCat to power in-app purchases, analyze subscription data, and grow revenue on iOS, Android, and the web.

Related posts

We launched easier cohort comparisons in RevenueCat Charts

We launched improved cohort comparisons in ‘Charts’

These additions to RevenueCat Charts make it even easier to analyze data over time

Dan Pannasch

Dan Pannasch

March 13, 2023

RevenueCat Experiments

How to use RevenueCat Experiments to A/B test in-app paywall design elements 

Test and visualize the impacts of both price and design variables using this workaround.

Dan Pannasch

Dan Pannasch

February 28, 2023

RevenueCat now supports Unity Package Manager

RevenueCat now supports Unity Package Manager

To make our Unity SDK even easier to use, it's now available using UPM — but the asset package is still available.

Toni Rico

Toni Rico

February 23, 2023

Want to see how RevenueCat can help?

RevenueCat enables us to have one single source of truth for subscriptions and revenue data.

Olivier Lemarie, PhotoRoomOlivier Lemarie, PhotoRoom
Read case study