Skip to main content

Logic Applied: Apple's In App Purchase

Sony kicked off quite a storm yesterday by going public with their difficulties getting their iOS book reader app approved by Apple.  The collective gadget/tech internet has exploded, with a lot of writers going to the old saw of Apple being a greedy/restrictionist bully.  A little patience is probably in order.

Here next are probably the most pertinent items from Apple's App Store Review Guidelines, let's look at them logically.

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

A lot of people look at 11.2 and are coming to the incorrect conclusion that the Kindle and Nook iOS apps violate this an may be rejected on their next update.  This is totally inaccurate.  Both apps do not allow any purchase to happen IN THE APP.  Hell, neither of them even allow you to find a book to buy within the app, kicking you out instead to Safari to use their site for browsing and buying.  The Kobo app does allow in-app browsing of their catalog, but the purchase is handled completely outside of the app, via Safari.  Some might argue that their system violates 11.2, but I would not, because:

11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected

If we all agree that the second "goods" in this line includes digital goods, this situation makes a lot more sense.

Kindle, Nook and Kobo all use the iOS raw file system.  Books that get downloaded into the app are readily available to the user to remove and take somewhere else.  This puts each of these apps under 11.3.  Because the good that is purchased is a portable file (can be used outside of the app), they cannot use the In App Purchase API, even if they wanted to.

Sony's rejection makes even more sense if this comment by Zelannii (currently on page 1, but likely to be pushed to page 2 soon) on Engadget's article is accurate:

The kindle app (and nook app) was changed already to use the raw file system, and books are pulled in from a web page, and you have to buy them on the web page (not in-app). Its a file download. Sony tried to use in-app features to buy books, bypassing child protections apple has in place preventing kids from using your account without entering a password first, but also not replacing that with SSL based purchase security on a web site. Also, Sony is also downloading the content inside the app's own storage, not as raw files, making the impossible to sync back and forth to a PC or other devices, and also violating the in-app updating content from 3rd party sources rules. 

Sony simply needs to make simple changes: use the file system, allow book migration between devices, and stop using a directly connected 3rd party payment system. If they do as Amazon and BnK anlready do, it will get approved, and apple still gets $0 from each book sale. 

This has nothing to do with content blocking or apple demanding 30%, this has to do with use of features that are potential security risks that ALL apps have to be banned from using consistently. This is not some vague rule Sony accidentally tripped over, its a VERY clear condition, mentioned multiple times in the dev agreement in crystal clear print.

If Sony's app wasn't using the raw file system, then from Apple's point of view, the content in question (the book) is exclusive to the app.  This, plus the fact that they were allegedly circumventing the In App Purchase API to do an in-app purchase (i.e. not leaving the app), explains very clearly the rejection.  I don't see this as a case of Apple tightening up their rules or choosing to newly enforce something that they may have been lax on in the past.  Sony's app is in violation of the rules, as they are written today.

However, if Apple is tightening up their enforcement, then what will be interesting is if they force Comixology to change their apps.  Currently, all the Comixology apps (which includes Marvel, DC and Image's comic apps) use the In App Purchase API, but they also make the content available outside of the app, via the web (they do not use the raw file system).  As I read 11.3, that's a no-no.

Comments

Popular posts from this blog

Clay and Adam are a couple of dorks.

But I certainly had nothing to do with this monstosity. Or did I?

Some things are better left uncovered

Sometimes you hear a cover and go to yourself, "hey, that's doper than Sam Perkins at Woodstock." Other times, you wonder (possibly aloud) "that no talent hack! They couldn't even carry [inset original artist here]'s guitar case!" [Ed. note: You should have seen what the author originally wanted to use as the carried item. Believe us, it wasn't a guitar case.] Today was an example of the second. Some fool whose name I cannot even spare the mental RAM for, has covered "High and Dry" by the esteemed Radiohead. This is up there. With the worst covers of all time. Some songs just don't ever need to be covered. Like this one. And like "It's My Life" by Talk Talk. But No Doubt did a decent job with that one, although they crapped all over it with that video. This one today was bad. When you do a cover, you're supposed to bring something to it. Maybe your sound is similar to the original artist's, an