The pain of producing mobile icons and splash screens — and how to get rid off it

TL;DR: Let your build system produce icons and splash screens. Gulp plugins open sourced.

Ronny Roeller

Published in

NEXT Engineering

2 min readJan 4, 2017

Iterate to the death

Every mobile developer has been there: The UX team gave you the final version of the icons and splash screens. You created dozens of images for all kind of resolutions, page orientations, iOS/Android/etc. Finally, everything is nicely wrapped up.

Well, until the UX team comes back: “He, we made a small mistake with the colors. Could we change the icon? It’s just a minor thing.” So, you go back, recreate all the icons and splash screens, and package everything up.

Next thing you hear? Of course, the UX team: “He, user testing has shown that people don’t get the message in our splash screen. Could we change the text? It’s just a minor thing.” So, you go back, recreate all the splash screens, and package everything up.

I‘m sure you can guess how the story ends. You have been there. There will be dozens of “minor things” and you will end up producing 100s — if not 1,000s — of images for icons and splash screens.

The simple truth: Producing all these images just sucks.

Who wants to be a Mechanical Turk?

So, why can’t these UX guys get their stuff right the first time? Don’t they see that this is painful? Well, better don’t ask this question. People might start asking why developers can’t produce bug-free software at the first shot…

The question we should really ask ourselves: Do we aspire to be Mechanical Turks or developers?

If we fix a bug or add a new feature: Do we manually compile our code? No way! We have tools that do this automatically for us — aka a build system. So, why do we manually “compile” the latest splash screen into dozens of target images? Why not manage just one “source image” and let the build system to care of the rest?

Long live the build system!

And that’s exactly what we ended up doing: Our UX team creates app icons and splash screens as vector graphics, which can be scaled without losses to any size. We only check those vector graphics into our source control system (as SVG files). Our build system scales then these SVGs to any target size we require, converts them into PNGs, and places them wherever iOS and Android needs them.

Developers happy. UX team happy. Customers happy.