What I like about Swift

Lately, I have been interviewing again, only this time, being the interviewee, not the interviewer. The experience has been quite interesting, to say the least, and probably deserving its own post, but I would like to focus today in just one aspect of it.

Since I have been working on Swift-only projects almost exclusively since it was publicly released in 2014, one recurring question in every interview has been “what do you like about Swift”?

Now, before digging into what I like about the language, here comes the disclaimer:


This post is not an attempt to enumerate everything that is good with the language. This post is just a list of things I like about the language, things that make me more productive, or that make me write what I regard as better code. YMMV, so please take this only as my reflection on the code I’ve read or written during the last year and a half, and what I liked about it.

So, in no particular order, this is what I like about Swift:

1. Safety

This is a very broad topic, so I am going to break it down into smaller chunks.

Let’s begin with…

1.1. Swift code crashes very rarely

Maybe it is not because it is Swift, maybe it is because I am actually getting better at my craft after so many years, but I have the feeling that this one should be pinned on the language, not me.

Judicious use of optionals, specially as return values of integrations with remote APIs, in combination with judicious implementations of the Null Object pattern here and there make dealing with unexpected data almost pleasant. Almost.

But the point is: I have found that using optionals, when it makes sense, makes the code safer, and makes apps very difficult to crash. Which I assume is what the language designers had in mind.

1.2. The Swift compiler enforces safety

I know we all come from a background where swizzling and typing stuff as id where considered acceptable, when not good practices. And I am the first one that, sometimes, has wished that the Swift compiler got off my back, but, in the long term, I have found strict type safety to be one of the best features of the language, hands down.

Having someone telling you to not do something stupid before you attempt to do it is priceless. Seriously, I don’t consider strong typing a limitation, but the opposite.

2. Swift code is more modular

Again, this might very well be case that I have started to actually understand what all this Software Engineering thing is about. But I tend to believe that Swift actually helps build simple, decoupled code.

Extensions, and protocol extension in particular, make easier to rely on composition instead of inheritance when it comes to modelling abstractions. That makes the code way less rigid, and therefore way more modular.

I find very easy to build abstractions not by looking at what things are, but by thinking about how things behave. And I find behaviour way easier to abstract, manipulate and compose.

Modelling behaviours behind protocols, and providing default implementations of those behaviours in extensions has made my life way easier.

3. Richer type semantics

Swift provides classes, but also structs and enumerations. it could be argued that Objective-C also provided structs and enumerations, but structs where a pain in the rear, and enumerations where just sequences of integers.

Now, we can attach behaviour to structs and enumerations. We can make structs and enumerations implement protocols, so we can provide default implementations of those protocols through extensions. Oh, and enumerations can have associated values. I seem to like enumerations a lot, apparently.

A class and a struct look similar but they are not similar at all: one is passed by reference, the other is passed by value. Again, that will make the code safer in many situations.

And did I mention generics? I love generics. Generics are awesome. How could we live without generics for so long? I only wish protocol’s associated types where not that weird. I guess you can’t have it all…

4. Conciseness and simplicity

Swift code looks concise and to the point. I love how the compiler infers stuff for you, so you don’t need to write an enumeration name to use one of its cases, or how you can call .redColor() without the UIColor in front of it, or declare strongly typed arrays without actually needing to write the type explicitly.

It saves time, yes, but it also removes noise and distraction from the code. And I am looking at you now, square brackets. And I am also looking at you now, header files.

5. Access modifiers

In Objective-C, everything was either completely public or completely private (of course, having in mind that nothing was actually completely private)

Now, we can organise the code in modules. And we get to choose if we want something to be public and visible by everyone, or only visible by the module it belongs to, or be completely private and accessible only within the file it is declared in.

That provides an extra level of modularity and safety. Because, remember, encapsulation is good, and encapsulation is only enforced by privacy. And privacy is good.

6. Swift code is cleaner

This one is hard to blame on Swift only. After all, as the old adage says, you can write FORTRAN in any language. In this case, any programmer can write tangled, imperative code in any language. And I have been guilty of that many times. But I have found that all the features enumerated previously provide, as a final result, better code. Code that is easier to read, easier to understand, cleaner, more modular, and therefore easier to maintain and extend.

Which is what this whole “engineering” thing is all about, isn’t it?

What I don’t like about Swift

Xcode can not refactor Swift code. And that drives me nuts.

Final words

As you might have noticed if you have reached this far, there is a lot I like in Swift, and not too much I dislike.

In my experience, Swift code is clean and modular. When I write Swift, I usually find myself in a SOLID-compliant mode.

In one line, what I like about Swift is that it makes writing clean and maintainable code easier, and fun.

Leave a Reply

Your email address will not be published. Required fields are marked *