Optionals also work for unknown selectors. Say you want to call a method on a Objective-C object, but you didn't know whether it existed or not, you can do that the following way:

// 1.
object.secredMethod?(param)
// 2.
if let obj = object.secretFunction(param) {
   // do things with obj
}

The sophisticated Pattern Matching in Swift's switch construct is also a good alternative to unwrap Optionals:

var result: String? = secretFunction()
switch result {
case .None:
    print("is nothing")
case let a:
    print("is a value")
}

With Swift 2.0, this can also be expressed more cleanly:

var result: String? = secretFunction()
switch result {
case nil:
    print("is nothing")
case let a?:
    print("is a value")
}

While this may seem to offer little benefit, the advanced pattern matching syntax in Swift allow you to define far more detailed cases that test for much more than just nil or not nil.

// A number of very stub methods 
func secretFunction1() -> Int? {return 0}
func secretFunction2() -> [String] {return ["a", "b"]}
func secretFunction3() -> Bool {return true}

switch (secretFunction1(), secretFunction2(), secretFunction3()) {
case (nil, let col, true):
    print("case1")
case (let num?, let col, true) where num > 1:
    print("case2")
default: ()
    print ("default")
}

Try to figure out what the above will finally print. We're matching for the return results of three function calls at once. This would quickly become a cumbersome list of if and else blocks if it weren't for Optionals and switch.

As already explained above, Objective-C always offers you to use nil instead of an actual object. This, of course, means that every Cocoa or UIKit method that returns a NSObject subclass will need to be typed as optional in Swift. This means that whenever you interact with UIKit or Cocoa libraries, you will need to unwrap your values:

if let u = c.componentsSeperatedByString("a") {
}
if let u = c.firstItem() {
}

This is also necessary for NSDictionary access:

let u: NSDictionary = magicMethod()
// image u as having the following structure
// Objc Syntax: @{@"a-key": @[@1, @2, @3]}
// Swift Syntax: ["a-key": [1, 2, 3]]
u["a-key"].count // u["a-key"] returns an optional, this fails.
u["a-key"]!.count // this works fine 
// *Until* a-key does not exist in your NSDictionary, then it will crash.
// So the better way is
if let ux = u["a-key"] {
}

However, it is much more important here to use the let ux = ... syntax, until you're really, really sure, that the NSDictionary will contain the required key. In general, if your code contains ! outside of IBOutlet bindings, there may be a better way to do this. In this case, Swift's combined let statements.

let example = ["a": ["b": ["c": 1]]]
if let a = example["a"],
    b = a["b"],
    c = b["c"] where c > 0 {
	print(c)
}

Since let can access previous let's contents, we can access b from a etc. We can also add a where block for any of the let-bound values. This makes it particularly easy to express the desired requirements for accessing a value.

The alternative to the list of let statements from the previous section would be optional chaining. Here, Swift will take the return value of an optional operation, and if it is non-nil, will process the next operation on the value, and return the optional result of this again.

By adding ? in between each call / access, Swift will automatically unwrap if there is a value, or stop the chain as soon as any one evaluates to nil. For our previous example, that would look like the following:

example["a"]?["b"]?["c"]

Consider the following code:

func example() -> Int? {return 10}
if let value = example() {
    storeInDatabase(value * 2)
}

If we break down the logic, what we're really trying to achieve, were it not for optionals, is the following:

storeInDatabase(example() * 10)

Optionals are still very useful here, as they prevent us from the danger of multiplying nil with 10 and trying to store that in the database. But still, we have to admit that the optionals code looks more convoluted. As you can imagine, there's a solution to this, of course.

Optionals offer an implementation of the map function which will call the .Some value of an optional with a supplied closure iff the optional has a value.

// The following will call print with 5, i.e. will print 5
let px: Int? = 5
px.map { print($0) }

// The following won't call print
let px: Int? = nil
px.map { print($0) }

This lets us rewrite our example from above in terms of map as follows:

example().map { storeInDatabase($0 * 2) }

Note: I've kept the following in since it still explains a nice way to match multiple dictionary entries, however the intended use case for matching JSON values is better served by using one of the modern JSON Swift libraries like SwityJSON or Argo.

Say you're receiving data from a json frontend. The data converts to a NSDictionary, and then you want to process it. However, this being json and a mystic webservice, you don't know for sure if the dictionary contains all the keys. So the be really sure, you'd like to test for all keys in the dictionary. It is not immediately clear how to do that, but @_nickmain on Twitter (and subsequently Wes Campaigne) came up with a really good solution for this. They're utilizing the switch statement with a tuple to test for multiple entries.

let j2 = ["a": 1, "b": 2, "c": 3]
switch (j2["a"], j2["b"], j2["c"]) {
case (let a?, nil, nil):
    print("got \(a)")
case (let a?, let b?, .None) where b is String:
    print("got \(a), \(b)")
case (let a?, let b?, let c?):
    print("got \(a), \(b), \(c)")
default:
    print("got none")
}

This prints "got none" because b is not of type string. If the dictionary would be ["b": "45"] then, it would print [got 5, "45"]. This is a really nice solution, because it allows you to test different cases based on the information available in the dictionary. What's more, you can also use the where operator to test for advanced properties of your values. I.e. you can test whether they're of class String, or whether they're above a certain value (i.e. > 5).

If this looks tempting, have a look at my tutorial on using switch statements in Swift, particularly for people who're mostly accustomed to the way it works in C / Objective-C and not the much more powerful switch statements like in Swift, Scala, Erlang, or Clojure's core.match.