IAP availability and removal checklist

Name the availability reason

Write whether the product is being removed because of a failed experiment, pricing change, regional legal constraint, product replacement, support burden, App Review issue, tax concern, or entitlement migration. The reason determines how careful the rollout must be.

Do not confuse hiding a paywall with removing a product from sale. Existing customers may still need restore, support, receipt validation, or entitlement access even when new customers cannot buy the product.

AppReviewReady interpretation: availability changes should be planned like release changes because they affect revenue, customer trust, and the evidence reviewers see in the app.

Reconcile storefront and app state

• List countries or regions where the product is sold, hidden, or replaced.
• Remove or update paywall placements that advertise unavailable products.
• Keep restore paths for prior purchasers.
• Check localized copy, screenshots, marketing URLs, and onboarding.
• Confirm analytics separates product removal from purchase failures.

Protect existing entitlements

Existing users should not lose promised value merely because acquisition strategy changed. Verify the app and server still recognize old receipts, family-shared access where applicable, refunds, restores, upgrades, and support overrides.

If the product is replaced, decide whether old customers are grandfathered, migrated, offered an upgrade, or left with the original entitlement. Ambiguous migration creates refund risk and App Review confusion.

When removal is connected to a rejection, make the app path explicit. Reviewers should not encounter a broken purchase button, missing product error, or unsupported state while verifying the fix.

Release the change safely

1. Freeze the product state and app build expected at release time.
2. Update server product allowlists and paywall configuration.
3. Test new purchase, restore, no-product, and legacy entitlement states.
4. Prepare support copy for unavailable, retired, and migrated users.
5. Monitor purchase errors, restore failures, refunds, and support volume.

Availability change record

The record connects App Store Connect state with app behavior. Without it, teams often diagnose unavailable products as StoreKit bugs even though the cause is an intentional configuration change.

Use rollback criteria before the change ships. If restore failures, refund requests, or paywall errors increase, the team should know whether to restore availability, patch the app, or update server configuration.

After the removal window, inspect whether revenue moved to the intended replacement product. A clean removal should reduce confusion, not simply push users into support.

Keep a separate note for users who purchased before the change. They are the group most likely to create refunds, negative reviews, or support escalations if the app silently changes access language after the product disappears from sale.

Availability record:
Product ID: [id]
Change: [hide/remove/replace]
Storefronts: [regions]
Existing entitlement: [rule]
App UI updated: [yes/no]
Support copy: [link]
Rollback: [steps]