💰 In-App Purchases & Subscriptions

In App Store Connect → your app → Monetization choose In-App Purchases or Subscriptions and create each product:

• Consumable — used up and re-buyable (coins, credits).
• Non-consumable — bought once, owned forever (lifetime unlock, pro features).
• Auto-renewable subscription — recurring; must live inside a Subscription Group (create the group first; users can switch between products within a group, which is how upgrades/downgrades work).
• Non-renewing subscription — fixed-duration access you manage yourself (rare; you handle expiry and cross-device sync).

Name product IDs in a stable scheme you'll never change, e.g. pro_monthly, pro_yearly, coins_500 — product IDs are permanent and can never be reused, even after deletion.

Each product needs, before it can be submitted:

• Reference name — internal only (shows in reports).
• Product ID — e.g. pro_monthly (permanent!).
• Price — pick a price point; subscriptions also choose duration (and optional intro offers / free trials).
• Localized display name + description — what users see on the payment sheet, in at least your primary language. Keep the display name short ('Pro Monthly').
• Review screenshot — a screenshot of your purchase UI/paywall showing this product. It's only for the reviewer, not the store. A simulator screenshot of the paywall is fine — but it must exist or the product can't be submitted.
• Review notes — optional; explain anything odd (e.g. 'Pro unlocks the Stats tab').

The first IAP for an app must be submitted together with an app version; later products can be submitted on their own.

Two solid paths:

RevenueCat (recommended default)

• Wraps StoreKit and handles receipt validation, restore, cross-device entitlement status, renewals, refunds, and webhooks — the edge cases that eat weeks.
• Free under $2.5K monthly tracked revenue, ~1% after.
• SDKs for every stack: react-native-purchases, purchases-flutter, native Swift.
• Gives you a server-side source of truth and analytics from day one.

StoreKit 2 direct

• No fee, no third party, modern async/await API (Product.purchase(), Transaction.currentEntitlements).
• You own: server-side verification (App Store Server API / JWS transaction verification), restore logic, subscription-status edge cases (billing retry, grace period), and cross-platform entitlement sync if you ever ship Android.
• Right choice if you're native-only, single-platform, and allergic to dependencies.

Also worth knowing: Adapty and Qonversion (RevenueCat alternatives), Superwall (paywall A/B-testing layer that pairs with RevenueCat). For a first app: RevenueCat unless you have a reason otherwise.

1. Create a project at app.revenuecat.com → add an App Store app with your Bundle ID.
2. Generate an App Store Connect API key (Users and Access → Integrations → App Store Connect API, role App Manager) and an In-App Purchase key; upload them to RevenueCat so it can validate purchases and read product/subscription state.
3. Define an Entitlement (e.g. pro) — the abstract 'thing the user has'.
4. Attach your App Store products (pro_monthly, pro_yearly) to the entitlement.
5. Create an Offering (e.g. default) with Packages (monthly/annual) — your paywall fetches the current offering so you can change products without an app update.
6. Integrate the SDK and check entitlement status at launch.

Before submitting, verify every box:

• Restore Purchases button is visible (paywall and/or settings). RevenueCat: Purchases.restorePurchases(). Missing restore is a guaranteed rejection.
• Paywall shows the full terms: price, billing period, and that it auto-renews, plus links to your privacy policy and Terms of Use (auto-renewable subs require a Terms of Use link — Apple's standard EULA link is acceptable).
• Digital goods use IAP — no Stripe/PayPal/web-checkout links for digital content, including inside webviews (Guideline 3.1.1).
• Physical goods/services must NOT use IAP — use Stripe/Apple Pay for those instead.
• ⏱️ External purchase links are policy-in-motion: since the Epic v. Apple injunction, US storefront apps have gained limited rights to link out to external payment — but terms, disclosure sheets, and commissions have changed repeatedly. Check Apple's current policy before building anything on external links.

Never submit untested IAP — reviewers buy your products.

Sandbox tester route (closest to production):

1. App Store Connect → Users and Access → Sandbox → Test Accounts → + — create a tester with an email that is not an existing Apple ID (plus-addressing works: you+sandbox1@gmail.com).
2. On a real device: Settings → App Store → Sandbox Account (sign in there, not in the main Apple ID slot).
3. Run a development build and purchase — the sheet shows [Environment: Sandbox] and no real money moves.

StoreKit Configuration file route (fastest iteration):

• Xcode: File → New → File… → StoreKit Configuration File, optionally synced from App Store Connect; select it in the scheme (Product → Scheme → Edit Scheme… → Run → Options → StoreKit Configuration). Works in the simulator, supports clock-acceleration and refund simulation.

Know the quirks: sandbox subscriptions renew on an accelerated schedule (e.g. 1 month → 5 minutes), and TestFlight purchases are free and behave sandbox-like — warn your beta testers.