Overview of In-App Purchase

A high-level look at IAP.  Could be wrong.  Oriented to a trial-use or freemium app.


A user can acquire your app without using IAP.  That is, your app can be in the store without using IAP.

“Acquire” does not necessarily mean “pay for”.  If your app is free, a user can get it without payment, by browsing the App Store.  The free portion of your app is a product with a receipt, but it is not a product that you show in your app’s store facade, since the user already has it.


Apparently, Apple does not want “trial versions” of apps in the store.  But this just means: they don’t want duplicates (where one is crippled and the duplicate not) and  instead prefer one version with IAP.  The version in the store can still be a trial version in this sense: the app can require an IAP purchase to continue certain capabilities beyond a trial period.  Probably Apple also doesn’t want an app that won’t do anything after a trial period.  In other words, an app should continue to do something minimally useful after a trial period.

Probably they don’t even want you to advertise that an app is a trial-version: the user will see the IAP icon in the store, and know that the app may be limited (from the get-go, or after a trial period.)

Probably most users expect that certain apps will be trials or crippled.  Don’t worry about offending potential customers.

The Data Model

An app has one or more products.

A product has one or more receipts.  Each receipt is for a transaction.  (StoreKit lets you play back the transactions.)

A product has one or more content/capabilities.

Generally content/capabilities are one-to-one with receipts.

I am glossing here: it is probably only subscription type products that have many receipts for the same product.  That is, a subscription product entitles the purchaser to many contents, and each content has its own receipt.

The Facade Pattern

Your app presents a facade to the store.  In other words, your app has GUI for IAP.  Behind the scenes, your app collaborates with the store server using StoreKit.  Your app is a client of the store server.

You must submit a screen capture of your store facade during the app review process.

Validating a productID is the process for insuring that the products your facade presents to the user are indeed products in the store server (configured using iTunesConnect.)

Receipt Subclasses


  • bona fide Apple receipts, stored in the app bundle and maintained by the OS/framework
  • ad hoc receipts, stored e.g. in NSUserDefaults and maintained by your app

The difference is in how much code you need, and strength of receipt against hacking.


A purchase is restorable when a purchaser:

  • deletes your app from a device
  • buys a new device
  • enables Family Sharing for other devices

The store maintains records of purchases.   Your app must collaborate.

If you use ad-hoc receipts, when a user deletes your app, the settings for the app are deleted.  When a user re-downloads your app,  since you are not using Apple receipts, you won’t know that the user has downloaded it before (in another transaction.)  Thats a weakness of ad-hoc receipts.  Your app won’t have any record that it was downloaded previously.  Presumably, most users will purchase rather than repetitively download your free app (just to reset the trial period.)

Creating products

You need to create a product on both sides:

  • in the real store using iTunesConnect
  • in your store facade (hard coding productIDs or putting them in a .plist file)


There is a sandbox for testing IAP.  (If it works in the sandbox, it should work in the real world.  The only way to test in the real world is to actually purchase; be the first one if you are worried about it.)

Test Cases

You should test:

  1. Normal purchase: success on the main path.
    1. User declines: in your store facade, answers “No thanks.”
    2. User declines: Settings>Restrictions>IAP is On (Restrictions enabled, IAP restriction On)
    3. User declines : Cancels StoreKit’s log in dialog to the store.
    4. User declines : Cancels StoreKit’s confirmation dialog for purchase
  2. Product invalid: for some reason, what your app thinks is a product is not in the store.  (Your app configuration is wrong, or the store has removed your product.)
  3. Restoration: user installs your app on another device, or deletes and reinstalls your app.
  4. Store facade can be paused and resumed with the Home button
  5. Store facade handles user bottom double swipe up the Control Center

For a trial-use app:

  1. In the trial period: all capabilities
  2. After the trial period: capabilities are denied
  3. After the trial period: you dun the user when they try to use a capability (you present your store facade.)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s