1 Learn Swift With an Open Mind

Developers making the switch from Objective-C to Swift tend to translate Objective-C into Swift. They take what they know about Cocoa development and apply it to Swift. Unfortunately, this often results in frustration and sometimes even an aversion towards the Swift language.

It’s easy enough to understand why developers take this approach. People learning a new spoken language tend to look for the patterns and constructs they’re already familiar with. While this is a common phase in the learning process, it emphasizes the importance of a carefully chosen learning trajectory. The same applies to picking up a new programming language.

Developers new to Swift often take these commonalities to think that Swift and Objective-C are very similar while they’re not.

Because Swift is so different from Objective-C, you need to take a step backward. You need to unlearn what you know about Objective-C and start with a clean slate and an open mind. Swift and Objective-C differ more than they’re alike. It’s true that a Swift application runs in the Objective-C runtime and that the languages are interoperable, they understand one another. But developers new to Swift often take these commonalities to think that Swift and Objective-C are very similar while they’re not.

Reference Types and Value Types

While there’s nothing inherently wrong with classes and inheritance, Swift implicitly encourages the use of value types (tuples, structures, and enumerations) instead of reference types (classes). Several months ago, I came across a talk from Andy Matuschak about this topic. It’s a great introduction to the advantages value types have over reference types.

The Swift Standard Library also embraces value types. Strings, arrays, dictionaries, and sets, for example, are value types in Swift. This is very different from their Foundation counterparts, NSString, NSArray, NSDictionary, and NSSet.

Protocol-Oriented Programming

Even though structures and enumerations in Swift are more powerful than their Objective-C counterparts, they don’t support inheritance. This is often seen as a missing feature and scares many developers away from value types. Developers new to Swift and accustomed to object-oriented programming look for inheritance and find it in classes, that is, reference types.

Earlier in the book, I emphasize that the lack of inheritance isn’t a problem. Protocols and value types are a potent combination, maybe even more so than reference types and inheritance.

Apple emphasizes that protocol-oriented programming is a pattern developers should embrace in Swift. I encourage you to watch Protocol-Oriented Programming in Swift to understand what it is and how you can apply it in Swift. Dave Abrahams does a tremendous job explaining why protocol-oriented programming is a natural fit for Swift.

Classes and inheritance remain important in Swift. They’re not the enemy. The Cocoa frameworks are for the most part powered by Objective-C and that means classes and inheritance are here to stay, at least for the foreseeable future.

As a Cocoa developer, you continue to use classes and create subclasses. But it’s equally important to understand the ideas that power Swift and how you can use them in your projects. In his presentation, Dave repeatedly draws attention to Swift being a protocol-oriented language.

Type Safety

Type safety is a cornerstone of the Swift programming language. As a developer, Swift expects you to be clear about the types of the variables and constants you use. The advantage is that common mistakes, such as passing a value of the wrong type to a method, can be caught by the compiler.

Developers coming from Objective-C often struggle with Swift’s strict type safety rules. This ties in with another concept of Swift, optionals. Optionals are seen as an obstacle, an unavoidable side effect of Swift’s type safety. What happened to sending messages to nil in Objective-C? What’s wrong with that?

Optionals may indeed feel as obstacles when you first start experimenting with Swift. As time passes and you become more familiar with the language in its entirety, the pieces of the puzzle start to come together and you come to appreciate optionals for what they represent and the problem they solve. In combination with optional binding and optional chaining, optionals start to fit into that proverbial puzzle.

I agree that optionals can feel clunky if you’re interacting with an Objective-C API that wasn’t built with Swift or optionals in mind. But I wouldn’t want to use Swift without them. Optionals are such a nice feature of Swift and I’ve come to appreciate them. In fact, every time I take a trip down memory lane when I need to fix a bug in Objective-C, I miss them. Optionals clearly express what’s happening.

If you’re still not sure about optionals, then I suggest you read the chapter about optionals in this book. Give them the benefit of the doubt for now. Use them for a few weeks, avoid the exclamation mark, and see how you feel about them in a month.

Best Practices

The more you read about Swift and the longer you spend time in the Swift community, the more you realize that Swift is still a very young language, especially if you compare the language with C and Objective-C. A common problem developers face is the lack of best practices. They look for strategies to solve common problems and struggle to find them. Best practices are slowly taking form as more people use the language in real-world scenarios.

This isn’t surprising. The Swift community is still exploring the language, finding out what’s possible and how things can or should be done. The language is still developing at a rapid pace and the open sourcing of the language is another component that drives this swift evolution.

Several best practices are slowly taking shape, such as the adoption of protocol-oriented programming, the value of immutability, and the use of value types over reference types.

Forget What You Know

My advice is to approach Swift with an open mind. Try to forget what you know. What you know has value, but it may slow you down or it may lead to frustration. Explore the language, become familiar with the foundations it’s built on, and learn from others.