Consumables, non-consumables, and subscriptions: choosing the right iOS in-app purchase model

A structured comparison of the three primary iOS IAP purchase types — consumables, non-consumables, and auto-renewing subscriptions — covering revenue predictability, App Store tooling, the non-consumable restore requirement, hybrid architectures, and a decision framework for choosing the right model before you build.

When you open App Store Connect and tap In-App Purchases → Create, Apple immediately asks you to choose a type. That decision shapes every downstream choice: how you price across 175 territories, which promotional tools you can use, how predictable your revenue will be, and what users expect when they reinstall. Most guides assume you've already chosen subscriptions. This post covers all three primary models side-by-side so you can make a deliberate decision before you build.

The three IAP purchase types Apple supports

Apple defines four In-App Purchase types in its documentation, but one — the non-renewing subscription — is largely a legacy format used for fixed-duration seasonal content such as magazine archives. Modern apps almost always decide between these three:

Consumables are products that are purchased, used, and depleted. AI prompt credits, in-game coins, photo-processing jobs, and cloud render minutes are classic examples. A user can buy the same consumable product multiple times. Apple does not track the balance on your behalf — your server or local app logic must record what has been consumed and how much remains.

Non-consumables are permanent unlocks. A user purchases a product once, and it is theirs forever across every device signed in to the same Apple ID. Dark mode access, a premium level pack, an extra export format, or a “pro” feature tier are typical non-consumables. Apple requires that non-consumables be restorable via a Restore Purchases mechanism — this is an App Store Review requirement, not merely a best practice.

Auto-renewing subscriptions provide ongoing access to content or features for a recurring billing cycle: weekly, monthly, quarterly, semi-annually, or annually. Apple manages renewal, failed-payment retry, the grace period, and the cancellation flow. Subscriptions also unlock the richest set of promotional mechanics: introductory offers, promotional offers for win-back, a managed price-change flow with grandfathering, and Family Sharing opt-in.

Revenue predictability and lifetime value

Subscriptions provide the most predictable revenue trajectory of the three models. Once a subscriber renews past the first billing cycle, each subsequent renewal is a relatively high-probability event. RevenueCat’s published research has shown that annual subscribers in particular exhibit substantially lower short-term churn than monthly plans. This predictability matters for small teams: you can forecast cash flow, justify new territory pricing experiments, and model the return on paid acquisition more reliably.

Non-consumables sit at the opposite end. Revenue is almost entirely driven by new install volume and paywall conversion. A seasonal sale or a feature launch can lift it, but there is no renewal tail. That said, churn is zero by definition: a user who bought “pro” two years ago still has it. For utility apps where a genuine one-time value exchange is the right model — a PDF scanner, a unit converter, a specialised measurement tool — non-consumables avoid the trust problem subscriptions can create when users feel the recurring charge is not being earned month after month.

Consumables can produce higher revenue per highly engaged user than subscriptions can capture at a sustainable price point. Mobile gaming demonstrates this pattern consistently: committed players in some categories spend significantly more on top-ups than any equivalent subscription would generate. But consumable revenue is directly coupled to engagement. Users who drift from active use stop spending without ever officially churning, and the revenue signal can be harder to diagnose and act on.

App Store tooling: what each model unlocks

Choosing your IAP type is not just a conceptual decision — it determines which App Store mechanics are available to you.

Subscriptions only: Introductory offers (free trial, pay-upfront, pay-as-you-go), promotional offers for existing subscribers to support win-back campaigns, the managed price-change flow with purchase-price preservation for grandfathered users, Family Sharing opt-in, and real-time App Store Server Notifications for every lifecycle event from initial purchase through cancellation and billing failure.

Non-consumables: Territory pricing via the standard tier system, Universal Purchase support (if you also publish on macOS), and the restore-purchases requirement. No promotional offer tooling at the SKU level beyond standard price reductions. No lifecycle events from Apple’s servers.

Consumables: Territory pricing via the standard tier system. No restore requirement. No introductory or promotional offer mechanics at the SKU level natively — though you can build server-side promotional logic by controlling which product identifiers are surfaced to which users, or by timing a standard App Store price change around a promotional window.

One practical implication: if you choose subscriptions, you gain real-time visibility into your subscriber lifecycle. A renewal, a cancellation, a billing failure, or a refund each generates a server-to-server notification you can respond to with an email, an in-app prompt, or a win-back flow. For consumables and non-consumables, your backend learns about purchases only when your app reports them. If lifecycle automation is part of your retention strategy, subscriptions are the only IAP model Apple’s infrastructure actively supports. The StoreKit 2 guide covers how to verify entitlements and respond to lifecycle changes in practice.

The non-consumable restore requirement

In StoreKit 2, the correct approach is to call Transaction.currentEntitlements on app launch and verify each transaction’s revocation status before granting access. In the older StoreKit 1 API, you call SKPaymentQueue.default().restoreCompletedTransactions() and listen for the paymentQueue(_:updatedTransactions:) delegate callback. Either way, the restore button must be visible in your UI — typically in your settings screen or directly on the paywall — and it must work reliably even when the user has already restored once.

Users who switch to a new device, sign in on a family member’s iPhone, or reinstall after a factory reset rely on this working correctly. A broken restore flow generates support requests, one-star reviews citing “they stole my purchase,” and App Store rejections in roughly equal measure. Build and test it before you submit.

Hybrid IAP architectures that work in practice

Many successful apps combine models rather than committing to one exclusively. Three patterns appear frequently across the App Store:

Subscription + consumables: A base subscription grants access to core features, while server-intensive operations — AI inference, cloud rendering, large-file processing — are sold separately as consumable credits. The subscription provides a predictable revenue floor; the consumable layer captures additional spend from power users without forcing a price increase that would hurt conversion across the broader subscriber base. This is increasingly common in AI-powered productivity tools.

Non-consumable unlock + consumables: A one-time “pro” purchase removes ads and enables offline mode, while optional credits top up premium capabilities. This works well for apps with a segment of users who want a permanent relationship and a different segment that prefers to pay as they use.

Subscription + lifetime non-consumable: Growing in popularity as some users have grown resistant to recurring charges. The “lifetime” purchase is technically a non-consumable product in App Store Connect. It converts well with high-intent users and complements the standard subscription options on a paywall. Pricing it at three to five times the annual subscription rate is a common approach that captures fair value without undermining recurring conversions. See our guide to iOS paywall design patterns for how to present these options without confusing the user.

The primary risk with hybrid models is complexity — both in your entitlement logic and in how users understand what they are purchasing. Before adding a second IAP type, verify that the scope of each product is unambiguous and that your support documentation addresses every combination a user might find themselves in.

A decision framework before you commit

Four questions help narrow the choice:

1. Does the value compound over time? If your app’s core purpose is ongoing — a daily habit tracker, continuous access to a content library, a background running service — a subscription frames the exchange correctly. If the value is delivered once and does not appreciably change after purchase, a non-consumable is a more honest model.

2. Is engagement variable across your user base? High variance in usage often favours subscriptions over consumables. A flat monthly charge does not penalise low-engagement months the way a credit-based model does, which means you retain revenue from moderate users who would otherwise stop buying.

3. What does your category norm suggest? User expectations differ sharply by App Store category. Productivity, health, and media apps have broadly normalised subscriptions. Casual games have normalised consumables. Specialised one-time utility tools — calculators, converters, document editors — still convert well with non-consumable unlocks. Fighting a category norm adds friction to conversion without a clear benefit.

4. Do you need Apple’s retention infrastructure? If you want grace periods, billing retry, win-back promotional offers, and real-time server notifications, only subscriptions give you that. If your retention strategy is entirely within the app — onboarding sequences, push notifications, in-app prompts — consumables and non-consumables are viable without it.

There is no universally correct answer. The right model is the one that matches the nature of your value delivery, your users’ expectations, and the backend infrastructure your team can actually build and maintain. Commit to it early; switching IAP types after launch is technically straightforward but can confuse existing users and complicate your entitlement logic considerably.

Sources and further reading

• Apple Developer: In-App Purchase overview
• App Store Review Guidelines §3.1 — In-App Purchase
• Apple Developer: Restoring purchased products (StoreKit)
• RevenueCat blog — subscription benchmarks and industry data
• Apple Human Interface Guidelines: In-App Purchase
• Apple Developer: StoreKit framework documentation