天天看點

In-App Purchase Programming Guide----(八) ---- Preparing for App ReviewPreparing 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

一、遞交産品以供稽核

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

二、在測試環境中的收據

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

In-App Purchase Programming Guide----(八) ---- Preparing for App ReviewPreparing for App Review

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

三、實作核對清單

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 the

    finishTransaction:

     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.

     實作一個系統來跟蹤最新釋出的内容。 當恢複購買時,使用該系統,讓使用者可以根據訂閱激活的時間來通路他們已經支付的内容。

轉載于:https://www.cnblogs.com/patientAndPersist/p/3713419.html

ui