Think & Build


From Objective-C to Swift: thoughts and hints

In this article I want to share with you some of the thoughts I had along the way during my transition from Objective-C to Swift. I’ll try to give you hints and I’ll discuss the main pitfalls, trying to compare, when possible, the different approaches of these two languages. So without further ado let’s dive into the core of the article!

NOTE: this article has been written referring to Beta 2 of Xcode 6.

Single file vs Interface-Implementation files

A first big change that is worth mentioning is the dismissal of the interface.h/implementation.m structure.
I have to admit that I’m a strong supporter of that model; Obtaining and sharing information about a class just via the interface file is safe and quick.

In Swift interface and implementation aren’t split in two files. We just implement our class (and at the time of writing it is not even possible to add visibility modifiers).

There are some caveats that we can use if we really are unable to tolerate this huge change:

The first is obvious: Using common sense.
We can easily enhance readability of our classes with good documentation. For example, we can move the elements we want to be “public” at the top of our file, maybe using an extension just to separate public and private areas.
Another really common choice is to prefix private methods and variables with an underscore “_”.

Here is a short example mixing the two:

// Public
extension DataReader {
    var data { }
    func readData(){
        var data = _webserviceInteraction()

// Private implementation
class DataReader: NSObject {
    let _wsURL = NSURL(string: "")
    func _webserviceInteraction()->String{
        // ...

Although we can’t modify the visibility of our class elements, we can try to make accessing some of them “more difficult”.
An exotic solution that partially hides private area (at least to the autocomplete) can be achieved using a nested class, here’s an example:

import UIKit

class DataReader: NSObject {
    // Public ***********************
    var data:String?{
        get{return private.internalData}
        private = DataReaderPrivate()

    func publicFunction(){

    // Private **********************
    var private:DataReaderPrivate
    class DataReaderPrivate {
        var internalData:String?
            internalData = "Private data!"
        func privateFunc (){}

We put private implementations into the private constant instance and we use the “regular” class implementation just as public interface. The private elements are not really hidden but to access them we have to go through the “private” constant.

let reader = DataReader()

The question is: is this weird pattern worth the final goal of partially hiding the private elements?
My suggestion is to wait for visibility modifiers (Apple is working on it) and in the meanwhile just use good documentation with or without extensions.

Constants and Variables

In Objective-C I’ve rarely used the const keyword, even when I knew that some data would never change (OK… shame on me). With Swift, Apple suggest developers to give some more thought to the choice of using a constant (let) instead of a variable (var). So just keep an eye on it and try to figure out the effective role of your variables. You’ll end up using more constants than you’d expect.

Write only what needs to be written

Look at these 2 rows of code and find the differences:

let wsURL:NSURL = NSURL(string:"");
let wsURL = NSURL(string:"") 

During the first 2 weeks of training with Swift I forced myself to remove semicolons from the end of each line of my code. My life is better now (and now I forget to add semicolons in Objective-C :| )

Type inference is the ability to assign a type to a variable, inferring it directly from its definition. This is another convenience that turns out to be a bit hard to embrace, when coming from a verbose language like Objective-C.
We should try to use consistent methods naming, otherwise it would be difficult for another developer (and for you) to guess the type inferred by an unfortunate naming choice:

let a = something() 

A more reasonable name helps us:

let a = anInt() 

Another big change is the use of parenthesis. They are no longer required.

if (a > b){}
if a > b {}

But remember, what we write between the parenthesis is evaluated as an expression and we are not always allowed to write it that way. In variable binding, for example, we can’t use parenthesis:

if (let x = data){} // Error! 
if let x = data {} // OK!

We are not required to adopt type inference or to remove semicolons and parentheses but we can consider these choices as the suggested ways to write code in Swift. We’ll end up enhancing readability and saving some keyboard typing.


How many times, working with functions that return “a value” or “nothing”, did you wonder what the best way to define “nothing” was? I’ve used NSNotFound, -1, 0, custom return values…
Thanks to Optionals we now have the “nothing-value” completely defined, we just need to add a question mark after the data type.

We can write:

class Person{
    let name:String
    let car:Car? // Optional value
    init(name:String){ = name


var Mark = Person(name:"mark")

// use optional binding 
if let car = {

// unwrap the value

In this example the relation “Person has a Car” is defined by an Optional. It means that the car property can be nil, a Person could not have a car.
Then we access this value using optional binding (if let car = ) or using unwrap (car?).

If we don’t define a property as optional we are required to set a value for that property or the compiler will soon complain.
Our last chance to define a non optional property value is within an initialiser.
So we are required to determine how the class properties will interact with the rest of the class and how they will behave during class instances existence.
These improvements completely change the way we conceive our classes.

Optionals unwrapping

If you find it difficult to work with optionals because you can’t understand why the compiler asks you to unwrap a value before using it…

…I suggest you to think about an Optional as a struct (it is a struct, so it shouldn’t be too difficult :P ) that doesn’t contain your value directly, but adds a layer around it (wrap). If the internal value is defined, you remove the layer (unwrap) and you get the wanted value, otherwise you get nil. BOOM.
Forcing the unwrap through the “!” sign is just a way to remove the layer without caring about the internal value. You “risk” trying to access a value behind the layer. If this value is nil the application just crashes.

Delegate pattern

After years spent coding with Objective-C and Cocoa we are delegate pattern addicted.
Fear not! We still adopt that pattern the same way we were used to. Here’s a super simple example of a delegate:

@objc protocol DataReaderDelegate{
    @optional func DataWillRead()
    func DataDidRead()

class DataReader: NSObject {
    var delegate:DataReaderDelegate?
    var data:NSData?

    func buildData(){
        delegate?.DataWillRead?() // Optional method check
        data = _createData()
        delegate?.DataDidRead() 	  // Required method check

We substitute the check for delegate existence and the use of respondToSelector with an elegant optional chaining.


Note that we have to prefix protocol with the @obj keyword because we used @optional. By the way, the compiler will warn us with a clear message in case we forgot it.

To implement this delegate we implement the protocol into another class and we assign it as we were used to with Objective-C:

class ViewController: UIViewController, DataReaderDelegate {
    override func viewDidLoad() {
        let reader = DataReader()
        reader.delegate = self

    func DataWillRead() {...}
    func DataDidRead() {...}

Target Action Pattern

Another common pattern that we still use in Swift is the target-action and even in this case we implement it the same way we did in Objective-C.

class ViewController: UIViewController {
    @IBOutlet var button:UIButton
    override func viewDidLoad() {
        button.addTarget(self, action: "buttonPressed:", forControlEvents: UIControlEvents.TouchUpInside)

    func buttonPressed(sender:UIButton){...}

The only real difference is how we define a selector. We just write the method prototype using a String that will be automatically converted in something like:


Singleton pattern

Love it or hate it, the singleton is still one of the most adopted patterns out there.

We can implement it using GDC and dispatch_once or we can just rely on the thread-safe nature of the let keyword.

class DataReader: NSObject {
    class var sharedReader:DataReader {
        struct Static{
            static let _instance = DataReader()
        return Static._instance

Let’s have a quick look at this code.
1. SharedReader is a static compound property (we can substitute this implementation with a function)
2. Static (not compound) properties are not yet allowed into a class implementation. So thanks to nested types we add a nested struct to the class.
A struct supports Static properties, so we just add the static property here.
3. The _instance property is a constant. It can’t be overridden with another value and it is thread-safe.

We can refer to the singleton instance of DataReader using:


Struct and Enum

In Swift, struct and enums have a lot of features that you hardly find implemented in other languages.

They support methods:

struct User{
    // Struct properties
    let name:String
    let ID:Int
    // Method!!!
    func sayHello(){
        println("I'm " + + " my ID is: \(self.ID)")

let pamela = User(name: "Pamela", ID: 123456)

As you can see the struct uses an initializer, that in this case is automatically created by Swift (we could add other custom implementations).

The enum syntax is a bit different by the syntax we are used to.
It defines its cases using the keyword case:

enum Fruit { 
  case orange
  case apple

Enum is not limited to int values:

enum Fruit:String { 
  case .orange = "Orange"
  case .apple = "Apple"

and we can build an enum with a more complex behaviour:

enum Fruit{
    // Available Fruits
    case orange
    case apple
    // Nested type
    struct Vitamin{
        var name:String
    // Compound property
    var mainVitamin:Vitamin {
    switch self{
    case .orange:
        return Vitamin(name: "C")
    case .apple:
        return Vitamin(name: "B")

let Apple =
var Vitamin = Apple.mainVitamin

In the previous code we added a nested type (Vitamin) and a compound property (mainVitamin) that initializes elements for that struct depending on the enum value. Mind blowing… isn’t?

Mutable and Immutable (and fixed bug!)

With Objective-C we are used to immutable and mutable versions of whatever class. Some examples? NSArray and NSDictionary.
With Swift we don’t need different data types anymore, we just leverage on constant or variable definition.
A variable Array is mutable while with a constant Array we can’t change its stored values. So just keep in mind the rule “let = immutable. var = mutable” (Fixed Bug: before Beta 3 you could modify a let Array).

Blocks vs Closures

I love the syntax for Blocks, it’s so clear and easy to remember!


By the way, after some years of development with Cocoa, we get used to this syntax and sometimes I prefer to substitute easy delegation tasks with blocks. They are ingenious, quick and totally useful.
The Swift counterparts of Blocks are Closures. The power behind Closures is extreme and Apple did a great job trying to simplify the way we write them.
The example on the official Swift documentation leaves me speechless.
It starts from this definition

reversed = sort(names, { (s1: String, s2: String) -> Bool in
    return s1 > s2

and it refactors it to:

reversed = sort(names, >) 

So we have different ways to implement a Closure thanks to type inference, shorthand arguments ($0, $1) and direct operator functions (>).
In this article I’m not going through the Closure syntax but I want to spend some words on capture values within a Closure.
In Objective-C we define a variable as __block when we intend to modify its value trough a Block. Using Closures this becomes unnecessary.
We can access and modify any value of the surrounding scope. In fact Closures are clever enough to capture external elements that are used into the Closure. An element is captured as copy or as reference. If the Closure modifies the value of the element it creates a reference, if not, it creates a copy.

If a Closure refers to the instance that contains/uses the Closure itself we could run into a strong reference cycle

Let’s check this example:

class Person{
    var age:Int = 0
    @lazy var agePotion: (Int) -> Void = {
        (agex:Int)->Void in
            self.age += agex
    func modifyAge(agex:Int, modifier:(Int)->Void){

var Mark:Person? = Person()
Mark!.modifyAge(50, Mark!.agePotion)
Mark = nil // Memory Leak

The agePotion closure (damn D&D!) uses self, keeping a strong reference to the current instance. At the same time that instance keeps a reference to the Closure… BOOM… strong reference cycle!

To avoid this problem we use a Capture List. This list associates a weak or unowned reference to the instance that we want to use into the Closure. The syntax is really simple, just add [unowned/strong self] before the Closure definition and the instance will get an unowned/weak reference instead of a strong one.

@lazy var agePotion: (Int) -> Void = {
     [unowned self](agex:Int)->Void in
         self.age += agex

Unowned and weak reference

We already know how the weak reference works in Objective-C. It works the same way in Swift, no changes here.
So what about the unowned reference? I’ve really appreciated the introduction of this keyword because it’s a good hint to define relations between classes.

Let’s describe a simple relation between a Person and its BankAccount:
1. A Person can have a BankAccount (optional)
2. A Bank account should belong to a Person (required)

We can describe this relation with code: 
class Person{
    let name:String
    let account:BankAccount!
    init(name:String){ = name
        self.account = BankAccount(owner: self)

class BankAccount{
    let owner:Person
        self.owner = owner

These relationships are going to create a reference cycle. The first solution would be adding a weak reference to the “BankAccount.owner” property. However using an unowned reference we are defining another useful constraint: the property must always have a value, it can’t be nil (we have satisfied the point 2 of the previous list this way).

There is really nothing more to say about the unowned reference. It works exactly like a weak reference without incrementing the counter for the reference it points to, but ensuring a value different from nil.

Final thoughts

I have to admit: sometimes I still run into compiler errors and end up looking at them in silence, just wondering: “WAT?”

The more I work with Swift though, the clearer it becomes it’s worth every hour I’m spending on experiments and learning. There are a lot of interesting changes from Objective-C and things that didn’t exist before that make me want to practice more and get completely comfortable with it.

It’s a welcome breath of fresh air in iOS / OSX development and I’m sure you’re going to love it too!