If you’re one of those people who loads up your iOS device with lots of apps, you’ve possibly already experienced the problem Martin Taylor is having this morning:
When I try to download an ebook from the Kobo store using the Safari web browser on my iPad — this is the new procedure users must follow now that Kobo’s in-app store has been cut off from the iPhone and iPad — the ebooks won’t open in the Kobo reading app. Instead, what I was offered to open my Kobo ebook was a choice of Bluefire or OverDrive, two Adobe DRM-compliant reading apps installed on my iPad.
From what I understand (please let me know if I’m wrong), there are two ways third party developers can try to work with specific file types.
The first way is through a URL protocol handler. Apple lets developers associate custom URL strings to specific apps, so for example if Kobo decides to introduce download links that start with “kobo://” instead of “http://” then that can trigger the Kobo app to launch from within Mobile Safari. But because Kobo will be serving these links from its primary website, it will have to make sure to only offer the custom URL to iOS devices.
The other way is to build support for specific file types–EPUB or PDF, for example–into an app, and iOS will automatically include that app in a list of potential choices when a user tries to download or open a file.
The problem with this second approach is that if you have fifteen apps that open EPUB, instead of listing all of them, Apple might randomly display a subset of choices–leaving out the one app you actually wanted to use (like Kobo).
Here’s a more detailed explanation from the troubleshooting page of the popular PDF reader GoodReader.
The Open In functionality is controlled by iOS, we have no active control over it, we just declare GoodReader to be capable of accepting certain file types. iOS is known to show only a limited number of randomly selected apps for any given file type when you invoke the Open In action in any app. The actual maximum number of apps depends on a device type and on a version of iOS. The only way to resolve this issue is to delete some apps that you don’t need that expose themselves for a particular file type, to make way to other eligible apps.
The options for Kobo and any other ebookseller with an iOS app seem to be: either figure out a way on your primary website to serve custom download links to customers shopping from an iOS device, or ask the customer to delete other apps that also open the same file type.
The problem could be solved much more efficiently by Apple, if it would simply let users maintain a list of preferred apps for specific file types in Settings, but for now the company seems content to let the competition deal with this usability issue.
“Kobo’s new iPad set-up doesn’t seem to work” [Activity Press]
NOOK update finally worked, and buying a book in Safati was fine. It doesn’t download automatically, rather you have to sync the app to B&N Nook site from within the app itself to refresh and the book appears. No great shakes, just one extra step to buy a book.
A problem you won’t encounter with the Kindle app since Amazon is not using ePub. My, who would have thought Apple’s decision would strengthen proprietary formats … silly.
I ran into the same problem last night with a different app, and found out that the ‘Open In” list in iOS can only list 10 apps that can handle the file type, and those apps are chosen randomly from all the compatible apps. The solution is to delete apps that you no longer use that support the app type, in order to get Kobo into the list. As Chris suggests, the longer-term solution is to allow users to specify the apps that they want to use for various file types.
BooksOnBoard seem to have it worked out. When I go to my account there on my laptop, beside each purchased ebook it just says “Download” (and downloads the .acsm file for Adobe Digital Editions to open if it’s in the mood). When I go there on my iPad or iPhone the link says “Download to Bluefire Reader”. Clicking on this opens Bluefire Reader and the ebook downloads. I agree, however, that it would be helpful to have more choice in how we open files. Apple have said they don’t want iOS to be like a desktop system, but we do need more configuration in some areas (e.g. viewing full headers in email).