Consumable vs non-consumable IAP product type review checklist

Define entitlement lifetime first

Consumables are used up: coins, hints, credits, extra lives, upload packs, or one-time processing units. Non-consumables are owned permanently: unlock a feature, remove ads, buy a level pack, or enable a pro tool.

If the entitlement expires, renews, or covers a service period, consider subscription types instead. Do not force time-limited access into a non-consumable just because implementation seems easier.

Respect product type permanence

• Product IDs should be named for durable meaning, not a temporary campaign.
• Purchase type should be decided before metadata, pricing, and server entitlements are wired.
• Non-consumables need restore behavior and durable ownership.
• Consumables need balance accounting, delivery confirmation, and failed-delivery recovery.
• Support should be able to explain what the user bought without reading code.

Make purchase behavior match the type

A non-consumable that disappears after a month looks broken or misleading. A consumable that can be restored infinitely can become a revenue and support problem. App Review can catch these mismatches when purchase copy, restore behavior, and entitlement state disagree.

AppReviewReady interpretation: test the user promise rather than only the StoreKit transaction. The app should say exactly whether the item is used once, lasts forever, or depends on an account service.

Run product-type QA before submission

1. Purchase the product, interrupt delivery, relaunch, and verify final entitlement state.
2. Restore purchases and confirm only restorable products reappear.
3. Refund or revoke where sandbox tooling allows and verify access changes appropriately.
4. Test multiple devices, app reinstall, signed-out state, and server outage.
5. Compare product display name, description, price, and in-app copy with the actual entitlement.

Create a product type decision record

If a product type is already wrong, create a new product with the correct model and plan migration. Do not hide a different entitlement behind the old product ID.

For apps with both consumable credits and permanent unlocks, test the same paywall after every purchase type. The user should never confuse a replenishable balance with a durable ownership right.

If balances sync across devices, record whether unused consumables are tied to the Apple Account, app account, or server wallet. That answer drives restore, support, and fraud handling.

IAP type decision:
Product ID: [id]
Type: [consumable, non-consumable]
User promise: [what is bought]
Entitlement lifetime: [used up/permanent]
Restore behavior: [yes/no]
Server record: [balance/ownership]
Migration if wrong: [new product plan]