A Retina Display Reckoning for Magazine Publishers

Brad Frost recently noted the impending arrival of the iPad Retina display could “wreak havoc on the Web,” owing to mammoth image file sizes. Hopefully, with a little resourcefulness and education, the Web design and development community’s innate resilience will kick in and we’ll find some smart ways of dealing with this.But there is one group that’s about to smack headlong into a reckoning, and that’s the publishers who’ve been using several popular device-specific app platforms to churn out print-like periodicals for the iPad.

The iOS apps created by systems from Adobe, Woodwing, Mag+, and others—the platforms used by the bulk of traditional publishers to crank out their iPad magazines right now—are essentially collections of PDFs or JPGs exported out of programs like InDesign and bound inside a wrapper application. Basically, they boil down to pictures of layouts, photos, and text. Rather than create new rendering engines from scratch, these platforms rely on existing desktop applications to do that work, then package up the output. While faster to develop, this has negative consequences for the end user. You can’t resize text. File sizes are untenably large.

Now apply the volumetric increase in pixels that’s upon us, and it’s easy to see why the size of an average iPad magazine issue is about to go through the roof. Very roughly speaking, a single page of text built this way and saved using light JPG compression weighs in at around 150-350kB. At the new Retina dimensions these same app platforms will generate pages on the order of 2MB. That’s per page.

This isn’t just a question of the bandwidth these apps will devour while downloading issues, it’s also a question of whether or not a user can actually store these things anywhere. The screen volume may have quadrupled, but the new iPad still ships with the same three memory options: 16, 32, and 64GB. As I noted on Twitter, the growth rate of the potential payload size just outgrew the growth rate of device storage exponentially. Some publishers may be implicitly backing themselves into maintaining cloud-based storage for their users, since there’s no way the average reader could keep more than just a few of these things on their device at one time. (Remember, there’s lots of other things vying for that space.)

The question now before platform makers is whether they will begin exploring alternatives or will pass the pain along to users in the form of unsustainably large issue sizes. The three likely options on the table for them are: 1) Do nothing; 2) Start building dynamic layout and text rendering engines; or 3) Begin basing their platforms on Web technologies.

Doing nothing simply won’t cut it, as either they or the user will begin encountering problems too obvious to ignore (though I strongly suspect we’ll see it being done anyway for at least a little while). Building your own layout engine and the runtime environment to display it can be an extremely complicated endeavor. Just ask a browser maker…

And that brings us to the third option. An existing markup and layout technology that’s widely deployed, supported, and understood. That’s the Web. This doesn’t mean they necessarily have to shift to entirely Web-based delivery, either. Many of the most successful iOS (and Android) apps are actually hybrid apps in disguise, utilizing modified WebKit views to display information. Adobe has clearly started laying some groundwork for this. Why reinvent the wheel?