A modern iOS App Icon and Image Workflow with Blade

Posted on 2015-12-16

There are a few steps in a typical Designer-Programmer exchange. This starts when either you (the developer) — are part of the team and the designer had finished design work, or when you (the developer) hire a designer or make contract work, and now you need to integrate the deliverables into your app.

The following is an explanation on how I chose to attack this problem, and an open source tool called Blade I’ve built to make the solution work.

Current Workflow

You typically need an app icon, and image assets you would like to include in various resolutions, where a given image would be at 1x, 2x and 3x resolutions, and an app icon would be a bit more involved.

Here are the steps:

  1. (Designer) Design
  2. (Designer) Produce — cut sizes, adapt resolutions
  3. (Designer) Handoff — provide assets, and specs
  4. (Developer) Integrate — place each provided asset in its catalog, and resolution. Repeat until it looks good.
  5. (Developer) Identify mismatch — sum all glitches up, provide feedback to designer.
  6. Go back to either (1), (2) or (3) based on step (5)

Here are all the things that can go wrong, and how Blade compensates for them:

  1. (Designer) Producing sizes — can produce wrong sizes for wrong assets. Can use the wrong tool for the job. Can save in wrong formats, and so on. Errors can also be introduced by tooling even when the designer may cut manually (using Sketch for example), or automatically (using a Photoshop script or a dedicated “App Icon” generator website). With Blade: the designer produces and delivers just one size of the asset.

  2. (Designer/Developer) Handoff — human miscommunication. The primary cause in a lot of software fiascos. although not as costly as a spaceship crashing, miscommunication between designers and developers still rots their workflow slowly and surely.

    With Blade: reduce communication, by providing a single asset, of known size — the largest possible.

  3. (Developer) Integration error — placing the wrong assets in the wrong resolutions, fitting assets incorrectly, and so on.

    With Blade: automates asset catalog creation, and takes that concern away from the developer.

  4. (Developer/Designer) Communication error fed back into the feedback loop. Injecting errors into a feedback loop quickly creates an avalanche effect.

    With Blade: even if there is a feedback loop, Blade enables skipping all of the production steps, because it runs them automatically. So basically it is — get a new asset, rerun Blade.

Blade Powered Workflow

With Blade the previous error prone workflow is reduced to a safer one:

Between the lines, this new workflow also establishes these:

  1. 1 size to rule them all. 80⁄20 best case.
  2. Automated steps 2–4
  3. A zero-friction process to repeat for providing feedback. Laziness as a natural optimizer.

Blade Quickstart

Using Homebrew:

$ brew tap jondot/tap
$ brew install blade

Now, within your project do:

$ blade --init

And take a look at the Bladefile that was generated for you.

This is how working with Blade looks like (movie might take a while to load):

If this is interesting for you, see the Blade README.md file, for the full power of Blade.

Why Blade Works

Contents.json

Blade was created in the wake of the Apple Watch release. At the time no tool supported the newer Apple Watch form factors, and it only emphasized the need to be coupled to Xcode itself, and not an external website/tool. Using a generator website or a Photoshop script — you are at the mercies of these, waiting for their update in the best case, and in the worst case — making all the additions by hand.

Apple saves each image catalog in their own format, in a file called Contents.json. Blade reads and generates this same format, and practically behaves like Xcode itself. This promises a slick integration and future-proof tooling — when a new iOS is released with new form factors, Blade doesn’t need to update, nor do you need to, just rerun to generate additional sizes.

Trade-offs

Every great solution and great design has strong trade-offs. In fact, when you can’t identify the trade-off a product or service make, that’s where you should be cautious.

Blade makes the following trade-offs:

  • The deliverable is a single big image per catalog. Every other size is a derivative of that. This means, you cannot provide a completely custom design for a exceptionally small/big variant of the asset. We also recognize that in this scenario, no other tooling will help you and in any case you should resort to a manual workflow.
  • Blade works with a single file format — PNG. While first versions of Blade included SVG, we found that Lanczos, as a resampling algorithm for scale reduction worked perfectly. We removed SVG support to avoid confusing users — SVG renderers out there make a poor job of rendering a pixel-perfect image, and including a headless browser would make rendering a lot slower.
  • Blade works with Xcode, and for Apple technologies only. We chose not to support Android by default, however it should be easy to add it.
  • Blade is meant for the developer. There is no UI, and you are encouraged to find you own convenient way of maintaining assets — storage and versioning.

Summary

Blade is now powering all of my iOS app. Working with designers (one of which happens to be my Wife) have become a lot more productive, and in the case of my Wife — makes a happier marriage :)

Feel free to submit pull requests or feedback on the Blade repo.