// the find
bizz84/SwiftyStoreKit
Lightweight In App Purchases Swift framework for iOS 8.0+, tvOS 9.0+ and macOS 10.10+ ⛺
SwiftyStoreKit wraps Apple's original StoreKit 1 framework behind a block-based API, making purchase flows and receipt verification less painful than working with SKPaymentQueue directly. It targets iOS indie developers who want to ship IAP without reading all of Apple's StoreKit documentation. The author now recommends using RevenueCat instead, which tells you most of what you need to know.
- The atomic/non-atomic purchase distinction is a genuinely good API design — it forces you to decide upfront whether you're delivering content immediately or via a server, which prevents the common mistake of finishing transactions before your server confirms delivery.
- Solid test coverage for the core payment queue logic: PaymentQueueController, PaymentsController, RestorePurchasesController, and CompleteTransactionsController all have dedicated test files with fakes and spies rather than just integration tests.
- Multi-platform (iOS, macOS, tvOS, watchOS, Catalyst) from one SPM package with no conditional compilation leaking into user code — the OS abstraction layer is handled internally.
- The block-based API genuinely is simpler than managing SKPaymentTransactionObserver delegates yourself, and the receipt verification helpers save real boilerplate.
- This wraps StoreKit 1. Apple shipped StoreKit 2 in 2021 with async/await, JWS-signed transactions, and no receipt file. Four years later, this library has zero StoreKit 2 support — the author says so in the README and suggests you go elsewhere.
- AppleReceiptValidator sends receipt data directly to Apple's verifyReceipt endpoint from the client. Apple's own documentation says receipt validation should happen server-side to prevent replay attacks. The library makes the insecure path the easy path.
- The author is not maintaining this project and says so explicitly in the README. Open issues go unanswered. The last push was June 2024 and appears to be minor housekeeping, not feature work.
- No local purchase persistence by design — you are responsible for storing what the user has purchased, which is reasonable, but combined with StoreKit 1's receipt complexity it means you still end up writing a meaningful amount of IAP plumbing yourself.