Monetization: In-App Purchases & Subscriptions
iOS Development — Production & Publishing
Chapter 8 · Monetization: In-App Purchases & Subscriptions
Chapter 6 mentioned in-app purchases briefly, as one more piece of App Store Connect metadata. This chapter covers the real, working mechanics behind them — StoreKit 2, Apple's modern, Swift-native purchasing API.
The Four Real Product Types
| Type | Real, Concrete Example |
|---|---|
| Consumable | Purchasable repeatedly — an in-app currency, extra credits |
| Non-Consumable | A one-time unlock — removing ads, an unlocked premium feature |
| Auto-Renewable Subscription | Recurring access that renews automatically until cancelled |
| Non-Renewing Subscription | A fixed-length access period the user must manually repurchase |
Making and Verifying a Purchase
StoreKit 2's own real API is genuinely built around Swift's async/await —
the same real concurrency model Architecture & Data Chapter 2 already covered — rather than the
older, delegate-callback-based approach of StoreKit 1.
Real Commission Rates
Verified directly against Apple's own current Small Business Program documentation:
| Situation | Real, Verified Commission |
|---|---|
| Standard rate | 30% of proceeds |
| Small Business Program | 15% — real eligibility: under $1 million USD in prior-year proceeds |
| EU, alternative terms, subscriptions after year one | A real, further-reduced 10% |
Testing Purchases Locally
Verified directly against Apple's own StoreKit documentation: StoreKit Testing in Xcode provides a real local sandbox — a StoreKit Configuration file defining test products directly inside Xcode, letting purchases be tested entirely on a simulator with zero real App Store Connect setup or real money involved.
Hands-On Exercises
TaskFlow is considering a "Pro" tier unlocking unlimited tasks permanently, versus a recurring monthly cloud-sync subscription. Explain, in your own words, which real StoreKit 2 product type fits each, and why.
📄 View solutionExplain, in your own words, why .pending is a genuinely different real outcome from an error, and why an app must handle it as its own distinct case rather than treating it as a failed purchase.
Explain, in your own words, why testing purchases through StoreKit Testing in Xcode's own local sandbox is genuinely preferable to testing directly against a live App Store Connect in-app purchase during development.
📄 View solutionChapter 8 Quick Reference
- Four real product types: consumable, non-consumable, auto-renewable subscription, non-renewing subscription
product.purchase()is a real, async StoreKit 2 call — handle.success,.userCancelled, and.pendingas genuinely distinct outcomes- Every real transaction is cryptographically signed (JWS) by the App Store itself
- Standard commission: 30%; Small Business Program (real, verified): 15% under $1M/year; EU alternative-terms subscriptions after year one: a real 10%
- StoreKit Testing in Xcode provides a real local sandbox with zero App Store Connect setup or real money required