The 10 commandments of Sketch exports for iOS and Android
By Tim Wouters, senior UX Researcher at Internet Architects
Granted, for a visual designer, Sketch makes it really easy to export icons and images for multiple screen resolutions. But especially for native mobile apps, exchanging design assets (why do people still call them slices?) with developers can go a lot smoother if you keep a few common pitfalls in mind. Here are some of the things we’ve learned in our collaboration with iOS and Android development teams.
For the web, things have become relatively easy over the past few years. Thanks to the amazing versatility of CSS and near-universal support for SVG, UX designers can deliver a single set of resolution-independent assets that work across all browsers and screen resolutions. Icons can be resized and recoloured on the spot to work in different contexts and colour schemes. In short: it’s cross-platform bliss!
When it comes to native app development for Android and iOS though, the rules are not only very different, but also not as well documented. Sure, Apple have their Human Interface Guidelines and Google have done astounding work with their Material Design framework. And while they do make some recommendations for icon sizes at various screen locations, there are many intricacies and good-to-knows that might not be very obvious to visual designers, especially when they come from a web development background.
Again, every project is unique and exposes different requirements, so your mileage may vary. But here goes.
1. Design @1x, import @4x
Don’t get distracted by the plethora of different screen resolutions out there. Design for the “logical pixel”, called “points” by Apple and “dp” by Google. Although an iPhone 7 features a screen resolution of 750 by 1.334 physical pixels, it only really displays 375 by 667 logical pixels at 2 times the resolution, to make the picture sharper. So in Sketch, make your artboards correspond to the logical size, not the physical one.
As long as you work with vector (read: SVG) shapes, it is very easy in Sketch to define multiple export sizes from a single source. If you have to include rasterized bitmap assets — like photos — do make sure the source material is imported into Sketch at least at 4 times the “1x” resolution, because you’ll need to export to higher resolutions again afterwards and you don’t want your fullscreen background picture to look fuzzy or pixelated on those high-end smartphones.
2. Put all icons into same-size bounding boxes
Not all icons are the same size. Some are square, others have a tall or wide shape. If you want to make developers really angry, you should give them the shapes “as is” and have them worry about nicely aligning all those icons into rows or columns.
To make everyone’s life that much easier, it helps to put every single icon into a square “bounding box” that is the same size everywhere. If you use one of the Material Design icons from Google’s own set, this square box comes with the package. But they’re still the exception. Download an SVG icon from The Noun Project or from Ionicons, and you’ll get all kinds of aspect ratios.
In Sketch, you can draw the bounding boxes either with a rectangle shape, or with a “slice” object. We prefer the first option simply because it makes it easier to move the icons around, position them and edit them.
3. File names are important. No, really.
Try to give your assets logical names that represent what they look like, and avoid whitespace, uppercase or any special characters. Stick with only lowercase alphanumeric characters (a-z, 0–9) instead, with underscores as separators:
- Good: “ic_search_active”
- Bad: “Active search icon”
- Bad: “Group 16 copy” (this happens in Sketch before you know it)
- Bad: “noun_123456_cc.svg” (what you often get when reusing icons from existing libraries)
The reason for this constraint is because Android translates the asset file name directly to a Java field name. And while you’re at it, you might as well keep your iOS naming logic in sync.
4. Be conservative in what you call an “asset”
In iOS and Android, most of the basic shapes like (rounded) rectangles and circles can be drawn in the app by the developers. So don’t waste your time exporting every single button in your app as a separate asset. Stick with just the complex shapes (like icons) and the bitmap images (like photos).
The same goes for any drop shadows that you might apply to specific screen elements: verify with the developers whether they can draw the shadow in-app, before you venture into managing multiple asset states in your design tool of choice.
Additionally, it pays off to examine whether some of the icons you use can be acceptably replaced by a Unicode text character. Shapes like stars (rating), chevrons and pager dots are only some of the more obvious examples.
5. The “stretchable bitmap” hack
Sometimes you’re working with shapes that have stable edges, but can grow depending on the content inside it. Think of buttons or tabs with a gradient background (short label, long label), or speech bubbles in a messaging app. On the web, this is mostly a solved problem, but CSS veterans will remember how they got excited about the “Sliding doors of CSS” hack way back in the early 2000’s. In the native world, this very same problem still surfaces today.
Luckily for us, iOS happens to support this use case right out of the box: you can specify a resizable area on a bitmap image together with “protected” end caps. Android doesn’t, but lo and behold: it does support a magic spell hack called “Nine-Patch images”. Basically, you can tell Android which parts of the asset are stretchable and which are protected by drawing 1-pixel black borders around the actual image. Ugly as hell, but it works. And of course, the web wouldn’t be the web if you couldn’t find a nice Nine-Patch generator tool to do the heavy lifting for you.
6. Go monochrome
Just like you can use single-colour SVG icons as a source on the web, and give them a different colour through CSS, assets can be coloured dynamically on iOS and Android as well. Even if they are exported to a bitmap format, such as PNG. So don’t maintain separate “blue” and “orange” versions of a specific icon, just give the developers a single, white version.
7. Respect export conventions for different screen resolutions
Smartphones come in all sizes and capabilities. It all started out with relatively low-resolution screens (the “@1x” or “non-Retina” ones), but nowadays some of the higher-end Android smartphones can go up to 4 times the original resolution. That’s 16 times the number of pixels compared to just 10 years ago!
Because full, resolution-independent SVG support in native applications is still in the early stages, we’ll have to work with raster-based assets like PNG and JPG for some time to come. Which means that we’ll have to export multiple “sizes” for each individual asset.
To make things even more difficult, Android and iOS have different requirements for specifying which image size is suitable for which resolution:
Android requires you to put assets for each screen resolution into a separate folder with dedicated names:
- “drawable-mdpi” is where you put assets for the @1x resolution,
- “drawable-hdpi” corresponds to @1.5x resolution
- “drawable-xhdpi” is for @2x resolution
- “drawable-xxhdpi” is for @3x resolution
- “drawable-xxxhdpi” is for @4x resolution
For iOS, on the other hand, you can put all assets into a single folder, as long as you append the correct resolution identifier to the file name:
- “ic_search_active.png” for the @1x resolution
- “ic_search_active@2x.png” for the @2x resolution
- “ic_search_active@3x.png” for the @3x resolution
- Contrary to Android, there is no “@4x” resolution. Yet.
In Sketch, you can specify these @ suffixes to be added dynamically upon export, so there’s no need to add them to your layer names. What’s left is the inconvenience of having to do multiple export actions (5 for Android, 1 for iOS), but this kind of repetitive tasks is what AppleScript was designed to do. Or you can revert to Sketch’ rich plugin ecosystem to do the job for you.
8. Full-size background images
For pictures that need to occupy the full screen edge-to-edge, we found that working with a 2.560px by 1.440px source file covers most bases. Because of its 16:9 aspect ratio, it’s a natural fit for most smartphones on the market today, and it’s the “@4x” version of a 360-by-640 pixel screen, which should be more than enough to support older smartphones.
Of course, if your app needs to scale all the way up to the 12.9' iPad Pro, this size won’t cut it.
9. Icon style: go cross-platform or follow platform conventions?
Android and iOS apps use different icon styles: Android’s material design icons are little bit “fatter”, while Apple sports ultra-thin icon outlines since the introduction of iOS 7. Moreover, the actual shape of the same-purpose icons can vary significantly:
Although this might not work for everyone, we found that investing in the development of a single, cross-platform icon style is worth the time and effort. Not only because it’s easier to maintain, but also because a custom style better reflects the app and the brand it represents.
For those icons where platform conventions do require a radically different shape, we still made sure that the icons maintained a consistent look and feel:
10. Performance: keep your assets small
Although this seems like a real no-brainer, it’s easy to forget that you can shave a significant amount off the total payload of your exported assets by just running them through an image optimisation tool like ImageOptim. Especially for those @3x and @4x resolutions, the difference can be huge. And every saved bit makes your app just that one split second faster.
Conclusion
Despite all the optimisations listed above, of course we’re still stuck with having to maintain multiple PNG versions of what are basically resolution-independent source files to begin with. Which kinda sucks.
So keep an eye on the nascent support for SVG on both iOS and Android. Google is plowing forward with its expanding support for “vector drawables”, and Apple has some basic support in the form of PDF vector assets. But we’ll still have some way to go before we can finally put those PNG and JPG assets to bed.
The post The 10 commandments of Sketch exports for iOS and Android appeared first on Internetarchitects.be
