Sunday, February 13, 2011

Thoughts on Apple's rejection of Sony's Reader app

A couple of weeks ago, Sony announced that their Reader app for iOS had been rejected by Apple. Apple stated that they did so to enforce their existing and unchanged policy, which is that apps which initiate purchase of content that is useable within the app must include an option to purchase the content using the user's iTunes account, using the 'IAP' (In App Purchase) API, which currently deals Apple a 30% cut of the sale. Reporting suggests that Sony's app was doing the same thing any number of other reading apps were doing, and that it has implications for the other reader apps.

(I don't know if it is connected, but Sony has been making noises about pulling their media out of the iTunes Store.)

Never mind that I have pored over the App Store guidelines in vain looking for this policy, and that apparently in the past, vendors like Amazon and Barnes & Noble were told by Apple that launching a browser to complete a purchase was an acceptable workaround to avoid IAP.

Apple has said that existing apps that violate this policy (whatever it is) have until the end of March to replace their already-approved apps with new ones that don't violate the policy.

If, as many fear, this means death to all reading apps, that would indeed be a very bad thing for those of us who enjoy the freedom to shop for ebooks from virtually any vendor on iOS, making it nearly unique in doing so (other mobile platforms don't have quite the number of reading apps that iOS does). However, it is said that said vendors are 'in negotiations' with Apple about the matter, so we'll see what happens when it happens.

I would note that on my iPod Touch, have at last count at least 9 reading apps that will launch a purchase workflow (always by using the Apple-suggested workaround of launching a browser):

  • Kindle
  • Kobo
  • Nook
  • Google Books
  • Borders
  • txtr
  • Bluefire
  • iFlow Reader
  • Zinio

Presumably the Audible application (for audiobooks) would also qualify as violating the policy.

However, note that content so purchased is not tied to the app. Having purchased it, there is no requirement that it be immediately downloaded for use by the iOS app. In each case, content is accessible using other apps and platforms. A purchase I initiate with Kindle app can be sent to any of my Amazon-registered devices or apps.

Interestingly, the Marvel Comics app _does_ use in-app (IAP API) purchase (using the user's Apple account). But they are the publisher of the content, not merely a storefront. They can afford 30% for distribution and convenience of in-app purchase. Like content purchased for the above apps, Marvel's content can be read elsewhere (web browser), but it looks like they don't offer apps for other mobile platforms yet.

Note that Apple provides none of the purchasing backend for any of these sales, and there are dozens of storefront apps like,,, for purchasing physical stuff online, and their purchasing workflow is in-app. But Apple isn't going after them (yet).

Finally no competing commercial platform is insisting on a cut of sales made on their platform:

  • Blackberry
  • Android
  • Windows Mobile 7

(not to mention reading apps for Windows or OS X)

So on what basis can Apple justify enforcement and application of the policy here? What value are they adding that is not the same value added for sales of physical goods, or greater than that added by competing platforms? As far as negotiating something less than 30%, what percentage (other than 0%) can be considered 'fair'? Is this a rhetorical question?

Assuming worst case (apps need to be re-submitted using IAP as well as browser launch, or have the purchasing workflow removed entirely), I see the following shake-out:

  • Amazon is in the best shape. There's nowhere else to go if you want to read Kindle content on your iOS device: you have to purchase from Amazon. They can remove the 'Kindle Store' button, perhaps provide an in-app 'download sample' capability, and describe how to purchase by launching Safari, etc. They could also create a HTML5 web app for Kindle Store to further streamline web-based purchasing. The web app could store login credentials and an 'Add to home screen' link for it placed somewhere in the web purchase workflow when it sees the user using Mobile Safari. Apple cannot prevent this, since it bypasses App Store requirements completely. I imagine they could even have a dedicated Kindle Store iOS app that just purchases content used by the Kindle app, because a Store app would not actually consume or download the content but just make it available in the cloud.
  • Kobo, Borders, are okay too, they are multiplatform, but they don't have the format/DRM lockin that Amazon enjoys. You can purchase compatible content from any number of ePub storefronts, and read them with the Kobo app, and all of those storefronts are going to have more or less the same accessibility. And you don't even need the Kobo app to read Kobo ebooks - we still have also Bluefire, iFlow Reader, and txtr. So their presence might diminish somewhat.
  •  B&N is in a different category, but similar to Kindle. You pretty much need the B&N app to read purchases from B&N (well, Bluefire will too), it won't read content from other storefronts (a Nook will, but not the apps AFAICT), and so B&N customers will still want an app that does that, even if they can't use it to purchase content. So they can also remove storefront access from the app and provide a separate web app or whatever for the storefront itself.
  •  I'm concerned about txtr, Bluefire, and iFlow Reader, however. They are not multi-platform, and rely on the connected-storefront sales to make some money. Without it, they'll either have to charge for their apps, or incorporate some sort of advertising tie-in. It may spell the demise of their business plan, and we would be the poorer for it: they are some of the more innovative reading systems on iOS.

Needless to say, those of us who appreciate what a great reading platform iOS has been are a little anxious about what will be.

There. I've said it. What are your thoughts?

Monday, February 7, 2011

Observations concerning the Google ebook platform

I thought it would be useful to summarize some of the properties of the Google ebook platform, some of which are unique.
  • Not unlike Amazon, B&N, etc., all of the ebooks associated with your Google account (free or purchased) are stored in the cloud with your Google account.
  • The iOS & Android apps do not download PDF/ePub as such, but rather use some Google-proprietary storage format. The Google ereaders do not allow 'side-loading' or 'open with' functionality, and can only open content that comes from Google's cloud storage.
  • The iOS & Android apps, web ereader do not use Adobe Reader Mobile technology, unlike other Adobe DRM-based reading systems. Google does not license the Reader Mobile software. As such, neither the Google mobile apps or the web ereader need to be authorized with an Adobe ID. 
  • Adobe DRM is applied only for DRM restricted titles, when downloading for use in a non-Google ereader (which needs to be authorized with an Adobe ID). Google licenses the Adobe Content Server for this purpose.
  • The Google instructions indicate that you need Adobe Digital Editions to download an ePub or PDF file. That's not strictly true: you can use any application that is authorized with your Adobe ID to open the .acsm file you get from Google, and download the ePub/PDF. For example, Bluefire can do this on iOS. 
  • So the Google ebook platform operates independently of Adobe technology, though it works with platforms that use it.
  • Some purchased titles do not allow downloading and must be read with the Google web ereader or one of the Google mobile apps.
  • Google now requires a credit card on file, even if you only want to get free books.
  • Apparently the Google apps and web interface consume a variety of CSS-free ePub whose capabilities are not well understood. Yet another challenge for ebook designers who want their ePubs to look good everywhere...