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.

This extension is pretty nice, I thought it deserved a post. Here’s a snippet of it in use:

It’s just tidy, it removes all the cell identifier stuff as we rarely need two identifiers for the same type of cell. If you do, you can still use the old version.

Also check out this post if you are curious what <== is.

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

Here’s the implementation:

Below, I’ll list examples of its use; with hopeful evidence of of its merit.

What?

We initialise Foo, but it’s not really initialised since we immediately want to assign bar. For some reason, Foo doesn’t accept bar in the constructor, so we end up with a create-assign pattern.

With <== , we arrive at a better expression of our intent and we avoid assigning invalid states of foo.

But, what about the real world?

A pretty typical UIKit interaction:

After we apply <==:

This creates a single assignment and clear initialisation block. The blocks encourage the code to be grouped logically, with a strong syntactic contract.

If we mutated these objects outside their blocks, it would stand out. So we get reassurances that we have the full picture of any objects configuration and mutations at a glance. Even the layer configuration for the button’s drop shadow falls into place nicely.

But wait, theres more

Since we have customisable single assignment, we can apply it at the class level:

This constrains the creation to constant, class level information; factoring out anything that depends on parameters to the init call.

It also removes order dependency, so any order dependant mutations can be performed in the initialiser itself, reducing the noise surrounding interdependent, order specific instructions.

It all feels much more declarative. Like UI code should feel.

I need more convincing…

At line 2, we don’t need v1 and v2 but we’re just using them as temporary variables so we can assign them titles, before passing them as arguments to the UITabBarController constructor. This is mostly how this pattern plays out in the wild.

Line 11 feels a lot better. We avoid polluting the symbol table with variables that are unnecessary; with the scope of use of the view controllers clearly indicated by the context of their creation and use.

This is more readable, as everything appears in context to it creation, modification and purpose. Rather than splitting that across three lines.

I’m sold

Try it out, it’s only 7 lines. It’s made our code much more easy to read and maintain. You’ll be glad of it.

Next thing, you can start making style-extensions.

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