Tips for exporting assets for iOS & Android design – UNITiD

If you design digital products, you will be confronted with slicing and exporting your visual assets so a developer can implement your design. If you are still in the prototype phase, please check out our popular prototype-tool: TAP for Fireworks.

For the web this is pretty much a straight-forward task. You can export the assets in just one size or use stylesheets to adapt to different resolutions. If you are designing an app that should run on Android and iOS devices, things get complex. You don’t want your button to look great on the iPhone 4s and blurry on the iPhone 3, right? Here are 10 tips we gathered along the way to help you slice and export assets for mobile apps. We use our favorite program Adobe Fireworks CS6 for designing, slicing and exporting.

(note: This is not a hands-on tutorial about how to create and export slices with Fireworks. If you are not familiar with the basics of Fireworks and slicing, check one of these videos.)

1. Talk to the developer

Talk with the developer of the app before you start. Developers have different ways of implementing the design. This is especially important with scalable assets like backgrounds and interactive elements like buttons.

Because you have to deliver (at least) four different assets for just one image, it will be a waste of time if the developer is expecting a different set.

2. Collect them all!

Assets should not be scattered around in folders, emails, libraries or different source files. The chance you have to change an asset is 99%. If it is not this release, it will be next year when your client decides to redesign their corporate identity.

So, get all your assets in a single document like this: Create a new file for your assets with the same name as the source file, add  ”_assets” to the filename. This way you always know where to find the assets of a specific file. Copy the assets from the original file and paste them in the new one. This will also help if  more than one person works on the project. Place similar assets (like icons, backgrounds etc) close together on a page, so you have an clear overview of all assets. Always use a transparent background when exporting your slices with transparency (PNG 32).

3. Every pixel counts

Slicing assets needs to be done very accurately. Take different button states. Active, inactive and pressed states of an asset need to align perfectly and have exactly the same size, otherwise it will look like the button is moving when you touch it.

To avoid blurry images always use snap to pixel (Mac cmd-k – Windows ctrl-k).

If you have a set of assets, like an icon set, it is recommended to create slices with similar dimensions for the whole set. Make them all 30×30 or 40×40 for example. After you exported the images you can check if the states match, by going through the images in Preview go back and forth between the states to spot minor differences in alignment or image size.

4. In iOS, size matters

If designing for a universal iOS app, you have to deliver assets at four different sizes. Retina and non-retina for iPhone as well as iPad.

Retina assets have to be exactly twice as big as non-retina images. You can scale the non-retina asset with 200%. Always double check if the slice is really twice the size.

If you design in retina resolution, keep in mind you have to downscale your images back 50%. So 1px lines or objects with uneven dimensions (like 31px or a 19px font) will give you trouble. What happens with the 1px line? How to handle a 15.5px images?

5. Android: Yes, more images

If you are (also) designing for Android, you’ll probably know that there are a lot of Android devices with different resolutions. Android thinks we have tons of time. You can see it coming, right? Yes, you have to export all the assets for (almost) all resolutions. Most common resolutions are:

Android Tablet
1280 x 800
1024 x 600
Android Phone
320 x 480
480 x 800
480 x 854
540 x 960
1280 x 720

For tablet you have to deliver the assets for two resolutions and for phone it is common to deliver assets for (at least!) three or four different resolutions. You can use the same asset size for 480×800 and 480×854 and sometimes also for 540×960, but this is something you have to discuss with your developer before you start slicing. Assets like headers, that are covering the whole screen width, must be delivered for all width sizes at all time (so four sizes for phone). Except for 9-patch assets of course.

Read more about Android screen sizes.

6. Getting the right asset sizes for Android

So how do you know what size your asset needs to be for all resolutions? Luckily somebody created a tool for this, so you don’t have to struggle. The Teehan+Lax Density Converter allows you to input the width and height for any density, and instantly see the dimensions you need to scale the graphic for each of the other densities. You can find more information on http://www.teehanlax.com/blog/density-converter/.

7. Use 9-patch scaling for Android

If you have assets that are used more than once in your application and are scalable, think about 9-patch scaling (don’t confuse it with the 9-slice scaling of Fireworks). You can use 9-patch scaling for scalable items like button-backgrounds. Things like icons will probably not scale properly, so unfortunately you have to resize them manually for all the resolutions. The 9-patch guide is always 1 px thick and must be black (#000000), otherwise it won’t work. Your slice will always be 2 px bigger than the asset (1px left and right and/or at the top and bottom). Thus if your asset is 48x48px your slice will be 50x50px. You can’t downscale 9-patch images, so you have to deliver them at the smallest size possible. This is also better for the overall performance of the application. You can use the Draw9Patch tool from Android to easily create or check your 9-patch images. For more specific information on 9-patch scaling and/or downloading the draw9patch tool check the Android Developers website.

Image source and more information: http://radleymarx.com/blog/simple-guide-to-9-patch/

8. iOS naming conventions

You probably aren’t the only one working with the (exported) assets. Everyone must be able to find the right assets easily. Also, you don’t want to overwrite existing images because you ran out of names. To keep your exported assets accessible, be consistent in naming your slices at all times (!) and agree on naming conventions with the developer. It is also useful to export your iPhone and iPad assets to separate folders named “iPhone” and “iPad”.

Most convenient slice-naming is: “screenname_type_thing / action_state” (state is optional) You are free to use whatever name you think is most suitable of course, consistency is the key. Also agree on language (do not use two languages at the same time, ie Dutch and English)

For iOS the following suffixes are documented and can be added for differentiating the various devices and resolutions:
@2x for retina indication
~ipad for device differentiation
@2x~ipad for using both

So your exported assets will have names something like this:
“home_button_share_down~iphone.png” and “home_button_share_down@2x~iphone.png”
“home_icon_logo~ipad” and “home_icon_logo@2x~ipad”

Bonus tip: You can edit your slice names in the Layer panel. Much more space than in the Property panel!

9. Android naming conventions

For Android it is also very important you are consistent with slice-names at all times(!). Again, make two folders for phone and tablet. Export specific assets to the correct folder and export 9-patch images to the root folder. They are used for both devices.

Agree on Android naming conventions for naming the slices. You can take a look at the Android Icon Design Guidelines for some useful tips.

We agreed on the following convention: “screenname_type_thing / action_state_resolution” (state is optional) or  ”screenname_type_thing / action_state.9″. Depending on slice type: add resolution if the slice is only usable for that resolution, add .9 if it is a scalable item that can be used on all resolutions. Make sure that the outer border actually contains guides for the 9-patch!

Assets will be named something like this:
“home_button_share_down_1280x800″ and “home_button_share_down_1024x600″
or “home_button_share_down.9″

10. The symbol library is your friend. Use it wisely.

Your initial design will probably be edited a few times along the way before you deliver the final visual designs and assets. Even after final delivery you sometimes need to update the design. That’s why you should use a library with symbols as much as you can. You don’t have to update every assets one by one. Just use the library in different documents (so in your source file and in your assets file). When symbols are edited in the source file, you can update the symbols in the assets file with a single click. Look at the Adobe Help Center how to do this.

That’s it! Please feel free to add tips to the comments