Attributed String in Swift: the right way

How we can make Cocoa a little less verbose and a little more type safe.

When I’ve started working with Cocoa in later in 2001 I was coming from some experience in Java and a little less of pure C. Cocoa was simply amazing (check out this cool old article from Ars Technica) and the difference with the old Mac Toolbox was huge.
A brave new world was coming and I was pretty exciting of all opportunities which a complete full-featured framework like that could offer to me.

Lots of years are passed since these days, the old NeXT heritage was taken from iOS with UIKit and we lived the mobile revolution also and especially thanks to a complete solution which really helped to create an fertile environment for what we call The App Economy (which, of course, was started on macOS).

With Swift it was like stepping back in time and live the same experience another time; even thanks to this new opportunity, UIKit (and to a lesser extent AppKit) is experiencing a smooth transition to a new life (while my dream is all about a new rewritten framework, I can understand the reason behind the choice of a smooth transition of the Foundation inside the Swift Standard Library).
So, while we’re still fighting with this transition we can make our life easier anyway.

NSAttributedString is one of the things I’ve started to hate in a post-Swift world; creating, combining and applying styles to a string, then render it it’s not a difficult task, but it’s boring, verbose and so damn inelegant.
It’s like playing withAuto Layout via code until not so long ago; we can deserve a better experience, especially now we are using Swift: we can make it type-safe, easy and coincise to use.

So, starting from this experience I’ve created a small library, called SwiftRichString (an original name, don’t you think so?).

Type Safety

The first issue I wanted to solve is regards type-safe; Swift implements type safety, which basically means that you can’t use a variable inappropriately for the terms of its type; letting the development environment enforce type safety is the safest way of handling these problems.
NSAttributedStrings uses NSDictionary to set attributes for text; attributes identifiers (as strings) are passed along with their values.
Like that:

In order to make it safer I’ve introduced the concept of Style. You can create a Style with a name (we will discuss about it later) and assign attributes using a traditional creational pattern:

Even font attribute is type safe; you can create a UIFont object in a type-safe manner by specifing one of the fonts which iOS made available. FontAttribute can also be extended and you can add your own font names (or if you are lazy you can instantiate a font in an old fashion way by specifing a literal). By looking inside the library you will found some other special structures like StrikeAttribute, ShadowAttribute or UnderlineAttribute; all of them are used to make things cleaner and faster to use (take a look at the doc for a complete list).

The ideal scenario for Style is to create a set of styles you will use along your code of your next application.

There is only one special Style which is called .default. Default style is applied in first place regardeless the order in which it’s passed to styles parameter of a functions. This ensure you can have a base common style for your string and add one or more attributes over it easily.

If you don’t need to use tagged string in your code you can create Style objects without giving to them a name; simply use it inside set() functions.

Painless attributed string creation and management

Creating NSAttributedString, combine them and apply style is tedious and verbose; tons of boring code to make a pretty easy task.
Let me show to you a very simple example.

Article continues on my block.
Click here to continue reading!