iPad Retina Display Concerns and Tips

TL;DR

The iPad 3 retina display means a lot of apps and web sites are going to feel pressure for sharper (bigger) images. Knowing if you need to scale your images, the impact on end users and some ways to mitigate that impact is the right way to approach this.

What’s All the Fuss?

With the announcement of the new iPad’s “retina display,” there has been quite a lot of buzz among web developers about what that means for graphics. Some are welcoming the change by diving right into their projects and kicking up the size of their images, and some are lamenting the ongoing unabated bloat of web pages and apps since images can quadruple in size.

If you don’t believe Apple sees the potential for apps to grow in size, earlier this month it raised the cellular network download limit in the App Store from 20MB to 50MB. While there are many arguments on why Apple might have done this, knowing that the image assets for any app may bloat in size by four times when targeting the new display provides a rather compelling reason on its own.

David Sleight points this out in his post A Retina Display Reckoning for Magazine Publishers, using magazine page sizes as an example of the problem scaled-up images could produce:

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.

Apple also understands that images on the web will grow in size to target the iPad 3. The method Apple employs to deliver these images is not only inefficient, if web developers user Apple’s code as a baseline then all the sites they build will affect their users. From a post last week, How Apple.com will serve retina images to new iPads, Jason Grigsby outlines just what happens to the end user:

As far as I can tell, there is no attempt to prevent duplicate downloads of images. New iPad users are going to download both a full desktop size image and a retina version as well. […] The total size of the page goes from 502.90K to 2.13MB when the retina versions of images are downloaded.

This doesn’t even account for the HTTP requests for the original images, the HTTP requests for the high resolution images, and the HTTP request to test if there is even a high resolution image to retrieve. All of this is wrapped in a browser detection script, something at which a seasoned coder may wince.

Josh Clark points out in his post 3.1 Million Pixels Are Heavy that responsive design is still a method-in-progress and that using techniques like Apple does to serve high resolution images can push down far more than a user needs:

Sending a full-screen iPad image (1536×2048) to an iPod Touch browser (320×480) is overkill to the tune of 25 times the file size. Over a wireless connection, that’s gonna smart.

Peter-Paul Koch takes this a step further in his article The iPad 3 and Moore’s Law, where he talks about the impact that larger images will have on network speeds and ultimately user experience. Citing an example of an app that will bloat from 18.3MB to ~35MB, he brings the file size discussion to its logical conclusion:

Thus the Retina display puts incredible extra strain on the already-strained mobile web. Retina may be great for the end user, but the data networks simply cannot handle it (yet).

A common response to the scaling of images involves reliance on SVG images. Because SVG images are vector files, meaning the elements of the image are defined as scalable shapes instead of columns and rows of pixels, they can be sized up or down and still maintain the same file size and not lose any information. For images that are not photographic this sounds like a good workaround when targeting iPads only, regardless of SVG support in other browsers.

As anyone who has worked with vector imagery may know, however, vector images typically don’t scale in ways that maintain the goal of the image. If you look at the icons on your computer and explore all the sizes, you may notice some elements change shape, relative size, or are even discarded altogether. The article About those vector icons by Kirill Grouchnikov demonstrates this in detail with some great examples. He also has a well-supported conclusion:

So no, SVG is definitely not the answer. At least not today.

The SVG solution is the common comment response to Brad Frosts’ post iPad3′s Retina Display Will Wreak Havoc on the Web. As you read through the comments it’s easy to see why I stress about the return of the browser monoculture, this time iPhone and iPad rather than IE6, as I wrote about a couple weeks ago (The Return of “Best Viewed in…”). Sadly, from that entire assault of comments pushing SVG or suggesting users just accept the bloat, only three comments even thought to mention responsive images, something the W3C is working to address now in a dedicated responsive images community group.

How to Adapt

I haven’t reviewed all this to disparage the new retina display on the iPad 3. Instead an informed developer takes into account the pros and cons of every scenario and makes informed decisions that balance the needs of the user with the practicality of development efforts.

If you build stand-alone apps for the iPad, then you’ll need to make many decisions about the images you use and whether or not they all need to be updated. You may find that getting the right icon size can be a bit tricky though, and Louie Mantia was kind enough to put together this iOS app icon template.

As for web development, a few posts have started to pop up that echo the same ideas good developers have used for years — evaluate the need, weigh the solutions, don’t get too caught up in the bleeding edge. Here is a distilled list from the post iPad 3 and Retina Screen: What it means for your mobile commerce site:

1. Prioritize important images;
2. Make text into text;
3. Boost button sizes;
4. Make the logo bigger.

Brad Frost offers some tips in his post Optimizing Web Experiences for High Resolution Screens:

1. Media queries (that sadly still lean on vendor prefixes);
2. SVG, with a link to browser compatibility tables;
3. @font-face to put icon typefaces to use;
4. Detect network speed (its own special kind of train wreck);
5. Get involved with the W3C Responsive Image Community Group;
6. Don’t forget some basic best practices:
   • Start with low resolution images first;
   • Make sure you optimize your images;
   • Use CSS3 for corners, gradients, etc.;
   • Use resolution-independent options;
   • Detect the network (when you can);
   • Know your browser compatibility.

My simplest tip on all this is to look at the logs for the web site in question and see if enough users come in on iPads to warrant the stress at this point.

Related

• Case study: Tweetbot for iPad from ImageOptim showing some impressive manual optimization tricks.
• Is the New iPad Screen Too Good for the Web? from The New York Times, because your clients may be reading it.