Apple & eReader insist every eReader book download site use their new non-standard URL format

eReader_logo 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.

eReaderlink Instead of, the site must use the format ereader:// (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?

Funny thing is, eReader is not the first e-book app to use the nonstandard HTML prefix approach; BookShelf uses it, too. But instead of requiring all PDB-offering websites to rewrite their URL format themselves, Bookshelf’s coder came out with a Javascript bookmarklet that would locally convert links within the user’s own Safari browser, so that tapping on them would download the books directly into BookShelf.

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. Perhaps they should borrow BookShelf’s.

5 Comments on Apple & eReader insist every eReader book download site use their new non-standard URL format

  1. Chris, custom URN’s are fairly common. Take a look at which is a standards based look at the whole issue. Just off the cuff, I think this ereader: urn is a method to get around the fact that the iPhone’s mobile Safari doesn’t download to a file system like desktop versions do. By putting a custom URN on the URL, the browser can route the download to the proper handler application. Its the same thing that happens with iTune Store URL’s to apps, with the itunes: urn.

    Of course, everyone should double-check my old memories, because I’m not really on top of these issues anymore.

  2. All right, fair enough. I thought that all URLs (or URIs?) were supposed to be approved by some standards body, the same way that domain name suffixes do. But I guess it’s more open than that.

    Anyway, that still doesn’t change the central point that asking everyone else to change the way they do things for the sake of convenience to them seems a little backward to me.

  3. I agree that now (2.1) the process to upload a .pdb file to eBook Reader is a pain. Either you need to send the files to your personal space in or you need to know the *exact* URL of the file, which — of course — most of the times is not easily obtained in Safari Mobile.

    Having a bookmarklet could indeed work around this. Something Fictionwise should consider.

    I’m still wishing I hadn’t upgraded from 2.0.1.

  4. I imagine that you could probably edit the Bookshelf bookmarklet to work by changing the extensions and the prefixes that it changes.

  5. I wouldn’t consider it worth the trouble… especially as I offer my books in 5 other formats already… that’s enough links. And I don’t support the idea of setting up specialized links for specific devices… that’s the opposite of standardization, and this industry needs standardization more than anything else.

The TeleRead community values your civil and thoughtful comments. We use a cache, so expect a delay. Problems? E-mail

wordpress analytics