28.7 · Building the integration: the store object, the catalogue, the SwiftUI views, status, account tokens and tests
The earlier sections explain what StoreKit 2 does. This one is the order you build it in: one object that owns the store, a catalogue screen, the ready-made views, a status screen, a link to your own users, and tests that do not need the App Store.
Mental model. Keep one source of truth: a single store object loads the catalogue, listens for updates, answers “is this unlocked?”, and is the only place that talks to StoreKit.
Structure and screens
The store object, the catalogue screen, and the built-in views.
- How do you structure a StoreKit 2 integration: which object owns products, entitlements, the updates listener and restore, and where does the seam for testing go?
Put everything StoreKit-related behind one store object created at launch and shared with the UI (an @Observable class on the main actor, or an actor with an… - How do you fetch products and build the catalogue screen: ids, ordering, missing products, period labels and comparing plans fairly?
Start from a list of product ids you own (hard-coded, or fetched from your server so you can change the lineup without a release) and call… - What do the SwiftUI StoreKit views (ProductView, StoreView, SubscriptionStoreView) give you for free, and when do you still build your own paywall?
Since iOS 17 StoreKit ships SwiftUI views that handle most of the work. ProductView(id:) shows one product with its icon, name, price and a Buy button, and…
Status, identity and confidence
Reading subscription status, linking purchases to your users, testing without the store, and a go-live checklist.
- How do you show a subscriber their status (renewing, in grace, will expire) and let them change or cancel the plan?
Read the group’s status with Product.SubscriptionInfo.status(for: groupID), which returns the statuses (usually one) for the user’s subscription group. Choose… - How do you tie a purchase to your own user with appAccountToken, and why derive the token instead of storing a random one?
An appAccountToken is a UUID you pass in the purchase options (product.purchase(options: [.appAccountToken(token)])); Apple stores it with the transaction and… - How do you unit-test the purchase and entitlement logic when Product and Transaction cannot be created in a test?
Product, Transaction and VerificationResult come from the system and cannot be constructed in a test, so test your logic against a seam you own. The store… - What must be true in App Store Connect and in the app before you ship in-app purchases or subscriptions for the first time?
Most “my products do not load” bugs are configuration, not code. In App Store Connect: the Paid Applications Agreement is accepted and the banking and tax…
More in Purchases & subscriptions
- 28.1 · Products, prices, the purchase call, verification and the update stream
- 28.2 · Subscription groups, renewal states, grace period, billing retry and offers
- 28.3 · What the user owns: entitlements, restore, family sharing, refunds and revocation
- 28.4 · JWS, certificate chains, notifications, the Server API and why receipts gave way to transactions
- 28.5 · Paywall design, price display and testing with StoreKit configuration, sandbox and TestFlight
- 28.6 · App Review rules, external purchases and designing a billing platform