I’d like to share my approach to flexible UI components styling in Swift. Some of the advantages are that it can be used for white-label product development and allows for clear styling definition in one place.

Initially, my goal was to present it, but then I also wrote the The way to solution chapter where I described the process of coming up with the solution. If you’re only interested in what the approach is, feel free to skip the chapter.

Problem

Sooner or later most of the apps have to prepare some kind of form. Whether it’s for login, registration or anything other specific to the project.

That part was no different for the application I was working on, where I had to prepare quite flexible component for user input. There were various elements that together created a single input view. For instance its title label, text input field itself and few others.
The requirement was also to create it in such way that it could be potentially used by other client’s applications.

Troublesome part besides for various design requirements etc. is styling of such component. It had to provide a validation interface, an input guide view, that explains to the user what the field should contain and provide feedback about the input once user finished typing.

So there were various states that the component could be in and each of them had to be styled distinctly.

How UIKit does it

Being an iOS developer you’re probably already familiar with the good old UIButton. The control is not that different from the custom input control in terms of styling. It’s just that it has different states.

So how does one normally style their buttons?
Probably by using methods like setImage(_:, for:) and setTitleColor(_:, for:) etc.

The problem I see in this approach is that simple button has much more functionality then it needs. Besides for providing the core touch support and state management, it also has to store all variations of its customisable properties and automatically apply them on state change.

Such approach to styling requires more work from the one who implemented it. For instance, the button has imageEdgeInsets, and there’s no corresponding method setImageInsets(_:, for state:). So either the author should add such method, or the user needs to somehow update this property manually.
Doing it manually is quite troublesome because UIKit is not KVO compliant, so simply observing the state property won’t work. There’s no UIControlEvents case that would notify about state change either. The most reliable approach would be probably to subclass the UIButton class, override state related properties and get notified of the change.

I think this could be improved by leaving the styling out of the control capabilities.

The way to solution

While writing the component I wanted to focus on its actual requirements, without making my own logic for its state-based styling. That way I wouldn’t be enforcing any particular approach on other client apps that would use it and managed to keep it at lower complexity level.

So what I did was, I prepared a set of publicly visible properties, a state property and defined a protocol to allow a delegate object to react to state changes.

Then I moved to preparing a way to style it.

First of all, whenever I have to prepare any API I like to start off from the perspective of its user. Like, mock its usage. So that instead of limiting myself to any particular solution or idea that I had, I try to play with how I would use it and only then implement it.

Of the things I wanted to do was to make the approach somewhat generic. My goal wasn’t to cover all possible cases. I wanted to come up with a good enough solution that maybe could be used for other scenarios too.

I didn’t want to work directly with the component so I started a new project and defined a label that had some associated states.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


class StateLabel: UILabel {

    enum State: Int {

        case idle
        case valid
        case invalid
        
        static let end: Int = State.invalid.rawValue + 1
    }

    var state: State = .idle
}

Then I prepared a basic view controller with the label and a button to change the state of the label.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


class ViewController: UIViewController {

    @IBOutlet var stateLabel: StateLabel! {
        didSet {
            applyStyle()
        }
    }

    @IBAction func onStateChangeAction(_ sender: UIButton) {
        // move to following state in loop
        stateLabel.state = StateLabel.State(
            rawValue: (stateLabel.state.rawValue + 1) % StateLabel.State.end
        )!

        applyStyle()
    }
    
    func applyStyle() {
        // applying style here
    }
}

The remaining thing was to figure out a way to style it. As it was a white-label application with multiple targets, I thought it’d be cool if I’d be able to decouple style definition from the whole component. The styling was meant to be dependant on the state, so whatever way I’d come up with I knew I’d need to pass the current state and an object I’d like to apply the style to.

Something like that probably:

1
2
3


func applyStyle() { 
    style(stateLabel, for: stateLabel.state)
} 

Then I started thinking about how the style definition could look like.
The most trivial way to do it would be just to check the state and apply styling like so:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


func style(_ label: StateLabel, for state: StateLabel.State) {
    // default properties
    ...
    
    switch state {
    case invalid:
        label.textColor = oneColor 
        label.font = oneFont 
    case .valid:
        label.textColor = otherColor
        label.font = otherFont
    }
}

That would be probably sufficient in trivial cases. The text field though had many customisable style properties and more states, so that wouldn’t be satisfying.
Looking closely at the above example, it’s simple to extract some of the common bits. Specific properties are applied under given state, but it all is assigned to the given object instance. So there’s a lot of label.... = x.

That seemed like a perfect use case for the key paths, I mean, they are meant for things like that! Instead of writing that code manually I could use key paths and store specific values.

So then I was thinking how would style definition look like.
First of all, it should be type safe, so I’ll certainly have to define each of the styled properties one by one, as there’s no way to have various generic types in a collection.
Second, came the styling properties. Some of the states might not be distinct from default styling, some of them may share their style. A way to define such dependance would be to have a default style value and a dictionary to store values for particular states.

Signature of such function could look like that:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


func storeStyle<Subject, Property, State: Hashable>(
    _ subject: ReferenceWritableKeyPath<Subject, Property>,
    values: [State: Property], 
    default: Property
) {}

storeStyle(
    \.textColor,
    values: [
        .invalid: .red,
        .valid: .green
    ],
    default: .black 
)

Once I more or less knew what I wanted the API to look like from the user perspective I started with the implementation.

How I did it

I came up with a dedicated style structure, that allows for style definition using the builder pattern and later its use.
Use of dedicated object with builder pattern not only can allow for a more readable code but also more flexibility in a white-label product.
This way styles can be defined independently.

That’s what the end result of style definition can look like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


let styleDefinition = StyleDefinition<StateLabel, StateLabel.State>
    .styling(
        \.textColor,
        [
            .valid: .green,
            .invalid: .red
        ],
        default: .black
    ).styling(
        \.font,
        [
            .valid: .systemFont(ofSize: 15),
            .invalid: .systemFont(ofSize: 25)
        ],
        default: .systemFont(ofSize: 10)
    ).styling(
        \.textAlignment,
        [
            .valid: .left
        ],
        default: .center
    )

And here’s a final applyStyle function:

1
2
3


func applyStyle() {
    styleDefinition.apply(for: stateLabel.state, to: stateLabel)
}

If there was a need for highly customisable components the app could even only define a very basic style and possibly overwrite it with one coming from server.
Specific styles can be defined in per-target files, which could simplify amount of code needed to write a component for multiple targets.
In the end I think such, or similar solution, could bring more flexibility to application styling.

This approach is one of many ways one could leverage key paths, they are a fantastic language construct and using them is so much fun. I can’t wait to see more dynamic, type-safe mechanisms in Swift!

Here you can find a demo project. In addition, it has a base style definition that doesn’t require a state and could be used for applying common styling to various views.
There are many ways the approach could be extended. For instance, one could define a way to initialise state based styling with the basic one, so that there’s no need to apply them separately.

Thanks for reading! If you’ve got any questions, comments, or general feedback, you can find all my social links at the bottom of the page.

I’d also like to thank @pknuth, for sharing with me an idea of documenting the approach.
As I made the implementation, I wasn’t thinking about sharing it. Paweł pointed out, though that not many iOS developers are aware of, know how to use key paths. Hopefully, after reading this article and looking at the demo project, some will see the benefit of using them.

Components styling using KeyPath expressions - a way of API design

Contents

Problem

How UIKit does it

The way to solution

How I did it