Yesterday Apple introduced iBooks Author at an education event in New York City. Almost immediately people were up in arms: How dare Apple introduce an application for free that does not meet all of their own personal needs? And the audacity of insisting on a EULA that favors Apple’s own devices and markets. Not to mention the fact that iBooks Author only runs on Macs. Of course I would also prefer a tool that solves more of my issues related to publishing, along with unicorns and free beer. But, since I’m not footing the bill for the development of iBooks Author, my opinions on this don’t carry much weight. So let’s move on and look at what iBooks Author really is.
iBooks Author is intended to solve a very narrowly defined problem: How to easily create and publish great looking interactive eBooks for the iBookstore to be read on iPads. From what I’ve seen, it solves this problem very well.
iBooks Author is not intended to be a general purpose ePub authoring tool. This is of course disappointing. Most people don’t know that Apple already has one of the very few commercial, easy to use tools for creating ePub files in the iWork Pages application for the Mac. It’s not all that great, but Pages solves the problem of writing a book containing mostly text, adding some images and saving it as an ePub. A disappointing consequence of the introduction of iBooks Author is probably that Pages will not see many future improvements to it’s ePub capabilities.
.ibooks vs. ePub
The output from iBooks Author is like ePub but not quite. If you open up the .ibooks file (it’s a zip archive just like ePub files are) you will see the same structure as an ePub. Each page has it’s own xhtml file, and there are a couple of XML files that describe the structure of the book.
Creating an ePub reader for iOS is not terribly difficult since the individual pages or chapters are pretty standard HTML files which can be displayed in a UIWebView. I believe that iBooks v1.x in essence was built around a UIWebView. But that has changed significantly with iBooks 2.
Examining xhtml files generated by iBooks Author in more detail and you’ll find a lot of non-standard CSS: -ibooks-layout-hint:, -ibooks-list-text-indent:, -ibooks-strikethru-type:, etc. I know there are several WebKit specific CSS extensions with the prefix -webkit, but I don’t know what WebKit, and much less a UIWebView would do with these new -ibooks extensions.
But it gets worse.
When you use one of the built-in widgets you will get code like this:
<object type=”application/x-ibooks+anchored” data-anchor-ref=”danchor-gallery-0″> This code must trigger something in the iBooks 2 binary that renders the widget. It would have been nicer if iBooks Author generated standard JavaScript+CSS here instead. The native approach was probably done for performance reasons, as anyone who has tried to develop complex, interactive animations with JavaScript and CSS can attest to.
A consequence of these design decisions is that it’s no longer possible to load the xhtml files into a UIWebView and see a fully rendered page. This begs the question of how did they implement these new features in iBooks 2? I don’t see any way to just use the public APIs of a UIWebView to accomplish this. But given the debacle when iBooks was caught using a private API for adjusting the screen brightness, it seems unwise to go down that path again. Maybe they started from scratch using the WebKit open source code? They would certainly have the talent at Apple to pull that off.
So why did Apple choose proprietary extensions to ePub instead of fully conforming to the standard? We can only speculate.
- They want to lock in publishers to the iBookstore to boost the lagging number of titles.
- They want to ensure only iPads sales benefit from this free tool.
- They want full control over the format themselves.
- Time and budget constraints forced them to take the easier path.
- The current ePub standard does not provide all the functions and features they wanted to include.
I think there is some truth in all of the above, but I would put my money on the last one. See also John Gruber’s insightful analysis.
Given that the output format is closed, it would be possible for Apple to switch to a fully ePub compliant format as soon as the standards catch up. I don’t think this is very likely. But keep in mind that this is just the first version of iBooks Author.
Lack of iPhone compatibility
Curiously iBooks Author only generates ebooks for the iPad. I don’t think there are any technical reasons for excluding the iPhone and iPod touch. It’s more likely to be a content production issue. Creating the page layouts for these enhanced ebooks for the iPad is expensive enough. Forcing publishers to do the work twice to also target the iPhone, would probably be too much to ask.
For the educational market, the iPad is probably the right target. But if you are contemplating using iBooks Author to create ebooks for a wider audience, then the lack of support for iPhone and iPod touch is definitely a factor to consider.
Newsstand
One seemingly obvious application for iBooks Author is to create magazines to be distributed via Newsstand. Jason Snell of MacWorld wishes for this. The current EULA forbids content created with iBooks Author to be distributed via Newsstand (unless you give it away for free), but that is something it shouldn’t be too difficult to get an exception from Apple for, or conceivably see Apple change the EULA to include Newsstand in addition to iBookstore.
But given the architecture of iBooks 2 and the files generated by iBooks Author, it will be a challenge for third party developers to create magazine reader apps to display content generated by iBooks Author.
So should Apple create a generic magazine reader app, e.g. iNewsstand, that has similar features as iBooks, but also handles subscriptions and delivering content using the Newsstand infrastructure? That would be a bit odd to introduce now, as it would become a newsstand within the Newsstand folder. (Apple has actively discouraged third party magazine aggregators from making their apps Newsstand enabled.)
How about a sample project that magazine publishers can download and expand for their own use? This also seems unlikely as that would diminish some of the benefits Apple is achieving (deliberately or as a side effect) from the new proprietary file format.
IBooksPageViewController
An elegant solution to the problem of giving third party developers the ability to display content generated by iBooks Author would be to provide a new view controller that can read and display .ibooks files. It would be like a UIWebView on steroids. We can debate wether it should be a view or a view controller. Given the fixed page layout nature of ebooks created in iBooks Author, I think a view controller would be more appropriate.
Imagine the cool apps that can be created by developers if the creativity unleashed by the free iBooks Author tool could be harnessed in iOS apps. If Apple’s true intention is to keep the file formats proprietary and the technologies exclusive to the iOS platform, that is still achieved and further promoted with this solution.
I like this idea. I think I’ll go right now and submit a Radar for it.