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.

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?

I first came across this thing called Custom URL Scheme when I was going through the Facebook SDK, which uses it to reopen the app after the user has finished signing-in using mobile Safari during the Single-Sign-On (SSO) process. This is such a useful technique. To launch your app all you need to do is to define a Custom URL Scheme and use this scheme in the browser to trigger the launching of your app.

Defining the Custom URL Scheme (in xCode 4.2)
1. Go to you app info.plist. Add a new row and choose "URL types" as the key (if it doesn't already have this key - by default, it is not there unless you are editing someone else app which already have a URL Scheme defined).
2. Expand 'Item 0' and add in 'URL identifier' from the list.
3. Provide a value for this URL identifier. It can be anything. Although the convention is to use the reverse domain name style, e.g. com.absoluteripple.appname. (I am unclear as to the significance of this identifier as the URL scheme can be used to launch the app with or without this identifier as far as I can tell from my limited testing.)
4. Add another row, and choose 'URLSchemes' from the list. Now, the important bit. Provide the name that will become your custom URL scheme. If you put down 'myappname', then the url scheme will be 'myappname://'.
5. That is it.

Triggering the Launch of your App
Now that you have defined a custom URL scheme, you can use it to launch your app. This is just like any other url and you should (as far as I know) be able to use it like any other url. i.e. instead of 'http://', you use 'myappname://' (or whatever your scheme is). Whereas http:// opens a webpage, myappname:// opens your app. Try it out. e.g. if you type 'myappname://' in the mobile Safari it will open you app (after you have complied your app and put it on the iPhone/ iPad first of course).

Even More Useful:  It can be Used to Send Instructions to your App
Just launching the app is good but not that interesting. You can actually use it to pass variables to your app. How you use those variables is entirely up to you and your imagination. The point is that you can use this to get the app to do certain things. e.g. going to a specific location in your app and display certain information. And all this from an external url link.
The magic happens because of the following method (in the UIApplicationDelegate Protocol):
    - (BOOL)application:(UIApplication *)application openURL:(NSURL *)url
          sourceApplication:(NSString *)sourceApplication annotation:(id)annotation
This method gets called by iOS whenever the app is launched in response to your custom URL scheme.
A particular interesting variable is the 'url'. This is the url that you use to launch the app. As said above, this is just like any url, so it can have component paths. e.g. myappname://your/path/12345
So by structuring the component paths appropriate based on the needs of your app, you can send your app certain instructions and so get it to do things from an external url.
Notice also, you can tell which application is initiating the launch of your app with the values in 'sourceApplication' which is the bundle ID of the requesting app. You can also use the 'annotation' to to pass in information. This a property-list object. This opens the way for another app to communicate with your app.

Note: For iOS4.2 or before you need to use:
    - (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url
        (this is now depreciated)

Is the App you wish to launch installed?
From another app you can use [[UIApplication sharedApplication] canOpenURL: [NSURL URLWithString:@"YOUR_CUSTOM_URL_SCHEME"]] to determine whether the app you wish to launch is installed. This results a bool value.
So the code would look like:
    BOOL isAppInstalled = [[UIApplication sharedApplication]
                        canOpenURL: [NSURL URLWithString:@"YOUR_CUSTOM_URL_SCHEME"]];
    if(isAppInstalled) { // launch the app }
    else { // do nothing or send user to app store to download the app }

Is it possible to tell whether an app is installed from a browser? Don't know how or even if this is possible.

Useful Reference:

• code samples for common URL schemes

Recently, there are some noise in the media that iPhone and iPad apps are retransmitting user's address book information to external servers without the user's explicit permission.
We take user's data privacy very seriously. Any of our apps that access user's address book will only do so through the direct actions of the users. Address book information accessed by the app (such as in the Easy Party app), or personal information entered by the users in our apps, are only used within the app itself. Our apps have never and will never send the user's address book information to external sites or servers without seeking first clear and explicit permission from the users.

Scenario: You are using Automatic Reference Counting (ARC) in iOS 5 for your project, but you are also using some old class files or open-source libraries that are not ARC compliant. Your project won't compile.

Solution: Disable ARC on those files that are not ARC compliant by inserting a compiler flag. (Of course, the onus is then on you to ensure that those files adopt the appropriate memory management practice.)

To disable ARC on a per file basis:
1. Select the project in the Project Navigator
2. Select the relevant Targets (there should just be one if you have just created the project)
3. Click "Build Phases" tab along the top on the right hand side
4. Click the "Compile Sources" tab
5. Locate the implementation (.m) file you want to disable ARC and double click it
6. Type or paste in "-fno-objc-arc" on the dialog box that appears

Simply, set "Icon already includes gloss effect" under "Primary Icon" under "Icon files (iOS 5)" in info.plist to YES.

Note:
- "Icon already includes gloss effect" MUST be under "Primary Icon" for this to work. I I was lost for awhile and unable to remove the gloss effect until I realize this!
- You may also need to delete the app from the Simulator/devices and perform a clean build (Product > Clean) for the changes to show up.

Create a helper method:
- (void)openWithLink:(NSString *)urlLink
{
    [[UIApplication sharedApplication] openURL:[NSURL URLWithString:urlLink]];
}

Call the method:
[self openWithLink:@"THE_LINK"];

Replaces THE_LINK with the actual link, which can take a number of forms:

1. (Link directly to the app - method 1) http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=YOUR_APP_ID        e.g. http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=498871441
2. (Link directly to the app - method 2) http://itunes.apple.com/app/idYOUR_APP_ID
   e.g. http://itunes.apple.com/app/id488561581
3. (Link directly to the app - method 3) http://itunes.com/apps/YOUR_APP_NAME
    e.g. http://itunes.com/apps/memorable
4. (Link to your company) http://itunes.com/apps/YOUR_COMPANY_NAME
    e.g. http://itunes.com/apps/absoluterippleptyltd
5. (Link to the rating page of your app)
    NSString *str = @"itms-apps://ax.itunes.apple.com/WebObjects/MZStore.woa";
    str = [NSString stringWithFormat:@"%@/wa/viewContentsUserReviews?", str];
    str = [NSString stringWithFormat:@"%@+Software&id=", str];
    //- replace the following with your app id from iTunes Connect
    str = [NSString stringWithFormat:@"%@YOUR_APP_ID", str];

One point to note about all these url scheme is that they can (and do) change. You must test the link out inside your app to make sure it is working.

Optional:
You can replace 'http' with 'items-apps'. e.g. itms-apps://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=498871441
This will supposedly  open the App Store app directly, whereas the 'http' will first invoke Safari and then redirect to the App Store app. In practice, this doesn't seem to happen all the time.

See: Technical Q&A QA1633 Creating easy-to-read links to the App Store for your applications and company