Subscription Apps on iOS: StoreKit 2 in Practice

# Subscription Apps on iOS: StoreKit 2 in Practice

StoreKit 2 is Apple's async/await-native subscription API, released with iOS 15 and now the standard for in-app purchase implementation. It replaces the older SKPaymentQueue-based model with a cleaner transaction verification system, server-side receipts eliminated in favor of signed JWS transactions, and a subscription status API that makes entitlement checking dramatically more reliable. If you are building a subscription iOS app in 2026, StoreKit 2 is the only path worth taking.

What you need to know

• StoreKit 2 requires iOS 15 or later; if you need to support iOS 14, you must handle both APIs or drop iOS 14 support
• Transaction verification is now done via cryptographically signed JWS tokens, eliminating the unreliable receipt validation model
• The subscription status API gives you a real-time view of a subscriber's current state including cancellations and billing grace periods
• App Store Server Notifications v2 are the companion to StoreKit 2 on the backend and deliver reliable event updates for subscription lifecycle events
• Testing in Xcode's StoreKit sandbox has improved significantly; you can now simulate renewals, cancellations, and billing retry scenarios locally

The core argument

The original StoreKit API was built for a different era of iOS development. Receipt validation required your app to send a receipt blob to Apple's servers, parse an opaque JSON response, and hope the validation did not fail intermittently. Handling subscription renewals, cancellations, billing retries, and family sharing required extensive offline receipt parsing and a lot of defensive programming. Most apps got it wrong in subtle ways. Entitlement bugs were a leading source of subscription support tickets across the industry.

StoreKit 2 fixes the fundamental model. Every transaction is now a signed JWS token that you can verify locally without a server round-trip, using Apple's public keys. The transaction includes all the information you need: product ID, original purchase date, current subscription state, whether the subscription is in a billing grace period, whether it was purchased through Family Sharing. You get this information in a single call with a clear data model instead of parsing receipt payloads. The async/await API makes the code significantly cleaner than the old delegate-based model where transaction updates arrived through a shared queue.

The backend story improved too. App Store Server Notifications v2 delivers real-time events for every subscription lifecycle moment: subscription renewed, subscription cancelled, billing retry, grace period started, refund issued. With the original system, you had to poll receipt validation to detect these events. Now Apple pushes them to your server endpoint within seconds of the event. For Nexli, where subscription state needs to be reflected accurately in the user's access permissions, this push-based model is far more reliable than polling and makes the access control logic simpler to reason about.

Common mistakes

1. Not verifying transactions on your server for anything security-sensitive. StoreKit 2 enables local verification, but for subscription access decisions in a multi-device or web product, verify the JWS transaction on your backend. Local verification is convenient for UI purposes; server verification is required for access control.
2. Ignoring the billing grace period. Apple gives subscribers a grace period during billing failures before cancelling their subscription. If you revoke access the moment a billing failure occurs, you are cancelling users who Apple will successfully charge within 16 days. Respect the grace period and use it to reduce involuntary churn.
3. Not handling family sharing subscriptions. If your subscription supports Family Sharing, members of a family share group can access your app. The entitlement check must account for family sharing, or family members who are legitimately entitled will get an incorrect access denial.
4. Not testing subscription scenarios in the Xcode StoreKit sandbox. The sandbox lets you simulate renewals every 5 minutes, test billing failures, test cancellations, and test refunds without real money. If you have not run through every subscription lifecycle scenario in the sandbox before shipping, you have bugs you have not found yet.
5. Using StoreKit for subscriptions when the app is primarily a web product. If your primary product is web-based and the iOS app is a companion, Apple's 30 percent cut on subscription revenue applies to anything purchased through the App Store. Many products route subscription purchases through the web and use the app for delivery only, which is permitted under Apple's current guidelines.

Where to start

Step 1: Configure your products in App Store Connect before writing code. You need the product IDs and subscription group configuration in App Store Connect before StoreKit 2 can load them. This takes longer than expected; allow a day for initial review and approval of your subscription products.

Step 2: Build the entitlement check before the purchase flow. Start with StoreKit.Transaction.currentEntitlements and get the access control working correctly for already-subscribed users. Subscription status check is the most important piece to get right, more important than the purchase flow itself.

Step 3: Set up App Store Server Notifications v2 on your backend in the same sprint as the iOS implementation. Do not ship a subscription app without server-side notifications. You will miss cancellation events, billing failures, and refunds. These events are what keep your database synchronized with Apple's subscription state.

Related reading

• Native iOS Development in 2026: SwiftUI, Combine, and the New Stack
• App Store Review Hell: How to Survive It as a Solo Founder
• Apple App Store Account Setup: Avoiding the Common Traps
• App Store Pricing Psychology for Founders