StoreKit is Broken

Apple's framework is fundamentally flawed.

StoreKit is Broken
Jacob Eiting
Jacob EitingNovember 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

Subscribe to our monthly newsletter

Related posts

Google Play class action developer lawsuit

Google Play Billing Library 5.0, an overview

Everything you need to know about Google Play Billing Library 5

Rik Haandrikman

Rik Haandrikman

November 25, 2022


How RevenueCat’s SDK team uses Release Trains

How we automate the releases of our SDKs

Cesar de la Vega

Cesar de la Vega

October 31, 2022

Stripe for In-App Purchases

Can You Use Stripe for In-App Purchases?

Learn about when you can use Stripe and opportunities to save money on fees.

Corey Rabazinski

Corey Rabazinski

October 31, 2022

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