Understanding iOS In‑App Purchase (IAP): Guidelines, Process, Subscriptions, and Security Pitfalls

Apple’s App Store Review Guidelines require iOS apps to use the In‑App Purchase (IAP) API for selling digital content, forbidding non‑IAP systems, physical goods, and demanding that purchased credits be consumed within the app.

To implement IAP, developers first configure an App ID and provisioning profile on developer.apple.com, create the app in iTunes Connect, add in‑app purchase products with price and product IDs, and set up sandbox test users. The purchase flow then proceeds as follows: the user selects a product and taps purchase, authenticates with their Apple ID, Apple’s servers validate and charge the account, return a success receipt, and the app displays the purchased content.

Subscriptions use natural‑month cycles; for example, a purchase on January 3 expires on February 3, while a purchase on January 31 expires on March 1. Apple automatically handles renewal, attempting payment ten days before expiry and retrying for a short grace period after failure. Free‑trial periods can be configured in iTunes Connect and are reflected in the initial receipt.

After a purchase, the client receives a receipt that must be sent to the developer’s server for verification. The server forwards the receipt to Apple’s verification endpoint, parses fields such as user_id, product_id, purchase_date, and transaction_id, and grants the appropriate entitlement, using HTTPS and request signing to protect the communication.

Security threats include tools like IAP Cracker that manipulate the transactionState enum and IAPfree which performs DNS‑based MITM attacks to spoof Apple’s servers. Because the client can be compromised, server‑side receipt validation is essential to prevent fraudulent access.

Apple’s account system is based on the Apple ID, which may be shared across multiple devices, while the app often has its own user accounts. Developers must record the original transaction ID from the receipt and map it to the correct app‑level user, especially when handling subscription renewals across different app accounts.

Pricing is set pre‑tax in iTunes Connect; Apple converts the base price to local currencies for each of the supported 155+ regions. Products can be grouped (e.g., platinum, gold, VIP) where a user can select only one tier. After a year of continuous subscription, the revenue share can increase to 85%, and a 60‑day grace period is provided for missed renewals.

Common pitfalls include sandbox limitations such as the inability to cancel subscriptions, occasional missing transaction IDs in receipts, and uncertainty about the maximum length of receipt lists. Developers should design around these constraints and avoid relying on sandbox‑only behavior.

On Android, developers may prefer native payment solutions like Alipay or WeChat Pay, which have broader user bases and lower fees, but the article invites sharing of Android IAP experiences.