Boo! Gotchas in iPhone SDK restrictions might crimp e-book programs
E-book programs and other third-party software may not work out on the iPhone or may be severely crimped, thanks to some fine print from Control Central—Apple.
While third-party developers are abuzz over the $100M that Kleiner Perkins will dole out for iPhone-ware, the programming community is backtracking somewhat from its earlier ecstasy over the software development kit and the related technical infrastructure. As Wired notes, for example, programs like Firefox might be in trouble if they come with plug-in capabilities. And Gonnected worries about disk-access-related restrictions that might get in the way of e-bookware. Speaking generically, Techdirt wisely advises developers to check with Apple ahead of time. If anyone has a problem in the e-book area, tell me know about it, and I’ll make some noise for you!
Who knows? Will only Jobs-blessed formats run on the thing? This is yet one more reason to care about the .epub standard rather than entrusting your range of reading to individual companies. Apple’s a fine company and ideally will grow at least somewhat less proprietary, just as Sony has in the case of e-books.
(Thanks to Mike Cane. Image from Gerry Manacsa’s site.)
March 8th, 2008 at 4:13 pm
eBooks aren’t happening yet. Jobs seems to have his hands full just getting the promised 1,000 movies for AppleTV/iTunes. Seems signing up book publishers is a low(er) priority. I’d be very surprised if something on the “official” ebook front happened between now and June.
Does anyone know how long it took amazon to round up the publishers it did for the Kindle eBook Store?
March 8th, 2008 at 8:08 pm
Looking at Apple’s developer documentation, it’s clear that applications do have access to the local storage on the device. The proviso is that access to that storage is strictly limited to the application that owns it; applications cannot share a common area.
That means that an e-book reader application could store its library on the device. It could also provide web-based access to add to that library.
As far as formats go, this seems to offer no limitation. A given application can read whatever type of e-book file type it likes; it just can’t share its files with any other application on the device.
An interesting twist is that it appears you will not be able to add to your library outside the device, such as via iTunes. While you can back up an application’s storage onto your computer’s disk via iTunes, the backup version is encrypted and thus unalterable by the user. In other words, it’s fine if you need to restore the application on your device, but is otherwise inaccessible.
March 9th, 2008 at 10:35 am
>>>An interesting twist is that it appears you will not be able to add to your library outside the device, such as via iTunes. While you can back up an application’s storage onto your computer’s disk via iTunes, the backup version is encrypted and thus unalterable by the user. In other words, it’s fine if you need to restore the application on your device, but is otherwise inaccessible.
Huh? Please clarify that. How does the library get *in* the device to begin with? And if the library are unencrypted files, backing them up *encrypts* them?!
March 10th, 2008 at 11:24 am
Mike,
I think Jason means that if you had an ebooks application written in the official iPhone SDK, it will be able to read and write to its own storage space.
It means we probably won’t see ebooks coming into the iPhone through iTunes or disk access, but users will still probably be able to add books to their library through the application itself: Imagine a repository feature of some sort within the Ebooks application that fetches whatever files you want from gutenberg website.
So formats are irrelevant, providing the books application can read them.
The “twist” is that you won’t be able to extract these book files from your phone onto say your PC, because there is no direct access via disk or iTunes, and backing up your iphone it becomes encrypted.
March 10th, 2008 at 2:57 pm
Looking at the iPhone SDK, I was hoping for 3 access points for getting content on to the iPhone:
- Synching with a computer
- Downloading from the browser
- Direct downloading through the network from within the application.
However, as Phi Dinh already noted, it looks like there is just direct downloading to play with. However syncing could be done in the app, if your computer were running an FTP/HTTP service that allowed the iPhone the download/upload files, but getting the security model on that correct is going to be a bit touchy (most likely something like mutually authenticating SSL with some sort of enrollment process), and it’s nowhere near as elegant as tying into an existing synching model.
However the real worrisome bit could decide that it doesn’t like that way of doing synching, or if Apple decides to do eBooks on their own, they can choose not to make any competing 3rd party eBook readers available, sigh.
March 10th, 2008 at 2:59 pm
Too much editing, not enough proofing, sorry… the last paragraph should read:
However the real worrisome bit is that Apple could decide that it doesn’t like that way of doing synching, or if Apple decides to do eBooks on their own, they can choose not to make any competing 3rd party eBook readers available, sigh.
March 10th, 2008 at 5:18 pm
Wait, do I have this straight? You must use EDGE or WiFi to download an ebook *directly* to an iPhone or Touch? That spells s-u-c-k to me.
What it basically, realistically means is downloading to one’s *desktop* and then, I guess, maybe emailing yourself with the ebook as an attachment and then picking it up on the iPhone/Touch?
No bloody way would I just have *one* copy on an iPhone/Touch without a desktop backup that is also in some way accessible on the desktop too. That’s even worse than DRM!