In-App Purchase Programming Guide----（八) ---- Preparing for App Review

Preparing for App Review

After you finish testing, you’re ready to submit your app for review. This chapter highlights a few tips to help you through the review process.

當你完成測試之後，就表示已經準備好提交應用以供審覈。 該章節重點介紹了一些提示來幫助你經過審覈過程。

Submitting Products for Review

1、遞交產品以供審覈

The first time you submit your app for review, you also need to submit in-app products to be reviewed at the same time. After the first submission, you can submit updates to your app and products for review independently of each other. For more information, see In-App Purchase Configuration Guide for iTunes Connect.

當你第一次提交審覈程序時，你還須要同時提交內置產品以供審覈。 第一次遞交經過之後，之後更新應用程序和產品時則能夠分別提交。 更多信息，請看 In-App Purchase Configuration Guide for iTunes Connect.

Receipts in the Test Environment

2、在測試環境中的收據

Your app runs different environments while in development, review, and production, as show in Figure 7-1.

當應用程序在開發，審覈以及產品過程當中，在不一樣的環境中運行。以下圖：

Figure 7-1  Development, review, and production environments

During development, you run a development-signed version of your app, which connects to your development servers and the test environment for the App Store. In production, your users run a production-signed version of your app which connects to your production servers and the production App Store. However, during app review, your app runs in a mixed production/test environment: it’s production signed and connects to your production servers, but it connects to the test environment for the App Store.

在開發過程當中，應用程序的版本是一個開發簽名的版本，它鏈接到你的開發服務器以及應用程序中的測試環境。 在產品過程當中，你的用戶運行一個產品簽名版本的應用程序，它鏈接到你的產品服務器以及產品應用商店。 然而，在應用程序審覈過程當中，你的應用程序運行在一個混合的產品/測試環境中：它是產品簽名而且鏈接到你的產品服務器，可是它鏈接到應用商店的測試環境中。

When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code 「Sandbox receipt used in production」, validate against the test environment instead.

當你驗證在服務器中的收據時，你的服務器須要可以處理一個產品簽名的應用程序，它從蘋果的測試環境中獲取它的收據。 推薦方法是老是首先爲你的產品服務器激活收據而不是爲產品應用商店。 若是激活出現「Sandbox receipt used in production" 錯誤，則驗證測試環境。

Implementation Checklist

3、實現覈對清單

Before you submit your app for review, verify that you’ve implemented all of the required behavior. Make sure you’ve implemented the following core In-App Purchase behavior (listed in order of a typical development process):

在遞交你的審覈應用以前，驗證你已經實現了全部須要的行爲。 確保你已經實現瞭如下內核內置購買行爲(以一個典型的開發過程順序列出)：

• Create and configure products in iTunes Connect.

  在iTunes Connect裏建立並配置產品。

  You can change your products throughout the process, but you need at least one product configured before you can test any code.

  你能夠在過程當中更改產品，可是在測試任何代碼前，你至少須要一個已經配置好的產品。

• Get a list of product identifiers, either from the app bundle or your own server. Send that list to the App Store using an instance of SKProductsRequest.

  從應用束或服務器上獲取產品識別碼列表(product identifiers). 用一個SKProductsRequest實例把列表發送給應用商店。

• Implement a user interface for your app’s store, using the instances of SKProduct returned by the App Store. Start with a simple inteface during development, such as a table view or a few buttons.

  Implement a final user interface for your app’s store at whatever point makes sense in your development process.

  使用應用商店返回的SKProduct,爲應用商店實現一個用戶界面。開發過程當中使用一個簡單的界面，好比一個表格視圖或一些按鈕。在開發過程當中運行順利後能夠實現一個最終的用戶界面。

• Request payment by adding an instance of SKPayment to the transaction queue using the addPayment: method of SKPaymentQueue.

  使用SKPaymentQueue的addPayment:方法來添加一個SKPayment的實例到交易隊列，用來請求支付。

• Implement a transaction queue observer, starting with the paymentQueue:updatedTransactions: method.

  使用paymentQueue:updateTransactions:方法來實現一個交易隊列觀察者(transaction queue observer)。

  Implement the other methods in the SKPaymentTransactionObserver protocol at whatever point makes sense in your development process.

  在你的開發過程當中有任何須要時， 在SKPaymentTransactionObserver協議裏實現其它方法。

• Deliver the purchased product by making a persistent record of the purchase for future launches, downloading any associated content, and finally calling thefinishTransaction: method of SKPaymentQueue.

   爲了之後可以啓動，作一個永久交易記錄，傳遞已被購買的產品，下載所有相關內容，並在最後調用SKPaymentQueue的finishTransaction:方法。

  During development, you can implement a trivial version of this code at first—for example, simply displaying 「Product Delivered」 on the screen—and then implement the real version at whatever point makes sense in your development process.

  在開發過程當中，你能夠只實現一個該代碼的簡易版本--好比，只是簡單的在屏幕上顯示「Product Delivered」字樣---而後在開發過程當中有任何須要時實現真實版本。 

If your app sells non-consumable items, auto-renewable subscriptions, or non-renewing subscriptions, verify that you’ve implemented the following restoration logic:

若是你的應用程序出售非耗材產品，自動更新訂閱，或者非自動更新訂閱，驗證你已經實現瞭如下恢復邏輯：

• Provide UI to begin the restoration process.

  提供UI來開啓恢復過程。 

• Retrieve information about past purchases by either refreshing the app receipt using the SKReceiptRefreshRequest class or restoring completed transactions using the restoreCompletedTransactions method of the SKPaymentQueue class.

  經過使用SKReceiptRefreshRequest類來刷新應用收據或者使用SKPaymentQueue類的restoreCompletedTransactions方法來恢復完整交易，來獲取過去購買的信息。

• Let the user re-download content.

   容許用戶從新下載內容。

  If you use Apple-hosted content, restore completed transactions and use the transaction’s downloads property to get an instance of SKDownload.

   若是你使用了蘋果託管內容，恢復完整交易並使用交易的downloads特性獲得一個SKDownload類的實例。

  If you host your own content, make the appropriate calls to your server.

   若是你本身託管本身的內容，正確訪問你的服務器。

If your app sells auto-renewable or non-renewing subscriptions, verify that you’ve implemented the following subscription logic:

若是你的應用程序出售自動更新或非自動更新訂閱，驗證你已經實現瞭如下訂閱邏輯：

• Handle a newly-purchased subscription by delivering the most recently published piece of content—for example, the latest issue of a magazine.

  經過傳遞最新發布的內容片段來處理一個嶄新的購買訂閱---好比，一本雜誌最新的問題。

• When new content is published, make it available to the user.

   當新內容發佈時，用戶是能夠使用的。

• When a subscription expires, let the user renew it.

   當一個訂閱到期後，容許用戶從新更新它。

  If your app sells auto-renewable subscriptions, let the App Store handle this process. Don’t try to handle it yourself.

   若是你的應用程序出售自動更新訂閱，容許應用商店處理該過程。不要嘗試本身來處理。

  If your app sells non-renewing subscriptions, your app is responsible for this process.

   若是你的應用程序出售非自動更新訂閱，你的應用程序負責該過程。

• When a subscription becomes inactive, stop making new content available. Update your interface so the user has the option to purchase the subscription again, re-activating it.

   當一個訂閱到期後，中止用戶使用新內容。更新你的界面，這樣用戶就能夠選擇再次購買該訂閱並從新激活它的內容。

• Implement some system to keep track of when content was published. Use this system when restoring purchases to give the user access to the content that was paid for, based on the periods of time the subscription was active.

   實現一個系統來跟蹤最新發布的內容。 當恢復購買時，使用該系統，讓用戶能夠根據訂閱激活的時間來訪問他們已經支付的內容。