Implementing a store in your app using the StoreKit API
At a glance
| Item | Summary |
|---|---|
| Purpose | Offer In-App Purchases and manage entitlements using signed transactions and status information. |
| App architecture | A Swift sample with the source-visible chain SKDemoApp → ContentView → BoostStore → StoreKit APIs. |
| Main patterns | Central store, Binding-based state propagation, Actor-isolated state |
| Project style | 30 scanned source file(s) across Swift, organized around ranked entry, type, and file boundaries. |
Project structure
Source bundle/
├── SKDemo/
│ ├── SKDemoApp.swift
│ ├── In App Purchase/
│ │ └── Store.swift
│ ├── View/
│ │ ├── ContentView.swift
│ │ ├── Miscellaneous/
│ │ │ ├── CarItemStore.swift
│ │ │ └── ImageNameConstants.swift
│ │ ├── Stores/
│ │ │ ├── BoostStore.swift
│ │ │ └── SubscriptionStore.swift
│ │ ├── SelectedCarView.swift
│ │ └── SwiftUIMerchandisingView.swift
│ └── Model/
│ └── SKDemoPlusStatus.swift
└── SKDemoServer/
└── Sources/
├── Consumable.swift
└── Server.swift
Structure observations
- Architecturally prominent files are ranked from entry points and role-named declarations; resource-only paths are omitted.
- Primary languages: Swift.
- The verified tree contains 5 project/configuration file(s) and 62 source declaration(s).
Overall architecture
flowchart LR
N1["SKDemoApp"]
N2["ContentView"]
N3["BoostStore"]
N4["StoreKit APIs"]
N1 --> N2
N2 --> N3
N3 --> N4
Reference code
SKDemo/SKDemoApp.swift:13 — architecture anchor
@main
struct SKDemoApp: App {
// ...
}Interpretation
The arrows summarize the source-visible entry, role-named types or folders, and framework direction; when nodes come from structural folders, the sequence is a high-level interpretation rather than proof that every adjacent node calls the next. Ownership is claimed only where the next section cites a stored property or assignment. The diagram is intentionally limited to the dominant path into StoreKit.
Ownership and state
classDiagram
CustomerEntitlementsViewModifier *-- Logger : logger
CustomerEntitlementsViewModifier *-- SKDemoPlusStatus : skDemoPlusStatus
CustomerEntitlementsViewModifier *-- Set : ownedCars
ErrorObserverViewModifier *-- Error : error
Ownership evidence
SKDemo/SKDemoApp.swift:31 — stored dependency or nearest verified ownership anchor
private let logger = Logger(subsystem: "SKDemo", category: "CustomerEntitlementsViewModifier")
private var customerEntitlements = CustomerEntitlements.shared
@State private var skDemoPlusStatus: SKDemoPlusStatus?
@State private var ownedCars: Set<Car> = []| Owner | Object or state | Relationship | Mutation authority |
|---|---|---|---|
CustomerEntitlementsViewModifier |
Logger (logger) |
creates and retains | Initialized by the owner; the binding is immutable |
CustomerEntitlementsViewModifier |
SKDemoPlusStatus (skDemoPlusStatus) |
owns wrapper-managed state | Owning lexical scope |
CustomerEntitlementsViewModifier |
Set (ownedCars) |
owns wrapper-managed state | Owning lexical scope |
ErrorObserverViewModifier |
Error (error) |
owns wrapper-managed state | Owning lexical scope |
Composition arrows indicate a source-visible construction expression or locally owned value state; aggregation means the owner stores or receives a dependency without proving exclusive lifetime ownership.
Class and protocol design
SKDemo/SKDemoApp.swift:14 — representative type boundary
struct SKDemoApp: App {
// ...
}| Type | Responsibility | Depends on or conforms to |
|---|---|---|
SKDemoApp |
Application entry and top-level composition | App |
Store |
Centralized state or persistence access | Concrete collaborators/imported frameworks |
ContentView |
User-interface presentation and input forwarding | View |
CarItemStore |
Centralized state or persistence access | Concrete collaborators/imported frameworks |
BoostStore |
Centralized state or persistence access | View |
CustomProductView |
User-interface presentation and input forwarding | View |
SubscriptionStore |
Centralized state or persistence access | View |
BoostStore |
Centralized state or persistence access | Concrete collaborators/imported frameworks |
ContentView |
User-interface presentation and input forwarding | Concrete collaborators/imported frameworks |
FuelStore |
Centralized state or persistence access | Concrete collaborators/imported frameworks |
No local protocol conformance is claimed as protocol-oriented design; external framework conformances are listed only as dependencies.
Access control
| Symbol | Access | Verified effect | Likely rationale |
|---|---|---|---|
logger (SKDemo/In App Purchase/CustomerEntitlements.swift:12) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: keep state mutation or dependency lifetime inside the owning implementation. |
transactionUpdatesTask (SKDemo/In App Purchase/CustomerEntitlements.swift:17) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: keep state mutation or dependency lifetime inside the owning implementation. |
statusUpdatesTask (SKDemo/In App Purchase/CustomerEntitlements.swift:18) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: keep state mutation or dependency lifetime inside the owning implementation. |
shared (SKDemo/In App Purchase/CustomerEntitlements.swift:27) |
public |
The symbol is visible to importing modules. | Inference: make the declaration available across a module or target boundary. |
Reference code
SKDemo/In App Purchase/CustomerEntitlements.swift:12 — representative boundary
private let logger = Logger(subsystem: "SKDemo", category: "CustomerEntitlements")Swift declarations without a modifier are internal; explicit private, fileprivate, private(set), public, or open entries above are interpreted by language semantics. Objective-C/C samples instead rely on header and implementation boundaries, which are not equivalent to Swift lexical privacy.
Logic ownership and placement
| Logic | Owning type or file | Placement rationale |
|---|---|---|
| Application entry and top-level composition | SKDemoApp |
The source’s App suffix makes this role explicit. |
| Centralized state or persistence access | BoostStore, CarItemStore, CarWashStore, FuelStore |
The source’s Store suffix makes this role explicit. |
| User-interface presentation and input forwarding | ActiveUpfrontView, CommitmentProgressView, ContentView, CustomProductView |
The source’s View suffix makes this role explicit. |
Design patterns
| Pattern | Source evidence | Purpose or tradeoff |
|---|---|---|
| Central store | SKDemo/View/Miscellaneous/ImageNameConstants.swift:11 |
A store-named type centralizes feature state or persistence. |
| Binding-based state propagation | SKDemo/View/ContentView.swift:99 |
A binding exposes controlled read/write access while the upstream owner remains authoritative. |
| Actor-isolated state | SKDemoServer/Sources/Server.swift:23 |
Actor annotations make the concurrency ownership boundary explicit. |
Naming conventions
- Types: App: SKDemoApp; Store: BoostStore, CarItemStore, CarWashStore, FuelStore, Store; View: ActiveUpfrontView, CommitmentProgressView, ContentView, CustomProductView, PricingTermsView.
- Protocols: no local protocol declaration in the scanned source.
- Methods:
body,checkCurrentUserState,observeEntitlementUpdates,transformOwnedNonConsumables,transformStatuses,checkCustomerEntitlements,loadProducts,observeErrors. - Files:
SKDemo/SKDemoApp.swift,SKDemo/In App Purchase/Store.swift,SKDemo/View/ContentView.swift,SKDemo/View/Miscellaneous/CarItemStore.swift,SKDemo/View/Stores/BoostStore.swift,SKDemo/View/Stores/SubscriptionStore.swift.
Architecture takeaways
SKDemoAppis the main source-visible entry or composition anchor for this sample.- Framework work reaches SwiftUI, StoreKit, SKDemoServer, SwiftData through a deliberately small high-level chain; the detailed API graph remains inside the cited implementation files.
- Stored-property evidence identifies lifecycle collaboration; it does not by itself prove exclusive object ownership.
- Access-control conclusions separate verified language visibility from the likely design rationale.
- The source does not justify labeling the design protocol-oriented.
Source map
| Source file | Relevant symbols |
|---|---|
SKDemo/SKDemoApp.swift |
SKDemoApp, CustomerEntitlementsViewModifier, ProductLoaderViewModifier, ErrorObserverViewModifier |
SKDemo/In App Purchase/Store.swift |
Store, StoreError |
SKDemo/View/ContentView.swift |
ContentView, GarageButton, ContentGrid, SKDemoPlusSubscriptionOfferViewStyle |
SKDemo/View/Miscellaneous/CarItemStore.swift |
CarItemStore, ContentGrid, StoreHeader, BackgroundGradient |
SKDemo/View/Stores/BoostStore.swift |
BoostStore, CustomProductView, BoostProductViewStyle, BoostProductViewButtonStyle |
SKDemo/View/Stores/SubscriptionStore.swift |
SubscriptionStore, FamilySharingSubscriptionOptionGroupSet, SubscriptionOptionGroup, SKDemoPlusMarketingContent |
SKDemo/View/Miscellaneous/ImageNameConstants.swift |
ImageNameConstants, BoostStore, Car, CarItem, ContentView, FuelStore, Garage, PremiumFeatureCard, SubscriptionStore, BillingPlan, OfferCode |
SKDemoServer/Sources/Consumable.swift |
Consumable, CodingKeys |
SKDemoServer/Sources/Server.swift |
Server, ServerError |
SKDemo/View/SelectedCarView.swift |
SelectedCarView, SelectedCarMetricsView |