My Mac app icon design workflow
My favourite Mac app icons are simple enough to be easily read in the Dock, yet they contain interesting details when viewed up close. They have large vibrant areas of colour, yet they contain enough contrast and shading to give them a sense of volume.
There’s a bit of tension in those requirements, and I find creating decent Mac app icons pretty difficult. I’d go as far as saying I don’t have much insight on strategies for finding a good overall icon idea. It’s been a struggle for almost every Mac app icon I’ve worked on. It’s an exhausting process that seems to go nowhere, before finally producing a worthwhile result.
It’s not entirely random though. There are some guidelines that can be used to help rate icon ideas, and work out which concepts should be taken to a more polished stage. Yes, you have to choose something that can be represented as one or small number of objects. No, you shouldn’t use text. Certainly not more than a couple of letters or numbers, anyway. Yes, it should be legible at small sizes. Yes, it should feel like it has a similar weight to the rest of the system icons. A unique silhouette is a nice bonus, but not always essential. Circles are fine. Not ideal, but fine. Yes, your icon absolutely has to work on any background, including white, black, or photos of pets.
My process #
There’s typically six main steps I use when creating Mac app icons. I doubt my process is unique, but it does seem to produce repeatable, respectable results.
- Idea to scale.
- Model in 3D.
All steps may be repeated many times when trying out different ideas. Steps 3 and 4 are omitted for icons that don’t require any 3D work. This process was used for the creation of the suite of iStat app icons.
I wanted the iStat suite to share common colours and elements, so I tried to ensure they had unique silhouettes, to make it easy to distinguish them.
The same process was also used for the Display Buddy app icon (Display Buddy is an upcoming app from The Cocoabots).
App icons can be almost anything that vaguely relates to the job the app does. The best advice I can offer is to try many things, as quickly as possible. Sometimes being descriptive is the right approach, especially if the app is easily describable, or if App Store search discovery is important. Sometimes being abstract is the right approach, especially if the app covers many tasks, isn’t easily describable, or if being memorable is important. Most of the Igor Naming Guide can be applied to app icon design, and is worth reading, if you haven’t done so already.
Be prepared to move on when initially good ideas seem difficult to work with — the best idea in the world isn’t worth pursuing if you can’t execute it well. I do this all the time. Sometimes it’s due to lack of skill (I am terrible at drawing animals and many organic things). Sometimes it’s because the idea is just too difficult to work with.
I find working at small sizes helps. I sometimes draw small sketches on paper. They’re not pretty. They’re not the kind of illustration you see pinned to a wall in a slick “here’s our new logo” promo video. They exist only to get an idea out of my head, to see the proportions and basic form. Don’t worry if you can’t draw. You don’t have to show the sketches to anyone.
Try some obvious ideas. Try some abstract and ambitious ideas. Anything goes, and mistakes are cheap at this point in the process.
Idea to scale #
Sometimes, I don’t sketch ideas on paper. That’s because I’m not very good at it, and I’m usually faster working in Illustrator. And, if I’m working on an icon idea in Illustrator, I like starting at 32×32 pixels (usually using the Greyprint template). I use a 32×32 pixel grid, because it’s low fidelity, and because it scales up perfectly to all the larger Mac app icon sizes (1024 is an exact multiple of 32 etc). The small size and strict grid means you can’t put much detail in, which helps keep things simple for Dock sized icons.
I start by working in greyscale, or with a very limited colour palette. Colors are easy to change, and getting the overall shapes correct is more critical at this point. Once I have an idea I think might work, I save a PNG and use Icon Slate to preview it in the Dock. Does the idea work? If it does, move on to the next stage. If not, keep tweaking.
A very early test for the iStat Server icon is below. It’s a very quick composite of a render and a skewed version of the iStat Menus icon.
And, here is some Display Buddy sketches in Illustrator. Yes, we tried sun-cat face icons.
Model in 3D #
With the basic form worked out, it’s time to see what can be done with lighting and details. Now might be a good time to mention my bias — I like icons that look like they could be physical objects. They might be caricatures with emphasised features, but they could still be a real world item. Lighting and shadows should generally obey the laws of physics.
The goal of modelling in 3D isn’t to use the render as the final icon. It’s just a reference for form and lighting. I always reconstruct the icon in Photoshop, to give more control over colors, shapes, and for higher quality scaling. That means the 3D renders can be quite crude. The models don’t need to be constructed perfectly. Don’t worry if you’re not a Maya expert, because you don’t need to be. I’m certainly not.
Any design tool can be used, but I like Photoshop, because it contains some features that I find critical for realistic app icon design — great masking, dithered gradients, gradient maps, and other adjustment layers. Photoshop isn’t without it’s flaws, and all tools have compromises. Use whatever suits you best.
At this point in the process, I usually start working at 1024×1024 or bigger. Here’s an early and terrible render for the iStat satellite dish, created using Cheetah 3D.
I threw the entire model out and started again. Quite a few times. Here’s some near final renders.
Here’s the scene for iStat Server’s icon. The end of the needle and some other parts aren’t perfect, but they’re good enough to be able to work out the shapes needed.
And, here’s the Display Buddy scene in Cheetah 3D. This render was used a little differently to the iStat satellite dish (more on that later, in the styling section).
I’m using HDRI lighting with a hand made image for the backlit glow effect. The HDRI image is just a carefully placed black to white gradient that results in a back light with some leak at the extreme edges. I think it looks pretty cool, and I think I’ll use the technique in the future.
An example scene that uses the same HDRI light and no other lights shows off the effect well.
Renders are typically generated at the exact size needed. Given the strict grid I like working to, this is almost impossible to nail on the first pass. There’s a quick trick to getting it right on the second pass — place the render in your design tool of choice, and scale it up or down until it matches the size you need. Then, using the scaling factor to increase or decrease the render size. If your render was 1000 pixels wide and you’ve scaled the image down to 80%, then your render size should be 800 pixels wide. Scaling images lowers their quality, plus 3D rendering is slow. There’s no point in rendering pixels you’re not going to use.
At this point the scale and angle of the icon are pretty much locked in. If either needs to change, now is the time to go back and tweak the model. If you require approval for the icon concept, now is the time to get that as well.
All the shapes in the 3D render are traced as 2D shapes, so they can be styled in Photoshop (or whichever design tool you prefer). Some knowledge on how it will be constructed helps, but the idea is to capture any shapes that might be needed to recreate the icon without the render.
I typically trace the paths in Illustrator or Photoshop. It really depends on the paths involved. I find more complex paths easier to build in Illustrator. The iStat Server icon below was traced in Illustrator, because I needed to mirror the paths and use some other Illustrator specific features.
With all the shapes constructed, it’s time to paint everything. I really enjoy this part of the process — it takes a realistic 3D reference and lets me invent details and creatively ignore things that detract from the result.
Here’s the process from render to final icon, for iStat Server.
The iStat Server icon was quite difficult to get right, conceptually. We have an entire suite of iStat-related apps now, and the icons need to feel like they are part of the same family, yet different enough to be recognisable. That wasn’t easy, given the overlap in what they do. We settled on the remote monitoring clients as a satellite dish, and the remote monitoring servers as a WOPR-like sci-fi server core, which could be inside a satellite. It’s also the iStat Menus icon, seen from a different angle. The fan blades were fun to work out — they spin clockwise as seen from the top, so hot air is pulled up from inside the case, just like a Mac Pro.
When styling elements, I try to use features that are easily scaled in Photoshop. That means many types of layer effects can not be used, because only integer values are accepted. For example, a drop shadow distance of 3px should be 1.5px when the icon is scaled by 50%, but because only integers are allowed, it gets rounded to 2px. This means the value has been destructively altered. If it’s scaled back up by 200%, it’ll be 4px, rather than the original 3px.
Shadow offsets and other values in Sketch behave the same way. Shadow offsets and other values in Affinity Designer don’t.
It’s important to understand which features are acceptable to use for app icon design, where the artwork needs to be scaled multiple sizes, sometimes down to 1.563% of the original (1024px → 16px).
Because vector shapes can have non-integer positions and sizes, they don’t suffer from the same issues as layer styles in Photoshop. Pretty much anything that can be styled using layer effects can also be created using shape layers, so that’s what I do.
I also like to ensure elements used fit perfectly within the icon’s bounding box, keeping things tidy when translating and transforming. A base shape layer covering the entire icon area helps, too.
So far, I’ve suggested my icon design documents are constructed purely from vector shapes. That’s not always the case though. I do allow some rendered components, but only as fills for vector shapes. In Photoshop, the best way to achieve this is to paste the image in, then turn it into a smart object. In the example below, the smart object is clipped to the shape layer below, so the edge quality will always be preserved.
The colour of the render can be easily controlled using a gradient map, which is exactly what I did for the Display Buddy icon.
Now is a good time to work out if simplified versions of some layers and groups are needed at the very small sizes. Scaling the icon down to 32×32px is a good test. It depends on the icon, but I like building alternate components within the same icon document, flagging them by Photoshop layer colours. This means the document can be scaled to the icon size needed, and some layer visibility can be toggled as required, swapping in simplified versions. It keeps a single source file, so you don’t have to worry about changes staying in sync. If you’re feeling fancy, layer comps could be used to switch between the normal and simplified versions of the icons.
Retesting the icon again in the Dock, as a final check is a good idea at this point. Dock icons are bitmap scaled down, so you only need a single large size when testing (512×512px or 1024×1024px is great).
Hopefully the icon is looking great at this point, because changes become a little more difficult once the seven macOS app icon sizes are built. I use our Bjango App Icon Templates to store all the icon sizes in a single document — duplicate and scale the artwork as required for each size. When you’re done, use Save for Web in Photoshop to export each size as a separate image (if you’re using the Sketch or Affinity Designer templates, there’s different export instructions).
With the PNGs for each icon size built, they can now be dragged into Icon Slate, and the final ICNS file can be exported for use in the project.
I hope to continue to learn and evolve my process, but I feel it’s working pretty well at the moment. If you have any questions or comments, feel free to get in touch.
Published 2 February 2017.