As Paul posted earlier today, Barnes & Noble’s Fictionwise’s eReader’s iPhone eReader app version 2.1 is now available for download on the App Store. As I noted in the comments to that post, this version of eReader fixes the loudest complaint about version 2.0.2 when it came out—the removal of options to access the ManyBooks free e-books site, and to access books hosted on one’s own web server.
At the time, Steve Pendergrast told me that the removal was “due to a complex issue regarding the Apple Terms of Service that’s hard to even describe,” and an eReader rep said it was “due to some integration issues regarding how the App store works.” Now that these features are back, by looking at the changes we can get some inkling of what the TOS issue might have been—and see just how completely backward those Terms of Service requirements actually are.
The change is one of the most egregious examples of putting the cart before the horse I have yet seen from an e-book application—but it is not upon Fictionwise that the blame should be placed, but upon Apple’s asinine Terms of Service which have caused so many problems for other apps (such as Tweetie and Nine Inch Nails’s Access) already.
Under the old system, eReader’s access to Manybooks, and to e-books hosted at other URLs, was through an internal web browser panel much like some Twitter clients use—it opened a Webkit window and let you navigate through the pages, then click on an ordinary download link in order to download the books directly into the app, without ever leaving the eReader app itself.
Under the new system, any access to Manybooks, or to other external websites that happen to have eReader books available for download, is done by launching Mobile Safari and using the full-fledged Safari window to navigate to the files you want. But in order to be able to download them into eReader, it is necessary that the website support eReader for iPhone by using a special, Mobile Safari-friendly link format.
Instead of http://example.com/book.pdb, the site must use the format ereader://example.com/book.pdb. (Which also means that if the site wants to offer the eReader file for download to non-iPhones as well, it must actually link to the same file twice, and differentiate between the two so that users can figure out which one to click.)
At a guess, the Terms of Service issue must have involved Apple not liking Webkit (the web-browsing engine behind Mobile Safari, and the only one Apple will permit to run on the iPhone) to act inconsistently across applications—downloading files into eReader, but not knowing what to do with those same files if encountered in plain-vanilla Mobile Safari.
Or perhaps it has something to do with the rules about purchasing add-on content that were announced with OS 3.0—apps not being permitted to sell additional content from within themselves unless the App Store takes a cut? (If so, I wonder what this might mean for Lexcycle, which has not one but several e-bookstores integrated into its Stanza application.)
To be fair, the new system does mean that if someone encounters an eReader book download in the course of his normal Mobile Safari browsing, he can now download it without having to quit and launch eReader (even if it adds a little inconvenience to someone already in eReader who wants to download such a book).
But still, this means that Apple has enforced link consistency in its browser by requiring that every single website offering eReader books for download update all its links to add a brand new non-standard URL format, for the sake of one mobile platform.
Does this seem bass-ackward to anyone but me?
eReader seems to be doing much the same thing—but insisting that websites change their links instead of providing a handy bookmarklet to let users do it.