Absolute Ripple
  • Absolute Ripple
  • Contact

Apple In-App Purchase: Creating App Store Hosted Content

2/1/2013

2 Comments

 
Following the introduction of iOS 6 it is possible to host the content of your in-app purchase on Apple's server, rather than having to host the contents on your own server under previous iOS versions. This makes it simpler (and perhaps less expensive) to implement in-app purchase for your app as you no longer need to develop and maintain your own server to host the purchased contents.
The steps in filling out the online forms in iTunes Connect when setting up each product that you want to sell via in-app purchase appears simple enough until you come to the point where you need to upload the content to the Apple server. How do you upload the content? What format should the content be in? There is a scarcity of documentation or guides around regarding this. Some guides simply said that your need to put all your contents in a 'package' and that is what you upload to Apple. This raises another question: what is this 'package' thing? How do you create it?
After putting together information from many sources, here are the steps to create the Apple App Store hosted content and also how to upload the same to Apple.
What is the Package?
The package is simply a structured folder, which contains a ContentInfo.plist in the root level and a sub-folder called 'Contents'. The ContentInfo.plist contains two keys:
  • ContentVersion - This is the version number of the content.
  • IAPProductionIdentifier - This is the product identifier of the product with which the content is associated. i.e. the identifier you defined in iTunes Connect.
The Contents folder contains the actual files associated with the in-app purchase. e.g. in an app that sell music score, it would be the actual music score file or files. Note that the content must not contain executable codes, otherwise the package would not be valid.
How to create the Package
Even though the package is structured folder, you cannot just create a folder on the Finder with the above contents. The best way to create the package that meets Apple's requiremetns it seems at the moment is to use Xcode. (The following steps are based on Xcode 4.6.)

Creating the Package
Step 1: Create a New Project in Xcode
File > New > Project
Select "Other" under iOS heading on the left hand panel of the template screen.
Select 'In-App Purchase Content" on the right hand side.
Then click "Next".
Picture
Step 2: Enter the info for this project
For Product Name, enter the product identifier as defined by you in iTunes Connect. The two must be the same. Fill in the Organization Name and Company identifier as you normally would. In this example, the identifier is "p02050".
Then click "Next".
Picture
Step 3: Update the ContentInfo.plist
Unfold the Supporting Files section of the project navigator panel and select the ContentInfo.plist file. Update the two keys in this file.
ContentVersion - the default version is 1.0, update this as required
IAPProductIdentifier - change this so that it matches the Product Identifier your defined in iTunes Connect.
Picture
Step 4: Add in the Actual Contents
Locate all the relevant content files on your computer in the Finder.
Drag and drop the files onto the Supporting Files section of the project navigator panel.
Complete the panel as shown below and then clicked "Finish".
Picture
Step 5: Archive the Project
Select Project > Archive from the menu.
Picture
Step 6: Validate the Package
Click the "Validate" button.
Fill in the panel that appear as you normally would when validating and submitting an app. Make sure the correct app content is selected in the In-App Purchase Content drop down menu.
Step 7: Export the Package
Click the "Distribute" button.
Select the "Export Package" radio button and click "Next".
Enter a name and Select a location on your computer to save the resulting package.
Then clicked "Save".
This step is option as you can upload the content at this point using Xcode. See below.
Picture
How to Upload the Package?
You have two options:
a. use Xcode; or
b. use Application Loader - This is a free tool provided by Apple. After you have logged in to iTunes Connect, clicked the "Managed Your Applications" link. The link to this Applciation Loader is located towards the bottom of the screen.
Using Xcode to Upload
This is same as what you normally do when submitting an app for review. That is, instead of choosing the "Export Package" option in the above panel, choose "Submit in-app purchase content". After clicking Next, put in your developer program credentials and select the correct application and product identifier, then click "Submit"



2 Comments

Apple's in-app purchase: Some considerations

27/2/2012

0 Comments

 
Under Apple's App Store Review Guidelines, there is sometimes no choice but to use Apple's in-app purchase mechanism. Assuming you are dealing with a situation where there is a choice, what are the considerations you should think about. Here are a few you may like to consider.
  • Price. You can only choose from the list of prices provided by iTunes. You cannot make up you own price. This tends not to be a serious issue as there are quite a few pricing 'tiers' you could choose from. However, this may mean that you need to align the pricing of your products with the pricing tiers offered by Apple - i.e. forcing you to set your pricing strategy to fit the Apple’s framework.
  • Commission. A commission will need to be paid to Apple and currently is 30% of the price. This is not insignificant.
  • Other transaction costs. One other costs that are not quite obvious (in the sense that it is difficult to quantify) is the potential effect of exchange rates if you sell the products outside your home country as most developers do. Admitted, I have not researched the detail mechanics adopted (if it is even published) but potentially there could be multiple exchange rates conversion by the time the money hit your bank account. It is quite likely that each of the conversion is performed with Apple’s best interest in mind; the corollary is that the conversion is not likely performed in your favors. This could all costs you money.
  • When do you get your money. Under the present practice, Apple only forward payment to the developer once the amount has reached a certain threshold. At the moment, it is around $US150. And keep in mind that this is the amount payable to you so it is not the same as the total sale amount, i.e. this is net of Apple's commission. This may not be an issue if your sales volume is large, but it is something to keep in mind. In any event, the point to note is that there can be delay between the sale of your product inside the app and you seeing your money in your bank account. In operating a business, the timing of cash flow is an important issue.
  • Customers' record. Apple's system will supposedly keep track of the items purchased by each users. However, it is unclear what happen in situation in which people changes phone or install the app on another device. Anyhow, we consider that it is best practice that the vendor also keep track of the items purchased by each person/device (of course, the extent of the tracking required would depend on the nature of the contents sold), meaning that you will need to implement your own database solution.

0 Comments

Apple's in-app purchase: when do we have to use it?

17/2/2012

0 Comments

 
We were (and still are) struggling with this issue in an iOS app project. This project, which is still in its infancy, would eventually involve the sale of various music related contents including possibly sheet music (i.e. musical scores), music files and other related elements. What we are trying to work out is whether we can sell contents in the form of sheet music and music files in an iOS app without using Apple's in-app purchase mechanism (the Apple Mechanism)?

We have nothing against the Apple Mechanism, which definitely has its advantages. However, for reasons that will be become more apparent below, using the Apple Mechanism does not seem to be practical in respect of the present project.

Apple's App Store Review Guideline (the Guidelines) currently  contains the following relevant guidelines: (based on version accessed on 10th February 2012)
11.2 Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected
11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy” button that goes to a web site to purchase a digital book, will be rejected
11.14 Apps can read or play approved content (specifically magazines, newspapers, books, audio, music, and video) that is subscribed to or purchased outside of the app, as long as there is no button or external link in the app to purchase the approved content. Apple will not receive any portion of the revenues for approved content that is subscribed to or purchased outside of the app.

The practical application of these guidelines are not entirely clear. The following practical explanation is found on stackoverflow.com:
  • Digital goods, upgrades or subscription: Your only choice is Apple's In App Purchase.
  • Charity donation: You must redirect the user to a website using Safari, you CAN'T use a UIWebView inside the app.
  • Physical goods: you CAN'T user Apple's In App Purchase, you need to use a website or any other method, for example the new PayPal Library.
  • Personal donations: (like the famous "express your gratitude and buy me a cup of coffee") you are again in item (1) and NOT on item (2).

This seems fairly accurate. This would suggest that the contents in question must be sold using Apple Mechanism. This consequently would mean we must use the Apple Mechanism in our project. However, after stumbling across an app by VirtualSheetMusic.com I am less sure. That app is quite similar to the features that we have in mind (although the type of the music is different). Importantly, they are are not using Apple Mechanism. If they could get their app approved without using Apple Mechanism, it gives us hope that we could too.

What I am trying to understand is why their app got approve? What distinguishes it from the guidelines noted above?

Admittedly, one possibility is that their app was approved before this current guideline. I have no idea as I don't know the history of the guidelines (but I am aware that it has changed and will change from time to time). Nor do I know the history of their app, but it seems that their app has been on the app store for awhile (inferred from the fact that it is currently version 2.7).

One possible distinguishing factor seems to be contents that could be used both within the app itself and also used outside the app.

These are the characteristics of the contents that we are considering in this project. The sheet music and music sound files in question can be consumed outside the app. More specifically, it is envisaged that the users could purchase these contents inside the app and outside the app (e.g. through a web site or by more traditional means like a physical shop or by fax, etc). Once they have purchased the contents, the users could access the sheet music and music sound files from within the iPhone/ iPad app, as well as from their computer, or possibly in the future even other devices. From an implementation perspective, it seems more efficient to adopt a purchase and payment mechanism that exists outside the app so that we can have a single mechanism rather than multiple mechanisms, which would raise technically complex issues of trying to synchronizing all the data.

That contents used both within the app itself and also used outside the app may be able to be purchased using a non-Apple Mechanism could well be consistent with the Guidelines. Guideline 11.2 says that we must use the Apple Mechanism to purchase content, functionality, or services in an app. Guideline 11.3 says that we cannot use Apple Mechanism to purchase physical goods or goods and services used outside of the application. But if the contents can be used both inside the app and also outside the app, what is Apple's position? This is unclear. Although, it seems that in this situation we may be able to use either Apple Mechanism or something else. This appear consistent with the VirtualSheetMusic.com example.

Further, this would seem consistent with the broad approach described in Guideline 11.13. Under Guideline 11.3, we are prohibited from linking "to external mechanisms for purchases or subscriptions to be used in the app" and we draw attention to the fact that this is talking about using the content inside the app here.

The overall impression seems to be that contents consumed within the app must be purchase using the Apple Mechanism. Whereas contents that have an external elements may be able to be purchase using a non-Apple Mechanism.

However, a concern is Guideline 11.4, which says that "[a]pps can read or play approved content (specifically magazines, newspapers, books, audio, music, and video) that is subscribed to or purchased outside of the app as long as there is no button or external link in the app to purchase the approved content." This clearly means that we could access the externally purchased sheet music and music files within the app, but does this means we cannot provide a means to purchase these items within the app? Does this only apply to magazines, newspapers, books, audio, music, and video? If so, may be sheet music can be purchased within the app?
0 Comments

    Archives

    August 2013
    July 2013
    June 2013
    May 2013
    January 2013
    October 2012
    September 2012
    March 2012
    February 2012

    Categories

    All
    Apple Policy
    In App Purchase
    Ios Programming
    Our Apps

    RSS Feed

    Disclaimers

    Here are some resources that I find useful in writing iOS apps. These are not necessarily unique as they are based on various sources online.
    This is mainly to provide a source of reference to myself and my associates but if it can be of use to someone else, that is good.
    Note that information is provided here as is. Use at your own risk. There is no guarantee that it is accurate. We will update the information as time and resources permit.

    Powered by Create your own unique website with customizable templates.