If you are a graphic designer preparing graphics a multi-platform mobile app, there are a few things you should know before you start, to make things easier on yourself and the developer implementing your design. This article focuses on the iOS and Android platforms, beginning with a brief overview of the layout tools for each OS, then looking at how to deal with different screens, sizes and orientations.

Tools for Laying out Graphics

You don’t need to master the tools your developers use, but the more you understand your developer’s tools the better you will understand challenges your design may presents, and how the final graphic assets need to be composed. Some elements of your design can be implemented as raster graphics, other elements might need to be drawn via code for performance reasons. This is especially important when you are designing for multiple platforms with their own unique approaches to app design.

iOS

Interface Builder is the primary tool an iOS developer uses to implement layout. It is a (mostly) wysiwyg tool for laying out images, and UI controls. For alignment it supports absolute positioning or aligning an object relative to the bounds of its container. For sizing it supports fixed size, stretching, or scaling with an object’s parent.

Two limitations of interface builder to keep in mind: it does not allow the developer to layout objects relative to other objects, only relative to an object’s container, and it does not support rotating an object — that is something that has to be done via code.

Android OS

The most popular tool among Android developers seems to be the ADP plugin for Eclipse. While it does include a semi-wysiwyg layout tool, it offers a poor user experience and most developers I know choose not to use it, opting instead to layout everything via XML. For alignment objects can be absolutely positioned, aligned relative to their container’s edge (accounting for margins and padding), or aligned relative to sibling objects. For sizing it supports fixed size, stretching or scaling.

The Android platform provides two development tools that the iOS platform lacks: Drawables and Nine Patch graphics. Drawables are graphic (shapes, lines, colors, gradients, etc.) that are defined via XML and many of the platform’s UI controls are defined this way. Nine Patch graphics are specially formatted png files with a .9.png extension and defined stretchable regions. Nine patch graphics scale along the stretchable areas and do not distort the non-stretchable areas — Button backgrounds are a good example. You can read more about nine patch graphics at Android – Draw 9Patch and Android – 2D Graphics – Nine Patch Drawable.

I should mention that it is possible in iOS to set the top and left “cap” sizes of an image via code, the effect of which mimics the behavior of nine patch pngs. The Android OS makes this a feature that can be defined in the graphic itself vs having to do it via code.

From a designer’s perspective the lack of a robust wysiwyg layout tool is a major drawback for the Android platform. This is something that Google apparently recognizes since they have announced a new layout tool with the release of Gingerbread (Android 2.3) and a commitment to make continual improvements.

Handling Multiple Resolutions and Screen Sizes

When designing for multiple platforms it is possible, however unlikely, that you will only need to be concerned with a 320×480 screen size. Its more likely that you will be developing for at least three different screen sizes and as many as nine. The three sizes you are currently most likely to design for are:

Display	Screen Size
iPhone 4 Retinal	640×960
Android High Density (HDPI)	400×800 or 400×855
iPhone Original / Android Medium Density (MDPI)	320×480

 

Notice that the original iPhone and iPod Touch displays are the same size as most MDPI Android displays.

If you are designing an app that targets tablets as well as mobile phones and is to be supported across the widest possible range of mobile iOS and Android devices you will naturally want to include the iPad, the first generation of Android tablets, and less common models of Android phones. The relevant sizes are:

Display	Screen Size
iPad	1024×768
Android Galaxy Tab	600×1024
Other Android HDPI	480×640
Android Low Density (LDPI)	240×320

 

This brings the total number of screen sizes to seven — eight if you count the two common Android HDPI screens separately. If you consider the difference in design styles between platforms you could count the 320×480 iPhone and Android MDPI devices separately bringing the total to nine. Feeling a little daunted yet?

While there are many different screen sizes to consider it is unlikely you will have to create a separate design for each individual screen size. Naturally you will consider how your design might change to take advantage of the larger screens of the tablet devices but for the mobile phones you will typically only need a single design with minor differences where the iOS and Android platform UIs diverge, and that can support a little vertical scaling for some of the Android screens. With a little luck you will only need to create two designs, one for tablets, and one for phones.

I recommend designing for the largest screen size for the mobile phones. When your design is ready to be sliced up into individual assets you can save a little time if you start with the highest resolution first and work down to the lowest resolution. This is the approach I recommend if you have a single design for both platforms:

• Start with the graphics for the iOS Retinal display.
• For each image you slice, save one at full size with the “@2x” extension and one at half size without the extension. This takes care of the iOS phones, iPod Touch and (possibly) most of the Android MDPI graphics.
• Make a copy of your design and downsize it to match the Android HDPI screens.
• Slice up graphics for the HDPI screens and (optionally) scale each image down to match the LDPI screens.

Did you notice I say its optional to create a set of graphics targeting Android LDPI displays? The Android platform allows a developer to specify a separate set of graphics for high, medium and low density screens. It also allows the developer to specify a default set of graphics to be used if the screen specific graphics are missing. The default graphics are scaled up or down as needed. I like to take advantage of this behavior and let my MDPI graphics be my default set, and specify just my high resolution set. The MDPI graphics look fine downsized for a LDPI screen and I get to save a few kilobytes in the overall file size of my app.

If this approach works for you then you will only have to save three sets of graphics, allowing for a few one-offs for each platform to maintain its overall aesthetic. If you create separate designs for iOS and Android you can follow this same high to lower resolution approach and still only slice up one additional set of graphics.

Naming Conventions

For the Android platform your high, medium and low resolution graphics will all have the same filename and extension and your developer will organize them into their appropriate directories inside the application. This is not the case for iOS. Apple provides a naming convention for specifying high and standard resolution graphics and even which device a graphic is for. The naming convention is the image name, followed by the optional high resolution modifier, followed by a device modifier, and finally the file extension. Like so:

Standard: <ImageName><device_modifier>.<filename_extension>
High resolution: <ImageName>@2x<device_modifier>.<filename_extension>

The and portions of each name specify the usual name and extension for the file. The portion is optional and contains either the string ~ipad or ~iphone. You include one of these modifiers when you want to specify different versions of an image for iPad and iPhone. The inclusion of the @2x modifier for the high-resolution image is new and lets the system know that the image is the high-resolution variant of the standard image.
You can read more about the iOS approach in the iOS Application Programming Guide – Supporting High-Resolution Screens

A Word about Pixel Density

As of Froyo (Android 2.2) MDPI graphics are the Android baseline. When saving image resources, the Android documentation recommends saving the MDPI graphics first, then scaling up 150% for HDPI graphics and then scaling down 75% for LDPI graphics. I disagree with this for two reasons: first designing for HDPI and scaling down to MDPI seems to get a better result and 2) their math seems wrong.

If a HDPI screen is 150% larger than MDPI and LDPI is 50% smaller than MDPI it means that HDPI is twice the size of LDPI graphics. Do the math if you don’t believe me. The thing to remember is we’re talking about pixel density here, not screen size. An HDPI screen might be double the pixel density of an LDPI screen but that does not mean it is going to be double the screen size. Just look at the common Android screens and you’ll see a common HDPI width of 400 and a LDPI width of 240 and it should be clear that when it comes time to saving out your images its not going to be as straight forward as scaling HDPI graphics to 50% (or if your a stickler for the rule book, scaling MDPI graphics to 75%). Just keep this in mind and remember to do the math when you save your Android graphics.

If you’re curious to know more about pixel density (who isn’t?) you can find a list of displays by pixel density at Wikipedia – List of displays by Pixel Density

Font Sizes and Colors

Color values are represented differently between the iOS and Android platforms. On iOS, your developer will specify color values in Interface Build and in code as RGB number values where red, blue and green each range from 0 to 255. On the Android platform color values are represented as RGB hex values where red, blue and green each range from 0 to FF. Do your developer a favor and provide your color pallet in both sets of values. Seriously, he’ll thank you.

On both platforms, your developer is going to specify font values in pixels, as opposed to points so I recommend you use pixel values in your designs. If for some reason you have to specify your fonts in point values you or your developer are going to have to do the math to convert points to pixels for the relevant screen density if you want the app to be a pixel perfect match to your comp. To convert points to pixels, remember that 72 points is always 1 inch, and follow the formula : pixels = (72/screen ppi) * points.

Dealing with Screen Rotation

If the app your designing is to support both portrait and landscape orientations you must be careful to consider how your graphic assets might need to scale to fill space in different orientations, or how non-scaling graphics will realign without clipping, overlapping or obscuring other parts of the UI A good guideline is to expect to loose just under half of your screen real estate when the device rotates.

For text, its easy to let it span multiple lines. For images, its a good idea to keep the width of graphics equal or less than the width of the screen in portrait mode and, unless scrolling is desirable to keep the height of a graphic limited to the height of the screen in landscape mode.

Dealing with State Changes

If you’ve never seen the term “state change” before, just consider how a button looks when its not pressed vs when it is pressed. The pressed and not-pressed appearances of a button are two different states of the button. Depending on your design you may need to make separate graphic assets for each state and perhaps a few more.

To reduce the number graphic assets needed to support state changes use the system provided UI controls where necessary. When you need to use custom controls or change the appearance of the stock controls try to do so in a way that lets you maximize reuse. For buttons, you might define a scalable background graphic for its pressed and not-pressed states so the same two graphics can be reused for multiple buttons of different sizes and with different text labels, and remember that many graphic assets on the Android platform can be defined directly in XML. Your developer should have some good insight in how to reduce the number of images needed while getting the desired appearance, so ask for his recommendations.

Strategies for Performance

As a designer you should be aware that the graphics you slice up for your developer can have a direct impact on the performance of the application. The file size of the image can affect load times but the larger concern should be with alpha layers and transparencies. The platform’s operating system has to calculate alpha layers and image transparencies whether or not they actually have any noticeable visual impact on the look and feel of the app. So, when you are preparing your graphics remove any unused alpha layers from your images and avoid transparencies in any graphics that will scroll or animate — this should be 100% opaque to maximize the performance of your app. Remember that both iOS and Android lets you developer create many simple graphics via code and this approach may be preferable at times. Ask your developer when in doubt.

Wrap Up

Hopefully the tips in this article will help reduce the number of separate graphics you have to make to support your mobile app designs.

Check out these artciels for further reading:
Android UI Guidelines – Icon Design
A list of stock Android graphics: http://androiddrawableexplorer.appspot.com/
Android icon generator: http://android-ui-utils.googlecode.com/hg/asset-studio/dist/index.html
iOS Human Interface Guidelines – Custom Icons and Images
A partial list of required iOS graphics is provided in the Custom Icons and Images section of the iOS Human Interface Guidelines.