Codifying style guides in Swift

Embracing change and befriending designers

[A follow up to this post is available, called Advanced baseline grids for iOS]

There was a time where I would press designers to give me verbal confirmation that the style guide they were handing off was final. “Ok”, I’d reply cautiously. “That’s it. No more changes. Hands off. You’re done!”.

Anytime someone says final or last version, this comic pops into my head and makes me smile. The reality that I’ve come to accept across all aspects of life, and especially across product development, is that there is no such thing as final.

Change Happens

If we focus on the style guide as a key interface between design and engineering, I’ve found there are two big types of change.

1. The details of the style guide can change: “let’s make that purple a touch darker”; or “let’s add an alternate purple”
2. The application of the style guide can change: “let’s use the other beige for that text”; “let’s use the secondary button type there”

When you accept this, the style guide stops being a contract that you can bludgeon the designer with, and instead merely captures a snapshot along the path of product development. So what does this look like in practice? For simplicity, let’s reduce the problem space to focus on the coding of colors from a style guide (although the same concepts can, and have been applied to fonts etc.):

Characteristics of a flexible style guide implementation

• We want to limit the UI to a finite color palette — guarding against random RGB/Hex codes littering your code
• We need some flexibility with the alpha channel of palette colors
• It needs to be possible to see which UI elements use a particular color
• We need the ability to change a color across the whole app (“Make that purple darker”)
• And the ability to change a UI element color without affecting everything else (“let’s use beige for that text”)

I’ve found that constraining the implementation of style guides in a certain way can lead to a subsystem that actually liberates the design and style guide in a way that is tremendously rewarding and continues to pay dividends long after it is established.

Prerequisites

• Programmatically setting colors — no XIB or Storyboard colors
• If you want to use colors in Interface Builder, be diligent about programmatically re-setting them in awakeFromNib, or viewDidLoad
• In interface builder, use a custom palette with your style guide colors specified by hex value (to avoid frankly disgusting color profile nonsense with RGB and your screen color profile)

The Solution

Part 1: Establish your Palette

Want to tweak a hex value? Do it here. And have confidence that the entire UI will get the updated value. Want to check you’re consistently setting colors via code? Change these values one-by-one to be something starkly different (bright green is a good one) and see what is left over when you load up the app.

Part 2: Enumerate the UI which needs color

This is not a place for generalizing. Generalizing will be your undoing when a change request breaks that generalization. Be as specific as you can, and you’ll maximize your flexibility when the changes start flowing.

Part 3: Associate your UI with the palette

Now you can match up your UI with their assigned color. You can see exactly which UI gets which color, and adjust at your leisure. Fabulous.

The whole ColorUtil.swift file for Fantasy Movie League, along with FontUtil.swift (which is based on the same concepts) are provided for reference. Please comment on the gists with any feedback/edits/improvements.

Check out Fantasy Movie League for iPhone to see the beautiful, consistent, and flexible realization of Tav Calico’s designs.

— Ben Dalziel, June 2016