In-app Purchase Programming Guide----(eight)----Preparing for App Review

Preparing for APP Review

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

When you're done testing, you're ready to submit your app for review. This section highlights some tips to help you through the review process.

Submitting products for Review

First, submit the product for review

The first time you submit a your app for review, you also need to submit a In-app products to being reviewed at the same time. After the first submission, you can submit updates to your apps and products for review independently of all other. For more information, see In-app Purchase Configuration Guide for ITunes Connect.

When you first submit a review process, you also need to submit a built-in product for review at the same time. After the first submission, the application and product updates can be submitted separately. For more information, see In-app Purchase Configuration Guide for ITunes Connect.

Receipts in the Test environment

Second, the receipt in the test environment

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

When the application is in development, auditing, and product processes, it runs in different environments. Such as:

Figure 7-1 Development, review, and production environments

During Development, you run a development-signed version of your apps, which connects to your development servers and the T EST environment for the App Store. In production, your users run a production-signed version of your apps which connects to your production servers and the PR Oduction App Store. However, during app review, your app runs in a mixed production/test environment:it ' s production signed and connects to Y Our production servers is the IT connects to the test environment for the APP Store.

During the development process, the version of the application is a development-signed version that connects to your development server and to the test environment in your application. During the product process, your users run a product signature version of the application, which connects to your product server as well as the product store. However, during the application review process, your application runs in a mixed product/test environment: It is a product signature and is connected to your product server, but it is connected to the store's test environment.

When validating receipts in your server, your server needs to being able to handle a production-signed app getting its RECEIP TS 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 inste Ad.

When you verify the receipt on the server, your server needs to be able to process a product signature application, which obtains its receipt from Apple's test environment. The recommended approach is to always first activate the receipt for your product server instead of the product store. If the "Sandbox receipt used in production" error occurs, verify the test environment.

Implementation checklist

III. Implementation Checklist

Before you submit to your app for review, verify that's 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 ):

Before submitting your review application, verify that you have implemented all the required behaviors. Make sure you have implemented the following kernel built-in purchase behavior (listed in a typical development sequence):

• Create and configure products in ITunes Connect.

  Create and configure the product in itunes Connect.

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

  You can change the product in the process, but before you test any code, you need at least one product that is already configured.

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

  Obtain a list of product identifiers from the app bundle or server (products identifiers). Send the list to the store with a skproductsrequest instance.

• Implement a user interface for your app's store, using the instances of returned by the SKProduct 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.

  Use the skproduct returned by the store to implement a user interface for the store. The development process uses a simple interface, such as a table view or some buttons. A final user interface can be implemented after running smoothly in the development process.

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

  Use Skpaymentqueue's Addpayment: method to add an Skpayment instance to the transaction queue, which is used to request payment.

• Implement a transaction queue observer, starting with THE  Paymentqueue: Updatedtransactions:  method.

  Use Paymentqueue:updatetransactions: method to implement a trading queue observer (transaction queue observer).

  Implement The other methods in the  skpaymenttransactionobserver  protocol at whatever Point makes sense in your development process.

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

  To be able to start later, make a permanent transaction, pass the product that has been purchased, download all the relevant content, and at the end call Skpaymentqueue's finishtransaction: method.

  During development, you can implement a trivial version of this code at First-for example, simply displaying "Product Deli Vered "on the Screen-and then implement the real version at whatever point makes sense in your development process.

  During the development process, you can implement just one simple version of the code-for example, simply display the word "Product delivered" on the screen---and then implement the actual version if you need it in the development process.

If your app sells non-consumable items, auto-renewable subscriptions, or non-renewing subscriptions, verify that ' ve im Plemented The following restoration logic:

If your application sells non-consumable products, auto-update subscriptions, or non-automatic update subscriptions, verify that you have implemented the following recovery logic:

• Provide UI to begin the restoration process.

  Provides a UI to open the recovery process.

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

  Retrieve information from past purchases by using the Skreceiptrefreshrequest class to refresh the app receipt or use the Restorecompletedtransactions method of the Skpaymentqueue class to recover the full transaction.

• Let the user re-download content.

  Allows users to re-download content.

  If You use apple-hosted content, restore completed transactions and use the transaction ' s property to downloads get a Instanc E of SKDownload .

  If you use Apple managed content, restore the full transaction and use the downloads attribute of the transaction to get an instance of the Skdownload class.

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

  If you host your own content yourself, access your server correctly.

If your app sells auto-renewable or non-renewing subscriptions, verify that ' ve implemented the following subscription Logic

If your app sells automatic Updates or non-Automatic Updates 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 I Ssue of a magazine.

  Handle a brand new purchase subscription by passing a fragment of the latest release---for example, a magazine's latest issue.

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

  Users are available when new content is published.

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

  When a subscription expires, allow the user to re-update 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 automatic update subscriptions, allow the App store to process the process. Don't try to handle it yourself.

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

  If your app sells non-automatic update subscriptions, your application is responsible for the process.

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

  When a subscription expires, the user is stopped from using the new content. Update your interface so that users can choose to purchase the subscription again and reactivate its content.

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

  Implement a system to track the latest published content. When the purchase is resumed, the system is used so that the user can access what they have paid based on the time the subscription is activated.

In-app Purchase Programming Guide----(eight)----Preparing for App Review