Selling coins, unlocking a full version, or charging for a service on iOS is not a code problem first — it is a configuration problem. Every digital product you sell has to exist in App Store Connect, and Guideline 3.1.1 requires that any feature unlocked inside an app be sold through in-app purchase: no license keys, no QR codes, no cryptocurrency workarounds. Get the product configuration wrong and your submission fails before a single line of StoreKit is ever reviewed. This tutorial walks through the complete setup — product types, subscription groups, pricing, offers, sandbox testing, and the review expectations that decide whether your monetization goes live in 2026.
1. Choose the right product type
App Store Connect supports four in-app purchase types, and choosing correctly up front avoids painful migration later:
- Consumable — used once and depleted: game currency, power-ups, tips. It can be bought again.
- Non-consumable — bought once and permanently unlocked: a full version, filters, premium features. It must be restorable.
- Auto-renewable subscription — recurring access to content or services until the user cancels: SaaS, streaming, cloud storage.
- Non-renewing subscription — time-limited access that does not auto-renew and must be repurchased; rarely the right choice in 2026.
The guidelines set two hard rules around these: credits and in-game currencies purchased via in-app purchase may not expire, and you need a restore mechanism for any restorable purchases.
2. Sign the Paid Applications agreement first
Before any product can go live, the Paid Applications agreement must be in effect and your banking and tax information must be complete in App Store Connect. Products created while the agreement is pending sit in a limbo state and can be removed from sale. This is the most common reason an IAP submission stalls — the product exists, the agreement does not. (For the tax and banking forms themselves, see our Apple Developer tax setup guide.)
3. Create products with clean identifiers
In App Store Connect, go to My Apps → your app → Monetization (In-App Purchases) and add each product with:
- A Product ID in reverse-DNS form, for example
com.example.app.coins.100— it cannot be changed later, so plan the namespace. - A display name users will see on the payment sheet — short, self-explanatory, distinct from the app name and subscription group name.
- A price, a description, and a review screenshot showing exactly how the product is used inside the app.
4. Set up subscription groups and levels
Each auto-renewable subscription must belong to a subscription group — the set of plans users choose between at different access levels, prices, and durations. Apple recommends a single group for most apps, because a user can only hold one active subscription per group; one group prevents accidental double billing. Streaming apps that sell multiple channels use separate groups, and each group bills independently.
Within a group you rank subscriptions by level, and the level determines how switches behave — worth knowing before you build the UI: an upgrade takes effect immediately with a prorated refund of the old plan, a downgrade takes effect at the next renewal date, and a crossgrade switches immediately only when both plans are pay-up-front and the same duration. You can also surface in-app subscription management with showManageSubscriptions(in:) so users can upgrade or cancel without leaving your app.
5. Price it: 800 price points and the 70/85 revenue split
Auto-renewable subscriptions can be priced across 800 price points in all available currencies and tiers, with roughly 100 additional higher price points available on request. Prices are set per storefront, so you can hold parity across regions or adjust per market.
The revenue split shapes your model: during the first year of paid service you keep 70% of the subscription price at each billing cycle, and after one year of paid service that rises to 85%. Members of the App Store Small Business Program receive 85% from the very first billing cycle. Free trials and renewal extensions do not count toward the year of paid service, and if a subscription renews within 60 days of expiry, the clock resumes from the recovery date.
6. Add the modern offer toolkit
Apple's subscription page lists the offers that convert in 2026: introductory offers (free trials and pay-up-front discounts), promotional offers, offer codes (now available for macOS), and win-back offers, which are now available for re-engaging lapsed subscribers. A monthly subscription with a 12-month commitment is also a supported payment option for subscribers who want a lower monthly price.
For non-subscription apps, the guidelines allow a free time-based trial before the full unlock — a Non-Consumable item at Price Tier 0 named "XX-day Trial", with the trial duration, the content that disappears when it ends, and any downstream charges clearly communicated.
7. Implement StoreKit and verify server-side
In the app, StoreKit 2 provides product lookup, purchase, and transaction updates with a fraction of the boilerplate of the old API. On the server side, the App Store Server API plus App Store Server Notifications deliver real-time subscription status — renewals, billing retries, and cancellations — which is essential for granting and revoking access correctly. Relying on client-side checks alone is how subscription entitlement bugs happen.
8. Test every product in the sandbox
Test before you submit: use StoreKit Testing in Xcode for fast, offline purchase flows, and the sandbox environment for end-to-end purchases against your real App Store Connect products. Walk the entire path — buy, restore, renew, cancel — and make sure the review screenshot matches what a reviewer will actually see. App Review expects purchasable in-app purchases to be findable and reviewable inside the app; a product that cannot be reached in the build is a classic first-submission rejection.
9. Submit with complete review notes
In the App Review information section, explain how in-app purchase is used, note that products are testable in the sandbox, and provide any demo account the reviewer needs. Incomplete IAP configuration — an unsigned agreement, a product stuck in "Missing Metadata", or a purchase flow that breaks in sandbox — is one of the most common rejection reasons on the App Store. Fix those three and the review usually sails through.
The five-minute pre-submit check: Paid Applications agreement signed → every product ID in reverse-DNS form with display name and price → subscriptions in a single group with sensible levels → offers (trial, win-back, offer codes) configured with clear pricing → purchase, restore, and renewal tested in sandbox. Five checks, one monetization launch that works.
Configuration done right is the product
In-app purchase on iOS is a mature system: Apple handles payment processing, authentication, and receipts end to end, and billions of transactions flow through it every year. Your job is the configuration — the right product type, a clean group structure, prices that match your market, and a purchase flow that works in sandbox before it faces a reviewer. Get those right and monetization stops being a risk in your release cycle.