In App Purchase（程式內購買）為蘋果開發人員們打開了一個新的盈利渠道，如果您對此並不瞭解，下面這段 CocoaChina 會員“leon”翻譯的 In App Purchase 詳細介紹一定不能錯過。

一、In App Purchase概覽

Store Kit代表App和App Store之間進行通訊。程式將從App Store接收那些你想要提供的產品的資訊，並將它們顯示出來供使用者購買。

當用戶需要購買某件產品時，程式呼叫StoreKit來收集購買資訊。下圖即為基本的store kit 模型：

Store Kit的API只是為程式新增In App Purchase功能的一小部分。你需要決定如何去記錄那些你想要提交的產品，如何在程式中將商店功能展現給使用者，還要考慮如何將使用者購買的產品提交。本章的剩餘部分會展示整個流程。

Products

產品可以是任意一項你想要出售的特性。產品在iTunes Connect中被組織，這和你新增一個新的App是一樣的。支援的產品種類共有四種：

1. 內容型。包括電子書，電子雜誌，照片，插圖，遊戲關卡，遊戲角色，和其他的數字內容。

2. 擴充套件功能。這些功能已經包含在App內部。在未購買之前被鎖定。例如，你可以在一個遊戲程式中包含若干個小遊戲，使用者可以分別來購買這些遊戲。

3. 服務。允許程式對單次服務收費。比如錄音服務。

4. 訂閱。支援對內容或服務的擴充套件訪問。例如，你的程式可以每週提供財務資訊或遊戲入口網站的資訊。應該設定一個合理的更新週期，以避免過於頻繁的提示困擾用 戶。要記住：你將負責跟蹤訂閱的過期資訊，並且管理續費。App Store不會替你監視訂閱的週期，也不提供自動收費的機制。

In App Purchase為建立產品提供了一種通用的機制，如何操作將由你負責。當你設計程式的時候，有以下幾點需要注意：

1. 你必須提供電子類產品和服務。不要使用In App Purchase 去出售實物和實際服務。

2. 不能提供代表中介貨幣的物品，因為讓使用者知曉他們購買的商品和服務是很重要的。

通過App Store註冊產品

每個你想要出售的產品都必須先通過iTunes Connect在App Store註冊。你需提供產品的名稱，描述，價格和其他在程式中用到的元資料。

需為產品指定唯一的識別符號。當你的程式利用Store Kit和App Store通訊時，會使用產品標識來取回產品的資訊。如果使用者購買某個商品時，程式可以用該標識來將產品標註為“已購買”。

App Store將前面提到過的產品種類簡化為以下三種：

1. 消耗性商品。 該類商品在需要時被單次購買。比如，單次服務。

2. 非消耗性商品。 該類商品只需被某個使用者購買一次，一旦被購買，和該使用者iTunes 賬戶關聯的裝置都可以使用此商品。Store Kit為在多個裝置上重新儲存非消耗性商品提供了內建的支援。

3. 訂閱類。訂閱類商品擁有以上兩種型別的特性。和消耗性商品一樣，訂閱類商品可以被多次購買； 你可以在程式內部加入自己的訂閱計劃更新機制。 另外，訂閱類商品必須提供給和某一使用者關聯的所有裝置。In App Purchase期望訂閱類商品可以通過外部伺服器交付。你必須為多個裝置的訂閱服務提供相應的支援。

交付方式

交付機制在程式In App Purchase的設計和實現種有很重要的意義。有兩種基本的模型可以用來交付產品：內建型別（Built-in model）和伺服器型別（Server model）。 不管使用那種模型，你都需要維護產品列表，並保證當用戶購買後，成功的交付產品。

（一）內建產品型別

使用這種模型。 需要交付的產品已經在程式內部。 這種方式通常用在一些被鎖定的功能上。 也可以用來交付在程式束（App Bundle）中的內容。 該方式的一個重要的優點是你可以及時的給客戶交付產品，大多數的內建產品應為非消耗性商品。

注意：In App Purchase不提供購買補丁的功能。 如果需要更改app的bundle，你必須向App Store提交新的app版本。

為了標識產品，程式要在bundle中儲存產品的識別符號。內建模式下，Apple建議使用plist來紀錄產品的識別符號。 內容類應用可以使用折衷方式很方便的新增新的內容，而不改動程式本身。（原話為： Content-driven applications can use this to add new content without modifying the source for your application，不是很懂，感覺應該是說類似是用plist來管理產品列表，因此就不需要在新增新產品的時候改動程式了。再議。。。）

當成功購買產品後，程式應將鎖定的功能解鎖，提供給使用者。 解鎖的最簡單方式是修改程式偏好設定（Application Preferences）。 當用戶備份手機資料的時候，程式偏好設定也會隨之備份。 程式可能需要建議使用者在購買產品後備份手機以免丟失購買的內容。

上圖顯示了交付內建型產品的流程。

1. 程式通過bundle儲存的plist檔案得到產品識別符號的列表。

2. 程式向App Store傳送請求，得到產品的資訊。

3. App Store返回產品資訊。

4. 程式把返回的產品資訊顯示給使用者（App的store介面）

5. 使用者選擇某個產品

6. 程式向App Store傳送支付請求

7. App Store處理支付請求並返回交易完成資訊。

8. App獲取資訊並提供內容給使用者。

（二）伺服器型別

使用這種方式，要提供另外的伺服器將產品傳送給程式。 伺服器交付適用於訂閱、內容類商品和服務，因為商品可以作為資料傳送，而不需改動程式束。 例如，一個遊戲提供的新的內容（關卡等）。 Store Kit不會對伺服器端的設計和互動做出定義，這方面工作需要你來完成。 而且，Store Kit不提供驗證使用者身份的機制，你需要來設計。 如果你的程式需要以上功能，例如，紀錄特定使用者的訂閱計劃， 你需要自己來設計和實現。 

伺服器型別的購買過程

1. 程式向伺服器傳送請求，獲得一份產品列表。

2. 伺服器返回包含產品識別符號的列表。

3. 程式向App Store傳送請求，得到產品的資訊。

4. App Store返回產品資訊。

5. 程式把返回的產品資訊顯示給使用者（App的store介面）

6. 使用者選擇某個產品

7. 程式向App Store傳送支付請求

8. App Store處理支付請求並返回交易完成資訊。

9. 程式從資訊中獲得資料，併發送至伺服器。

10. 伺服器紀錄資料，並進行審(我們的)查。

11. 伺服器將資料發給App Store來驗證該交易的有效性。

12. App Store對收到的資料進行解析，返回該資料和說明其是否有效的標識。

13. 伺服器讀取返回的資料，確定使用者購買的內容。

14. 伺服器將購買的內容傳遞給程式。

Apple建議在伺服器端儲存產品標識，而不要將其儲存在plist中。 這樣就可以在不升級程式的前提下新增新的產品。

在伺服器模式下， 你的程式將獲得交易（transaction）相關的資訊，並將它傳送給伺服器。伺服器可以驗證收到的資料，並將其解碼以確定需要交付的內容。 這個流程將在“驗證store收據”一節討論。

對於伺服器模式，我們有安全性和可靠性方面的顧慮。 你應該測試整個環境來避免威脅。《Secure Coding Guide》文件中有相關的提示說明。

雖然非消耗性商品可以用內建模式來恢復，訂閱類商品必須通過伺服器來恢復。你要負責紀錄訂閱資訊、恢復資料。 消耗類商品也可以通過伺服器方式來紀錄。例如，由伺服器提供的一項服務， 你可能需要使用者在多個裝置上重新獲得結果。