IAP product ID lifecycle checklist
Product IDs become permanent references in code, receipts, support tools, analytics, and finance workflows.
Design in-app purchase product IDs before campaigns or code depend on them. Apple documents creating in-app purchases in App Store Connect. AppReviewReady interpretation: product IDs should have naming rules, ownership, lifecycle state, and retirement decisions because changing a commercial taxonomy after launch is expensive.
Design the product taxonomy
Define naming rules for subscription tiers, consumables, non-consumables, bundles, add-ons, legacy products, experiments, and regional variants. Product IDs should describe durable commerce meaning rather than a temporary campaign slogan.
Keep product ID structure separate from display names. Marketing copy can change by locale or campaign, but product IDs will appear in code, receipts, analytics, server logic, and support lookup tools.
A good taxonomy lets a new operator understand whether a product grants access, spends down, renews, upgrades, unlocks a one-time feature, or exists only for a migration.
Respect product permanence
- Create products only after product type and entitlement duration are clear.
- Avoid test products in the production app record unless they are intentionally isolated.
- Document which code paths, server tables, and dashboards reference each product ID.
- Do not reuse a retired product ID for a different promise.
- Keep legacy IDs readable for restores, refunds, and customer support.
Separate test, launch, and legacy states
Sandbox testing, TestFlight testing, production purchase, and legacy restores can all reference product IDs differently. Record which IDs are active in each environment and which are only expected in historical receipts.
AppReviewReady interpretation: product ID governance protects revenue because it reduces the chance that a working paywall sells an entitlement the server cannot recognize. It also protects review because reviewers can test the same product that customers will buy.
When adding an upsell or experiment, decide whether it needs a new product ID or only new paywall copy. A new ID creates support and analytics work; a copy change may be enough when the entitlement does not change.
Control product ID changes
- Assign an owner for every new product ID.
- Review type, entitlement duration, price, availability, and display copy before creation.
- Update app code, server allowlists, analytics, and support macros together.
- Test purchases and restores before public launch.
- Mark retired IDs with restore and support instructions.
Product ID ledger
The ledger turns product IDs from hidden constants into managed revenue objects. Finance, growth, engineering, and support can use the same record instead of reverse-engineering purchase behavior from receipt history.
Review the ledger before every pricing, offer, or product-page experiment. If two products look similar but grant different value, the paywall and support copy should make the difference obvious.
After launch, compare product ID performance with support cases. High refunds or low retention may indicate that the ID represents a confusing entitlement rather than a bad price.
Product ID record: Product ID: [id] Type: [type] Entitlement: [duration/value] Status: [draft/live/retired] Code owner: [team] Server mapping: [link] Support rule: [restore/refund guidance]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check product ID governance
Review IAP IDs, entitlement mapping, legacy states, and support rules before launch.
Open the tool