How to design an SDK to handle $10bn in transactions
A deep-dive into SDK design (feat. RevenueCat)
RevenueCat has a neat business model: Take an enormously painful hassle (managing in-app subscriptions), abstract it into something bearable, and charge devs a cool 1% for the service. Classic painkiller.
This abstraction is where the value lies.
$10bn worth of value (so far!).
When tens of thousands of devs are relying on you to make money, the stakes can’t get much higher. Consequently, the RevenueCat iOS SDK is one of the most battle-hardened open-source projects out there.
Therefore, we can learn a lot about SDK design principles by analysing it:
Backwards compatibility as a top-level constraint
Façade-first design for public APIs
Sensible defaults and progressive disclosure of complexity
Careful layering of dependencies
Relentless logging, diagnostics, and profiling
Orchestration between services for complex flows
Offline-first correctness
“Invisible” performance characteristics
Friendly abstraction over janky third-party APIs
Keeping mindful of dev-ex (developer experience) every step of the way
We’re taking a deep-dive into the payments flow: how the SDK abstracts away the complexity of making purchases and setting up in-app subscriptions.
Sponsored Link
RevenueCat Paywalls: Build & iterate subscription flows faster
RevenueCat Paywalls just added a steady stream of new features: more templates, deeper customization, better previews, and new promo tools. Check the Paywalls changelog and keep improving your subscription flows as new capabilities ship.
(That’s right, I finally manifested my bit from 2023)
Contents
High-Level System Design
Consider the RevenueCat SDK at a basic level: how would you design such a thing? Don’t think about payments, subscriptions, entitlements, receipt validation, and paywalling yet.
It’s easier to start with a big box that abstracts away everything a user has to worry about.
Now consider: who are the big players involved?
There’s the client app, of course, who pays you money to use the SDK. Then, with a great big box, we can represent the SDK. The other major players are StoreKit, Apple’s own servers, and of course the RevenueCat backend itself, mostly all chatting to each other.
The SDK needs to abstract all the complexity away of creating a customer, displaying products on a paywall, talking to StoreKit during a purchase, updating and handling user entitlements, and posting transaction info to a server so everything links up cross-platform.
Inside the SDK, the architecture is loosely set up in layers, with very heavy usage of constructor injection to manage dependencies across all the classes. These dependencies are all initialised on SDK init, with lower level services injected into high level managers and orchestrators where needed.
For payments, the conceptual layers look a little like:
Façade layer containing Purchases, the public API surface
Orchestration layer where PurchasesOrchestrator coordinates everything
Managers layer containing business logic and services like OfferingsManager, CustomerInfoManager, and ProductsManager.
Infrastructure layer containing basic services like Backend, HTTPClient, and OperationDispatcher.
Let’s dive down into these layers in detail to see how the SDK handles payments.
Upgrade to read this article right now, or wait until next month.
Paid members get several benefits:
🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my full course and advanced training
