In-App purchases

An In-App purchase within a game provides users with the ability to purchase upgrades, access levels, weapons, or other content by transacting with the App Store. The App Store will then communicate with the game to notify it that a purchase has been authorized and that the content should be unlocked within the game. All of this takes place within the iOS SDK and the App Store commerce systems, so you will not have to deal with credit card transactions or the security of commercial transactions across the wire. Apple will handle the entire process and you will receive money in your account the same way you would with regular application purchases.

Internally, In-App purchases are accomplished using the iOS SDK Store Kit API. This API is responsible for communicating with the App Store and collecting payments from the user:

In-App purchases

To date, Unity does not provide a channel within the iOS version of the Unity product for an application to add In-App purchases to games so, as with iAds, we will have to rely on a third-party plugin to implement this functionality. As before we will use a plugin from Prime31 – the StoreKit plugin.

Subscription types

There are four different types of In-App purchases: non-consumable, consumable, subscriptions, and auto-renewing subscriptions:

  • Non-consumable In-App purchases represent a class of items that you purchase once and have access to continuously. These purchases can be transferred between devices on the same iTunes account. Examples of non-consumable items include game levels, weapons, vehicles, and other permanently available items.
  • Consumable In-App purchases represent a class of items that, as the name suggests, are purchased and then consumed by the player – requiring an additional purchase each time the player wishes to use the item. Examples of consumable items include experience points, health kits, turbo boosts, ammo packs, and so on.
  • Subscriptions are similar to magazine and newspaper subscriptions that last for a limited duration and then require the user to renew after that duration has expired. While not typical in gaming circles, an example of a subscription might be a defensive coach in a football game, which allows the player to not have to call defensive plays. The coach would be available for the duration of the subscription and after it expires the game would require the player to call defensive plays again.
  • Auto-renewable subscriptions are those that allow the user to purchase In-App content for a set duration of time. At the end of the duration, the subscription will automatically renew, with iTunes charging the user, unless the user opts out. Examples of the auto-renewable subscriptions are the same as normal subscriptions except that the player continues to have the defensive coach until they cancel the subscription.

Delivery models

In-App purchases can use one of two delivery models with iTunes, the built-in model and the server model.

In the built-in product model, everything required for your application to deliver In-App purchases to your customer is built in to your game. This means that all of the consumable and non-consumable In-App purchases are already built into the game. Accordingly, this means that all purchase access would be defined through application identifiers. As an individual application would be responsible for maintaining these preferences they can become lost when a user moves between devices, so you must ensure that any preferences, that would preserve that state are stored in application preferences, as they are backed up by iTunes. Another solution is to use iCloud, or similar, to host these application preferences off of the device:

Delivery models

In the server product model a separate server maintains the In-App purchase content as well as the transactions with the App Store. The App Store, application and the server then orchestrate confirming purchases and delivering content to the iOS device. In this model a game would deliver new levels or other content directly to the application. While this model is compelling, at the moment it does not work well with Unity iOS applications, as Apple requires that all of your content be distributed in the application on the App Store. It is included here for completeness:

Delivery models

Note

As the In-App purchase process does not provide the capability to patch an application, and since Unity will not directly load content that is not in the application bundle, it is expected that all of the content that you plan to deliver through In-App purchases will be delivered in a version of your application in the App Store.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.135.194.251