Paper Ball and Chain

We’re so close to finally having iOS 8 SDK Development out the door! We just got the index back on Friday, and it looks great. I spent some time last night going over it, looking for either missing topics or things that didn’t really need to be in there, and it all looked great. If anything, I came away thinking “did we really write all that?”

Clipping from iOS 8 SDK Development index

And yet I’m kind of wondering: do books even need indexes anymore?

Yesterday, I bought The Anime Encyclopedia, Third Edition on iBooks, an update to a book I’ve been reading since its release in 2001. Their book is now 1,100 pages in print and over one million words (by comparison, ours is only 98,000 words), with some important consequences. A book that big and that niche no longer makes sense for offset printing, so they’ve switched to a toner-based small print-run system. Moreover, they’ve made a decisive switch to an ebook-first mindset:

So a governing emphasis for this third edition has been to design the content for a fully digital platform. If you obtain the e-book version of The Anime Encyclopedia, you will discover that cross-references within it physically transport you immediately to a main entry. If you click on a main entry title, you will, if your e-reader is online, be taken to a site on the Internet where you can find more information about the film, including links to image collections, biographies, related works, and so on. Instead of opening a narrow window on the anime landscape, The Anime Encyclopedia now appropriately takes you to the entire anime universe itself. Over time, we hope to continue to refresh and refine the hyperlinks in the digital edition. The presence of a printed, alphabetical index in the physical volume makes content updates there much more problematic, so we do encourage readers to continue to first check our website ( for fresh information, corrections, and updates.

So, for starters, this ebook doesn’t even have an index. Why bother, when you have a search tool? The fact that most of the book’s entries offer hyperlinks to official sites or Wikipedia entries is another strong idea. Realistically, the ebook is the better product here.

And that same logic is very true for programming books like ours. Janie and I crunched hard to get an 80%-complete beta book up the day that the iOS 8 SDK NDA dropped, something that would have been impossible with print. While working on the last few chapters, we’ve worked in feedback and errata from readers, while also handling changes to the Swift programming language in Xcode 6.1.

With Xcode 6.3, our sample code will break again, thanks to new Swift changes, so in our next update we are taking the position that we are now going to “lock” each update of the book to a specific version of Xcode, current as of the time of the book’s release. We already can’t offer code that runs on Xcode 6.0 (nor should we, since it’s obsolete), and we clearly cannot offer any promises about compatibility with future versions of Xcode, when Apple needs to make breaking changes to the language every few months as part of its natural evolution.

Swift Is A Moving Target aside box

With an ebook, this is doable. Buy it online, we’ll push you updates as needed, and you can go download the updated code examples too. With a paper book this is extremely problematic, and we are looking at a situation where there is no real release window that won’t be hit by at least some degree of instant obsolescence. The topic is simply moving too fast.

As I’ve finished each book I’ve worked on, I’ve felt it should be more of a digital product than it ended up being. This was most obvious in Learning Core Audio, where writing about sound is, as the old saying goes, like dancing about architecture. Had that book been imagined as a digital product from the beginning, perhaps before I even came in to help with it, it could have let you at least hear what you were doing, or perhaps even afford some level of interactivity with the topic.

Sometimes, this line of thinking eventually leads to obviating the book entirely. We know we’ve lost part of our audience to developers who would rather search through Stack Overflow posts to learn a new topic than take a guided tour. And it’s probably good that some topics (and some authors) have been winnowed out — you certainly don’t see the kind of programming book anymore where an author has done little more than rewrite the existing documentation or header file comments. But there does seem to still be an audience for the organization, experience, and clarity that a well-written book can deliver.

By analogy, consider The Anime Encyclopedia again: if every entry in that book links to its Wikipedia entry, what’s the advantage of the book? Why not just browse Wikipedia? The answer is that the thoughtfully-organized book provides opinion, insight, and context: traits that are explicitly forbidden on Wikipedia. Look up Master of Martial Hearts on Wikipedia, and you wouldn’t necessarily realize that a show about girls punching each others’ clothes off is really goddamned stupid (though I kind of hope you would). On the other hand, Helen and Jonathan will be happy to tell you that “it’s hard to imagine who would get anything out of this”.

There’s still an audience for good writing. I just don’t think that audience is well-served by paper anymore. I very much think that if you want to read iOS 8 SDK Development, then you will be best off by ordering it from the publisher directly. In the case of the Pragmatic Programmers, that means you can get an ebook in whatever formats you like (PDF, Kindle, or EPUB, with the option of a paper book too), have them automatically sync updates to your Dropbox, and get notified when updates are available. Plus, the forums and errata page give you direct access to us, the authors. Whether or not it’s the same price as buying from Amazon, you get a lot more for your money by buying direct, and I think most of the tech publishers are doing what they can to make themselves the most appealing option. My friend Daniel Steinberg has gone a step further with his Editor’s Cut imprint, going all-in on iBooks Author to make A Swift Kickstart an ebook experience that could only exist on Macs and iOS devices.

Speaking of resources available from the publisher’s site, consider how sample code has changed. When I first started writing tech books 10 years ago, the rule was that everything needed to complete the example code needed to be in the book itself, so you could work through it entirely with just the paper book. We still work that way in iOS 8 SDK Development because part of what we’re teaching is creating projects, building their UI, and managing their growth. But having to write the connective bits of an example project always presents a risk of going off-topic, and many books now set you up with a downloadable sample and have you just fill in the blanks that are relevant to the topic. To wit, you don’t want Bob McCune’s Learning AV Foundation book to have to burn 10 pages on GUI code to create a video timeline or an audio waveform UI, so he just has you download that part, and focuses his book on just the AV part. I can totally see going that way myself next time.

At any rate, with the index done all our beta readers can look forward to the first edition — fully edited, indexed, and errata-cleansed — real soon now. And when Xcode 6.3 comes out, we’ll push an update with a whole lot of the new as! syntax, as well as other changes where Swift 1.2 gives us opportunities to write cleaner or more expressive code. And if there’s another book after this, maybe we can make it make it even more of a digital product.

Previous Post

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.