Apple’s rules and mechanisms for selling content in apps have been “evolving” since the App Store opened.
In app commerce variations
One of our very early projects for a client was a wallpaper app where you could download a number of wallpaper images paid for by the app purchase price. After that you could buy additional credits for more downloads. Initially Apple told us to use our own payment mechanism for this, as this was before In App Purchases were available. We implemented a solution using Bango, which Apple then promptly told us to remove or risk rejection. We now use IAP and all is well.
An ebook reader app that I worked on used the one app per book model, which does not scale very well. When IAP became available, this app was used as a showcase in the keynote at WWDC. The purchasing model is still ok, but it appears that the content may not be. More about that below.
For a magazine reader app, an existing ecommerce back-end was used for purchasing single issues as well as subscriptions. The best usability scenario would have been to seamlessly integrate the ecommerce website in a web view. But on the evening before the launch, Apple suddenly had a change of heart and requested (i.e. demanded) that we quit the app and launch Safari for all ecommerce processing.
Amazon does the same thing with their Kindle app, as does Barnes & Noble with their nook app. Interestingly Amazon’s Windowshop app does allow you to buy Kindle editions from within a web view, but not from the native UI. For mega retailers like Amazon, these restrictions and gray areas just become absurd.
What change?
Although not ideal, the launch Safari approach works, and is being used by many apps currently on the App Store for selling content. The fact that so many apps that use this mechanism have been approved, has led us to believe that this had Apple’s blessing. Until now.
The paragraph in question is 11.2 in the
App Store Review Guidelines. The wording here is very vague and depending on how you interpret that single sentence, you can argue that all of the above scenarios should be fine, or all should be rejected. If we accept the premise that Apple’s review and approval process is not random (and I know that to some, this may be a leap of faith), then the interpretation and enforcement of this paragraph must have changed over time.
SKU limit
If Apple required Amazon or B&N to use IAP for their ebooks, they would very quickly run into the max SKU limit of the IAP system. I have heard that the max number of In-App Purchase product items you can have is either 3,000 or 5,000. Although I suspect anyone trying to enter that many items using iTunes Connect would go mad long before approaching that number.
Several of our clients find that IAP is a non-starter because of this limit. Yes I know that you can use consumable IAP items to represent multiple real life SKUs, but that leads to other issues.
Subscriptions
Subscriptions have been part of IAP since the beginning, albeit the functionality was so crippled that I have not seen any project use it. In a nutshell each developer had to manage all aspects of subscriptions beyond processing the payment. And the big deal breaker was that subscriptions did not renew unless the customer opened the app regularly.
Today News Corp launched the much rumored The Daily news app. The news here for developers is that The Daily implements a new subscription system. Not much is known about the system, but the updated iTunes terms of service provides some clues:
(Oddly the printable version of the terms of service does not include this new paragraph.)
It seems clear that these “Paid Subscriptions” do automatically renew until you explicitly cancel. And Apple will provide a mechanism for opting in to sharing your personal information with the publisher, which has been another point of contention between the newspaper/magazine industry and Apple.
Apple’s Eddy Cue says that the new subscription system is “Available on the Daily today, and there’ll be an announcement for other publishers soon.”
Books should be sold in the iBookstore
Having developed many book related apps I was surprised to hear about this rejection of an ebook app. Apparently if your ebook app does not offer any features beyond what an ePub file in iBooks can do, then it will be rejected and you will be asked to submit your book to the iBookstore instead.
I can understand Apple’s position on this from both a usability perspective (the book category is already the largest in the App Store) and from a profit perspective. But I sure don’t want to be on the app review team trying to decide where the line of “enough interactivity” goes.
What now?
My main gripe as a developer is of course the lack of proactive communication from Apple on policy changes like this. When they finally published the App Store Review Guidelines it was clearly stated that it was a “living document”. Well, it’s been pretty dead and void of changes since the initial publication. And I think that most developers would agree that there have been some significant changes since then.
If you currently have an app on the App Store that does not comply with all the latest interpretation and enforcement changes, then it’s unlikely that your app will be pulled from the store immediately. But if you ever want to make an update to that app, you will have to comply with the latest policy/rule/interpretation/enforcement. Even if this means that you have to make fundamental changes to your business.
written by Nick
\\ tags: In App Purchase