苹果Store Kit工具可助开发者实现应用程序与App Store的信息交流。应用程序可使用Store Kit接收将在App Store应用中出售的商品本地信息。应用程序会向用户展示这些信息，以便后者购买虚拟商品。当用户打算购买某项物品时，应用程序就会调用Store Kit搜集用户的支付信息，下图是基本的应用商店IAP（应用内置付费功能）运作模式。

remote_store_fetch(from developer.apple)

Store Kit API仅是开发者向应用程序添加商店功能的步骤之一。开发者在这个过程中需考虑好如何追踪自己打算发布的产品相关信息，应用程序如何向前端用户展现商店内容，应用程序如何向用户传送其购买的商品。下文主要介绍开发者如何创造产品和向应用程序添加商店的流程。

产品

这是应用程序内的商店向用户出售的一切功能，与创建新应用程序一样，它也通过iTunes Connect上传到App Store。开发者可通过IAP功能出售4种不同的产品：

*电子书、杂志、照片、艺术品、游戏关卡、游戏角色及其他可通过应用程序传递的数字内容。

*可解琐或扩展应用程序中已存在内容的功能性产品。例如，开发者可在一款游戏中发售多种支持用户购买的小型游戏。

*允许用户性付费获取的一次性服务，例如录音服务。用户每次使用该服务都需要再次付费。

*让用户获得扩展内容或服务的订阅内容。例如，某些应用程序以包月制方式提供金融信息或者在线游戏服务。

IAP提供了一个创建产品的通用机制，开发者可自行决定如何部署产品的规格。但开发者在设计含IAP功能的应用程序时仍需注意以下几点：

*在应用程序中只能出售数字商品或服务，不可使用IAP发售实体商品或服务。

*不可供应那些充当中间货币的商品，必须让用户清楚自己购买的具体商品或服务性质。

*所提供内容不可含有色情、过激言论、诽谤或赌博的信息（游戏邦注：模拟博彩内容除外）。

开发者可以查阅苹果开发授权条款了解有关IAP功能的详情。

在App Store注册产品信息

开发者欲通过应用程序出售的每件产品都必须通过iTunes Connect向苹果登记，需提供产品名称、产品描述、定价以及其他与App Store和应用程序相关的元数据。

需使用独特的产品标识符来区分每一项产品，因为Store Kit与App Store交流信息时，会使用产品标识符调取开发者提供的产品配套数据。然后，用户打算购买某项产品时，应用程序就可使用产品标识符识别出即将出售的产品。

App Store支持的IAP产品内容包括：

*用户会重复购买的可消耗产品。例如，一次性服务就属于可消耗产品的范畴。

*用户一次性购买的非可消耗产品。用户购买这种产品之后，与其iTunes帐号相关的所有设备都可获取这项产品。Store Kit支持多个设备获取这种非可消耗产品。

*可自动更新的订阅服务，与非可消耗产品一样，它也可以使用于用户同个帐号的多个设备。不过这种服务与前者略有不同，当开发者在iTunes Connect创建可自动更新订阅服务时，需要选择订阅持续时间。每次订阅到期时，App Store会自动为其续期。如果用户不希望续期，他们就无法在订阅服务到期时继续获取内容。在这种情况下，应用程序必须能够验证用户的订阅服务是否处于活跃状态，并接收最近更新的交易收据。

*免费订阅服务可通过Newssand向用户提供免费的订阅内容。假如用户注册了免费订阅服务，其同个帐号的所有iOS设备均可获取这种订阅内容。这种服务没有期限，并且仅限于支持Newsstand功能的应用程序。

*非可更新的订阅服务，这是一种有期限的创建内容机制，它与可自动更新订阅服务的主要区别如下：

·开发者在iTunes Connect中创建内容的时候不会生成订阅条款，需由开发者的应用程序负责向用户提供这些信息。多数情况下，开发者的产品描述中需包括订阅条款的内容。

·用户可多次购买非可更新订阅服务（这一点与可消耗产品相似），App Store不会自动更新这项服务。开发者需自行在应用程序中处理其更新流程，应用程序必须能够识别已过期的订阅服务，并提醒用户再次付费续期。

·开发者需向用户同个帐号的所有设备提供这项服务。非可更新订阅服务无法通过Store Kit自动同步到用户的所有设备上，开发者只能亲自完成这一操作。例如，多数订阅服务依靠外部服务器传送内容，开发者的服务就需要部署能够识别用户，并将付费用户与其所购买项目相匹配的机制。

开发者还可以通过iTunes Connect开发者指南了解App Store产品注册流程的详情。

产品传输途径

应用程序传递产品的机制要取决于其设计和执行方式。这里有两种模式可供选择：内置商品模式和服务器模式。这两种模式都可让开发者跟进商店所供应的产品列表，并向用户成功传递其购买的商品。

内置模式

在这种模式中，开发者需传递的所有商品都要嵌入应用程序中。这种模式多用于解决应用程序中的功能。开发者也可以使用这种模式传递应用程序包中的内容。该模式的一大优势在于它可以立即向用户供应其所需产品，其内置的商品多属于非可消耗产品。

注意：IAP功能并不支持应用程序在用户交易成功之后再修复补丁，假如产品需要应用程序包进行调整，那么开发者就只能选择向App Store上传更新版本的应用程序。

应用程序会储存应用程序包中的产品标识符以识别产品，苹果推荐使用属性列表跟踪这些内置商品的产品标识符。以内容为导向的应用程序可使用这种模式添加新内容，而无需修改应用程序的原始资料。

用户交易成功后，应用程序就必须解琐该功能，并向用户传递其购买的商品。最简单的解琐功能就是更改应用程序的参数选择。用户备份自己的iOS设备时，应用程序参数选择也会随之备份。应用程序可建议用户交易完成后进行备份，以免丢失交易信息。

built-in product delivery2(from developer.apple)

服务器模式

在这种模式中，开发者需准备一个可向iOS应用程序传递产品的服务器。这种模式适用于订阅、服务和内容这类商品，因为这些商品可在无需更改应用程序包情况下传输数据。例如，游戏向应用程序传递新的场景（谜题或者关卡）。Store Kit并没有定义服务器的设计，或者服务器与iOS应用程序之间的交互方式。开发者需自行设计服务器及其与iOS应用程序互动的方式。另外，Store Kit并不提供识别特定用户的机制，这就要求开发者自创识别iOS用户的机制。

store_transactions(from developer)

苹果建议开发者通过自己的服务器获取产品标识符，而非将其纳入属性列表。这样开发者就可以在无需更新应用程序的情况下灵活添加新产品。

在服务器模式中，应用程序会获取与交易相关的收据，然后将其发送至开发者服务器。服务器会验证这些收据信息，将其解码后再决定将哪项产品传送到应用程序。

采用服务器模式需考虑到安全性和可靠性问题，开发者需测试整个环境以确保数据传输过程不存在安全隐患。

虽然非可消耗产品可使用Store Kit的内置功能复原，但非可更新订阅服务却需要通过服务器才能还原。开发者需注意记录并向用户还原非可更新订阅服务的信息。可消耗产品可以选择通过服务器追踪交易信息，如果某项可消耗产品是一项由服务器供应的服务，那么开发者就需支持同个用户帐号的多个设备获取这些内容。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Overview of In-App Purchase

Store Kit communicates with the App Store on behalf of your application. Your application uses Store Kit to receive localized information from the App Store about products you want to offer in your application. Your application displays this information to users and allows them to purchase items. When a user wants to purchase an item, your app calls Store Kit to collect payment from the user. Figure 1-1 shows the basic store model.

Figure 1-1  In-App Store model

The Store Kit API is only a small part of the process of adding a store to your application. You need to decide how to track the products you plan to deliver, how your application presents a store front to the user, and how your application delivers the products users purchase from your store. The rest of this chapter explains the process of creating products and adding a store to your application.

Products

A product is any feature that you want to sell in your application’s store. Products are associated with the App Store through iTunes Connect in the same way that you create new applications. There are four supported kinds of products that you may sell using In-App Purchase:

Content includes digital books, magazines, photos, artwork, game levels, game characters, and other digital content that can be delivered within your application.

Functionality products unlock or expand features you’ve already delivered in your application. For example, you could ship a game with multiple smaller games that could be purchased by the user.

Services allow your application to charge users for one-time services, such as voice transcription. Each time the service is used is a separate purchase.

Subscriptions provide access to content or services on an extended basis. For example, your application might offer monthly access to financial information or to an online game portal.

In-App Purchase provides a general mechanism for creating products, leaving the specifics of how your products are implemented up to you. However, there are few important guidelines to keep in mind as you design your application:

You must deliver a digital good or service within your application. Do not use In-App Purchase to sell real-world goods and services.

You may not offer items that represent intermediary currency because it is important that users know the specific good or service they are buying.

Items you offer for purchase may not contain, or relate to, pornography, hate speech, defamation, or gambling (simulated gambling is acceptable).

For detailed information about what can be offered using In-App Purchase, consult your licensing agreement.

Registering Products with the App Store

Every product you wish to offer in your store must first be registered with the App Store through iTunes Connect. When you register a product, you provide a name, description, and pricing for your product, as well as other metadata used by the App Store and your application.

You identify a particular product using a unique string called a product identifier. When your application uses Store Kit to communicate with the App Store, it uses product identifiers to retrieve the configuration data you provided for the product. Later, when a customer wants to purchase a product, your application identifies the product to be purchased using its product identifier.

The App Store supports many types of products:

Consumable products must be purchased each time the user needs that item. For example, one-time services are commonly implemented as consumable products.

Non-consumable products are purchased only once by a particular user. Once a non-consumable product is purchased, it is provided to all devices associated with that user’s iTunes account. Store Kit provides built-in support to restore non-consumable products on multiple devices.

Auto-Renewable subscriptions are delivered to all of a user’s devices in the same way as non-consumable products. However, auto-renewable subscriptions differ in other ways. When you create an auto-renewable subscription in iTunes Connect, you choose the duration of the subscription. The App Store automatically renews the subscription each time its term expires. If the user chooses to not allow the subscription to be renewed, the user’s access to the subscription is revoked after the subscription expires. Your application is responsible for validating whether a subscription is currently active and can also receive an updated receipt for the most recent transaction.

Free Subscriptions are a way for you to put free subscription content in Newsstand. Once a user signs up for a free subscription, the content is available on all devices associated with the user’s Apple ID. Free subscriptions do not expire and can only be offered in Newsstand-enabled apps.

Non-Renewing Subscriptions are an older mechanism for creating products with a limited duration; consider using auto-renewable subscriptions instead. Non-Renewing Subscriptions differ from auto-renewable subscriptions in a few key ways:

The term of the subscription is not declared when you create the product in iTunes Connect; your application is responsible for providing this information to the user. In most cases, you would include the term of the subscription in the description of your product.

Non-Renewing Subscriptions may be purchased multiple times (like a consumable product) and are not automatically renewed by the App Store. You are responsible for implementing the renewal process inside your application. Specifically, your application must recognize when the subscription has expired and prompt the user to purchase the product again.

You are required to deliver non-renewing subscriptions to all devices owned by the user. Non-Renewing Subscriptions are not automatically synchronized to all devices by Store Kit; you must implement this infrastructure yourself. For example, most subscriptions are provided by an external server; your server would need to implement a mechanism to identify users and associate subscription purchases with the user who purchased them.

Detailed information about registering products with the App Store can be found in the iTunes Connect Developer Guide.

Feature Delivery

The delivery mechanism your application uses to provide products to users has significant implications on its design and implementation. There are two basic models you should expect to use to deliver products to users: the built-in model and the server model. In both models, you track the list of products offered in the store and deliver products successfully purchased by users.

Built-in Product Model

In the built-in product model, everything required to deliver products is built in to your application. This model is most often used to unlock functionality in your application. You could also use this model to deliver content provided in your application’s bundle. A key advantage of this model is that your application can promptly deliver products to the customer. Most built-in products should be non-consumable.

Important: In-App Purchase does not provide the capability for your application to be patched after a successful purchase. If your product requires changes to your application’s bundle, you must deliver an updated version of your application to the App Store.

To identify products, your application stores the product identifiers in your application’s bundle. Apple recommends using a property list (plist) to track product identifiers for your built-in features. Content-driven applications can use this to add new content without modifying the source for your application.

After a product is successfully purchased, your application must unlock the feature and deliver it to the user. The simplest way to unlock features is by changing your application preferences. See “Implementing Application Preferences”. Application preferences are backed up when users backs up their iOS-based devices. Your application may want to recommend to users that they back up their devices after making a purchase to ensure that purchases are not lost.

Figure 1-2 shows the series of actions your application takes to deliver a built-in product.

Figure 1-2  Built-in product delivery

Server Product Model

In the server product model, you provide a separate server that delivers products to your iOS application. Server delivery is appropriate for subscriptions, services and content, because these products can be delivered as data without altering your application bundle. For example, a game might deliver new play environments (puzzles or levels) to the application. Store Kit does not define the design of your server or its interactions with your iOS application. You are responsible for designing all interactions between your iOS application and your server. Further, Store Kit does not provide a mechanism to identify a particular user. Your design may require you to provide a mechanism to identify an iOS user. If your application requires these (for example, to track which subscriptions are associated with a particular user), you need to design and implement this yourself.

Figure 1-3 expands the built-in model to show interactions with a server.

Figure 1-3  Server product delivery

Apple recommends you retrieve product identifiers from your server, rather than including them in a property list. This gives you the flexibility to add new products without updating your application.

In the server model, your application retrieves the signed receipt associated with a transaction and sends it to your server. Your server can then validate the receipt and decode it to determine which content to deliver to your application. This process is covered in detail in “Verifying Store Receipts.”

The server model has additional security and reliability concerns. You should test the entire environment for security threats. Secure Coding Guide provides additional recommendations.

Although non-consumable products may be recovered using the built-in capabilities of Store Kit, non-renewing subscriptions must be restored by your server. You are responsible for recording information about non-renewing subscriptions and restoring them to users. Optionally, consumable products could also be tracked by your server. For example, if your consumable product is a service provided by your server, you may want the user to retrieve the results of that request on multiple devices.（source:developer.apple）