There is a lot of “process” that goes into designing for mobile devices, but sometimes you just wanna jump in and get your hands dirty! This post is designed to give you the tools you’ll need and the basic design and technical requirements to get you up and running quickly.

Standard Screen Sizes and Icon Sizes

If you haven’t read the Apple Interface Guidelines for iPhone and iPad yet, you should. It’s a lot of information, but well worth the time spent to understand how Apple thinks about application design. These guides also spell out detailed specifications for screen size, icon size, and resolution. Next, I’ll address a few commonly asked questions and summarize these specifications in an easy to digest format!

What’s the Resolution of the New Retina Display?

The iPhone retina screen is a spectacular thing to see. When viewing the new and old screen side by side, it’s obvious there are changes in this display that affect the design of your app. See this side-by-side screen comparison video.

You can see in comparing the two devices that the screen dimensions for iPhone 4 are unchanged from the previous model. However, both the iPhone 4 screen size and the pixel density of the screen is DOUBLED, giving it a 640 x 960px screen size (compared to the previous 320 x 480px size) and a whopping 326 pixels per inch (compared to previous 163ppi). This new screen squeezes 4 pixels where there used to be one - that’s why the images look so crisp and delicious!

When reading about screen resolution it’s easy to quickly become confused. The fact is the final exported file type on the iPhone is usually .png and Xcode doesn’t consider the ppi value saved when rendering images. If you follow the dimensions specified below, you’ll be in good shape!

Photoshop Setup Specs:

Graphics for the iTunes Store

Icon: 512 x 512 px (.tif, .jpg or .png, 72dpi, RGB)
iPhone Screenshots: 320 x 480 px or 640 x 860 px (.tif, .jpg or .png, 72dpi, RGB)
iPad Screenshots: 1024 x 768 px (.tif, .jpg or .png, 72dpi, RGB)

The Future of Screen Sizes

While we’re discussing screen sizes, it’s important to talk about the future of digital devices in general. I’m no fortune teller, but in the past year alone it’s no secret touch screen devices of all kinds are multiplying like rabbits and they’re producing offspring with varying screen sizes. Aye! As designers, that means we need to be prepared for how to translate designs to multiple devices and operating systems.

An app life cycle can run one of many courses. Some apps live on one platform exclusively, others branch out into other mobile devices or even a web-based presence. Creating scalable graphics saves you the headache of re-creating graphics for each specific platform. Using shape layers or vector smart objects is the best way to deal with the proliferation of screen sizes and operating systems.

Design for 3.0 or Retina First?

Designing icons for iPhone was my first introduction to the decision of “start small and scale up” or “start large and scale down.” For me, it became obvious after a few executions that designing for the 320 x 480px screen size and then sizing up to 640 x 960px is the better option. Designing for the smallest screen size eliminates the disappointment of losing details when a design must be sized down later.

How to Create App Graphics for Retina Display

Let’s say you’ve designed an app for a 3.0 iPhone and you want to prep this app for the iPhone 4 retina display. What do you do? Just size it up from 320 x 480 to 640 x 960? Yes. The problem is, if you haven’t created all of your graphics using shape layers or vector smart objects you’re images are going to look pixelated and grainy.

How Big to Make Your Buttons

For both iPhone and iPad the minimum size tap target area Apple recommends is 44 x 44 pixels. Leave it to Apple to quantify the average fingertip size of human beings. :) If you want to go smaller be sure to adequately space tap-able areas to prevent mis-taps.

Testing Your Design

“Testing” a design may sound odd, but designing for a mobile device on a laptop or desktop monitor can be tricky. Even if you follow standard guidelines like the 44 x 44px tap target rule, proportions and sizes may look significantly different when displayed on the device vs. your computer screen.

The easiest way to test your design is to “Save for Web” each screen design in .png format and sync to your phone using iPhoto. Once the images are synced, you can flip through and simulate what the actual app will look like. This is also a great way to share mockups with clients to give them a true preview of the app.

Design Templates for iPhone and iPad

Now that you have some basics under your belt, it’s time to start designing! Luckily there are plenty of resources available to help you get acquainted with the various iPhone and iPad interface elements. Even if your goal is to create completely customized interfaces, these templates are helpful in getting a baseline grid or dimensions of on-screen elements properly proportioned.

iPhone Templates

iPhone GUI PSD from Teehan + Lax
iPhone GUI PSD Retina from Teehan + Lax
iPhone Stencil for OmniGraffle from Patrick Crowley
iPhone UI Vector Elements from Mercury Intermedia

iPad Templates

iPad Stencil for OmniGraffle from Information Architects
iPad GUI PSD from Teehan + Lax
iPad Vector GUI from Icon Library

What File Format Do I Use for iPhone Graphics?

All graphical assets that will be used to build an app are exported in Portable Network Graphics (.png) format. Technically, the iPhone can display other file formats as well, but PNG files are automatically optimized by the iOS SDK, and consequently should be the preferred format.

This applies to all elements (nav buttons, bars, etc.) and any other imagery showcased in the app. For example, let’s say your app is a portfolio for a photographer. The photos showcased would also be exported in .png format.

The setting to export .png format in Photoshop (File > Save for Web and Devices) looks like this:

Preparing Files for Your Developer

Before handing your files over to a developer, it’s important to understand their capabilities with regard to slicing and dicing your file. If your developer is experienced in slicing and exporting, it can be a huge time saver to offload that task. Personally, I prefer to cut up all of my files to ensure all images are sliced out properly.

When saving out your final images, try using intuitive file naming conventions that will make locating and referencing the correct image files easier for your developer. Here are some example prefixes and suffixes I use:

• “btn-” for all button images
• “tab-” for all tab bar images
• “bkg-” for all background images
• “-up” for in-active state buttons
• “-down” for active state buttons
• “-hover” for hover state buttons
• “@2x” this is a standard suffix required for all retina display graphics

Another tool I use to communicate with developers is a .pdf file that includes all screens plus notes regarding the design. I define the typefaces, sizes, line spacing and all other styling so there is an easy reference that the developer can use without having to open Photoshop. Yet another resource I provide, especially when I’m working with off-site developers, is a screencast (ScreenFlow and iShowU are my favorites) of the app, walking them through every aspect of the design. This is especially helpful if the app contains animations and/or transitions that are better illustrated in a video.

Conclusion

Technical specifications aren't sexy but they're important. Commit these details to memory and you will save yourself a lot of headaches down the road!