Stylish UI Extensions (UIKit-CSS)

Conor Brady
2 min readApr 26, 2017

--

This post carries on from the mutate operator. Which, among other things, laid out a way of applying mutation blocks to UIKit classes. We made use of this in our codebase, but soon started to realise we had repeated mutation blocks all over the place.

This was our new world:

We need to do better, what about:

Don’t you use storyboards and Interface builder?

Let’s extend UIFont.

This gives us our font library. Back to our original example:

Much better, but we still have repeated code. Let’s extend UILabel.

(With some bonus line wrapping functionality)

We’re left with two identical lines. This seems like we have more to do, but this is the nature of style-extensions.

We must create an interface that balances:

  • A small API
  • Concise expressivity
  • Flexibility of interface

This was our balancing point. Labels can vary so much outside of our four fonts and colour palette.

Adopting these to another codebase will mean different things, it could be dependant the designers involvement, where better light could be shed on the degrees of freedom of labels, headers etc.

War of the buttons

Buttons are another story, they don’t change too much.

For the sake of completeness this is a basically all the style-extensions for buttons. We generally only need stylePrimary(fontSize:_). This gives us a single point of reference so the engineer only needs to call UIButton().stylePrimary(fontSize: 14). The only thing they need to worry about is if they got the font size correct.

What about everything else?

There’s plenty more, this outlines the concept. It’s about raising awareness of a syntactical possibility and seeing where it goes rather than providing a styling library. So let us know what you think.

Any or all of this sound interesting? Join the HubSpot iOS team.

--

--