This post is a follow-up to my prior post about selling content on the App Store with new information from today’s press release from Apple and the updated App Store Review Guidelines.
First of all, kudos to Apple for updating the guidelines. The paragraphs you should look at for this discussion are 11.12 – 11.14. Based on my reading (and keep in mind that I’m an iOS developer, not a lawyer) these are your options:
1. Use IAP only for selling content
This is the most straightforward approach for most smaller developers. Just let Apple handle all the headaches of credit cards, payments, recurring billing, etc. For this convenience you pay 30% to Apple.
2. Use a combination of IAP and your own ecommerce
Most existing publishers who also want to sell content on iOS devices fall into this category. If you want to make content available on the iOS device that a customer has purchased on your ecommerce website, then you have some serious integration work to do, but that’s nothing new.
What’s new is that now you also have to offer the option of purchasing the same content using IAP. And the big, but not surprising, stipulation is that there has to be price parity between the two options. Your customer will pay the same amount in both cases, but you will have to pay 30% to Apple if the customer elects to purchase via IAP, compared to the 5-10% you typically pay to your ecommerce or credit card merchant. (11.13)
Furthermore, you cannot have a “buy” button in your app to direct a customer to your website. In order to purchase from your ecommerce website your customer will have to manually launch Safari, and type in the URL of your website, and complete the purchase there, before returning back to your app. Inconvenient, yes. But still a viable scenario for people who prefer to purchase things online from their desktop. (11.14)
3. Only rely on your ecommerce website
If you have a really well-known brand (Amazon comes to mind) you could remove all buy buttons, website links and purchase capabilities from your app. To buy content, your customers will have to know that they need to go to your website.
The advantage is that you don’t have to fork over 30% to Apple. The disadvantage is that you don’t get the convenience of IAP and you don’t get to ride on the coattails of Apple’s mighty iTunes machine.
Subscriptions
Subscriptions have their own paragraph (11.12) in the guidelines, which basically says: “Apps offering subscriptions must do so using IAP”. That clearly eliminates option 3 above. But is option 2 allowed? Steve Jobs quote in the press release seems to indicate that this option will be allowed: “Our philosophy is simple—when Apple brings a new subscriber to the app, Apple earns a 30 percent share; when the publisher brings an existing or new subscriber to the app, the publisher keeps 100 percent and Apple earns nothing.” A big-name example that seems like a good test case is The Economist which provides print subscribers free access to all content in their iPad app.
If this is not complicated enough yet, what about publishers who sell both subscriptions and single issues? And combinations of print and electronic subscriptions?
What will publishers do?
I believe that most companies will complain and grumble about this for a while. But in the end they will come to the conclusion that 150 million iOS customers is just too big of a market to walk away from.
Some companies do not have the margins to pay Apple 30% for the content they sell. Just like some companies don’t have the margins for sales reps or TV advertising. They will have to look to other channels for selling their content.
What will consumers do?
First of all, Apple will continue to allow you access to content you have purchased elsewhere. So your Kindle books are safe.
People’s habits are difficult to change, and I don’t think these new rules will have a significant impact on how consumers will purchase their content. If you’re used to buying ebooks on Amazon, then you will probably continue to do so (even with a few extra clicks). If pushing the IAP button in apps is second nature to you, then that’s probably not going to change either.
February 18th, 2011 at 09:00
Thanks Nick for this follow-up.
The beatport app is a nice example of how to come close to an IAP system:
http://itunes.apple.com/hn/app/beatport/id366319645?mt=8
They do not use any IAP or custom “buy” button, that links to their webpage. Still, if you lock into your account using the app, you can add songs to your shopping card. These can be bought on their webpage later on with just one click.
Is it forbidden to link to your webpage at all in your app? I’m not talking about any “buy”-button, but rather some “visit beatport” – button to complete your transaction.
February 28th, 2011 at 18:45
@W.Gerick: It is my understanding that all links to your website are forbidden. Not just “buy” buttons. For any decently designed website it should be easy to find out how to buy something once you’ve found the website. So just forbidding “buy” buttons would not make that much sense.
September 27th, 2011 at 09:44
I’m struggling to understand Apple’s policy. My company has an app for both iOS and Android.
1. are we allowed to offer the same IAP content on both platforms, providing the price is the same? Surely, yes?
2. much more interests me; are we allowed to implement a user registration system which would allow a user (if he so wanted) to buy content with an Android device or directly from our website then sync it to an iOS device.
3. if yes, sync via registration is OK; are we allowed to oblige the user to register, before allowing him/her to make in app purchases? I suspect not.
September 28th, 2011 at 18:41
@Roger: Here’s what I think, which may or may not correspond with what Apple thinks.
Yes.
Yes. Zinio is an example of an app where you can purchase magazines on their web site and sync them to the iPad. They also have an Android app, and I assume that purchased content syncs across all devices.
A recent requirement from Apple is that you must allow anonymous purchases from the device. You can encourage (but not require) the customer to register by giving additional benefits to registered customers, such as purchasing from the website and syncing to other devices.