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 Apple's new programming language.
It is easy enough to understand why developers take this approach. People learning a new human language tend to look for the patterns and constructs they are already familiar with. While this is a common phase in the learning process, it emphasizes the importance of a carefully chosen learning trajectory. And 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 are 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 are alike. It is 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 are not.
Reference Types & Value Types
While there is nothing inherently wrong with classes and inheritance, Swift implicitly encourages the use of value types (tuples, structures, and enumerations) instead of reference types (classes). The talk from Andy Matuschak I linked to last week is a great introduction to the advantages value types have over reference types.
The Swift Standard Library also embraces value types. Strings, arrays, and dictionaries, for example, are value types in Swift. This is very different from their Foundation counterparts,
Even though structures and enumerations in Swift are more powerful than their Objective-C counterparts, they don't support inheritance. This lack 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.
The lack of inheritance isn't a problem, though. 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.
That said, classes and inheritance remain important in Swift. They are 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 is equally important to understand the ideas that power Swift and how you can use them in your projects.
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 is 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.
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. 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 is not surprising. The Swift community is still exploring the language, finding out what is 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 instead of 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 is built on, and learn from others.