Swift Ninja Logo

Swift 2.3 Update

Swift Language LogoSwift 2.3 was released on June 12, 2016. While Swift 3 was announced at WWDC the next day, it still isn’t in its final form, so I won’t cover those changes yet. I don’t want to have to be confusing and backtrack if things change in the beta.

The good news for us is that Swift 2.3 doesn’t really have any changes in it that we need to be concerned with in regards to the code that we’ve been writing. The notes from the official Swift Blog say:

“Swift 2.3 is a minor update from Swift 2.2.1. The primary difference between Swift 2.2.1 and Swift 2.3 is that it is intended to be paired with Apple’s macOS 10.12, iOS 10, watchOS 3, and tvOS 10 SDKs. It also updates the underlying LLVM and Clang versions to match with those in the Swift 3 compiler.”

That just means that this release is setting us up to be able to use the latest and greatest of Apple’s operating systems across their four platforms (mobile, desktop, tv, and watch).

Lesson 020 – POSTing to a REST API


Back in Lesson 015, we took a look at what you need to do in order to make HTTP Requests against a REST API. In that example, we only made a GET request, which limited us to a “read-only” interaction with a server. In the real world, we would need to send data back to the server. Whether that is to log in, save a picture to an online album, or post a status update, we are going to move beyond “read-only” pretty quickly.

Good News

The good news is that we can leverage almost everything that we did back in Lesson 015. Today, we’ll be using a free tester REST API located at http://reqres.in/. When you POST to http://reqres.in/api/users, it will add an id and timestamp field and just echo back any data you posted to it. So, let’s take a look at how we POST.

There are a few differences right off the bat. First, we added these lines

The first line just sets the code to make the request as a POST instead of a GET. GET is the default, which is why we didn’t specify this previously. Next, declare a body for our request. Whenever you submit a form on a normal website, that data will often be transmitted in exactly the format you see here. We have a key=value syntax with ampersands (&) separating each term. Next we encode that string so it can be understood and assign it to the body of the request.

After that, everything is exactly the same, with the exception that I’m pulling different keys out of the resulting JSON array. That should make sense, given that we are hitting a different endpoint. Remember that this code is all on GitHub, so you can absolutely pull it down. Add values to the body and then try to pull them back out again. Get familiar with how this “song and dance” goes. For example, when I make this request, I get the following result

A Few Closing Notes

Even if you run my exact code, you will get a different id every time you request. That seems to be random. Also, whenever I run this in the playground, I always get these errors first, which do not seem to affect whether the code executes properly. I didn’t get a lot of help when I Googled it, and it seemed to be harmless, so I’m ignoring it.

Lesson 019 – Defer

DeferWhen you are writing applications for mobile devices, being a good steward of resources is important. When you are through using objects or resources, you should release them so that the device can allocate the resources for other purposes. However, making sure you clean up resources every time you prepare to return can be difficult and result in a lot of copy/paste code.


The defer keyword creates a stack of commands that are executed when the current scope (typically a method) ends. For those of you unfamiliar with a stack, think of it like a list of things. However, unlike a queue where first in line is the first out of line, a stack operates on a Last-In-First-Out (LIFO) model.

Think about a list that contains A B C D. In a queue, which is a First-In-First-Out (FIFO) model, that list would be unloaded as A B C D. However, if that list were a stack, it would be unloaded as D C B A. This makes sense in English terms, too. If you had a stack of Blu-Ray Disks, the first one you would have to move to get to the bottom would be the last one you piled on.

Defer by Example

Defer is written as a block of code like if…else or do…while. Let us first take a look at code that requires cleanup to happen in multiple places.

You’ll notice that this method can return in two different places, depending on the argument that is passed in. However, if we declare the method’s cleanup code with defer right at the beginning, it will execute automatically when the method is exited – regardless of where that occurs.

Now, if I call this method with 0, I get

If I call the method with 1, I get

This example only dealt with one defer block, though. As I mentioned at the beginning, you can add several defer blocks in your code. Typically, you want to add the defer block right after you declare the thing you need to clean up. Take a look at this method. I declare a method-level cleanup, a cleanup after dealing with the NSBundle, and a cleanup after messing with the NSDate. As an added bonus, those only get added if method execution gets that far, saving my cleanup code from having several if statements and null checks.

Now, if I call into that method passing in 1, 2 or 3, I get the following 3 results. Notice how the added defer blocks are executed in reverse order from how they were added.


You can – of course – write successful Swift applications without using defer. However, defer is one of those language features that will help you to write cleaner code that is easier to read and to maintain. It is always a good idea to declare variables near where you use them (don’t declare them all at the top just to “put them in a spot”). And by the same token, it is better to declare the cleanup at the same time you declare the variables. It is a best practice that will serve you well as you progress on your career.

Lesson 018 – Guard

GuardIn our Introduction to Error Handling, we saw some ways to trap error conditions in our programs. However, the goal there is to control program flow when errors are raised from other parts of the program. That can be framework code (like the JSONObjectWithData call) or code that we have written ourselves.


In today’s lesson, I want to talk about Swift’s guard keyword. Guard is a very subtle feature. You can actually program without it and still create a perfectly well-written program. However, guard allows you to express your intent more directly and specifically than the alternatives. In Lesson 016, we ended up with this method, which handles two pre-conditions before attempting the operation.

Enter Guard

The problem with this code is that we have to think of all of the things that we DON’T want instead of describing the things that we do want. This is where the subtle part comes in. Instead of describing the failing conditions, we describe the passing conditions. Those of you familiar with unit testing might see similarities with Assert statements. I’m fairly sure that’s intentional.

Do you see the difference? Instead of saying if (dividend == 0), we say, guard (dividend != 0). Unlike an if statement, there is no “success block” only the else/failure block. If we have success, the code just keeps going. In my contrived example, this is obvious almost no matter which way we do our parameter checking. However, in an example that Apple provides, you can start to see how this is more clear.


As an exercise, I’d like you to think about how you might have done that without guard. I’ve worked through this a few different ways and each time, I have to either use more lines of code, or make the code itself look less elegant. If you can get yourself to think in this “assertion-based” manner, you are going to write much cleaner code.

Lesson 017 – Revisiting Error Handling for Lesson 015


Back in Lesson 015, we made a simple call to a REST API. At the time, we cheated in handling one of the errors that could occur. Take a look at this line from Lesson 015 to remind you of what we did

Better Error Handling

Now that we have Lesson 016 under our belt, we know better how to handle that situation now. Instead of the try!, which tells Swift that we don’t expect an error at all. We are so confident that we’ve said, “even if we get an error, just blow up the program… life isn’t worth living”. Those are bold statements considering we are dealing with fickle network connections.

Here is the complete program with the proper error handling in place

Now, we’ve exchanged our try! for a try and wrapped that segment of code in a do…catch block. If you want to test this out, you can use these different URLs to force each of our possible error conditions.


Doing error handling in a situation like a network call is often a “worst case scenario”. I realize that it may seem like we did a lot of protecting and if and else and try, but you can see that we have at least 4 different ways that this could have failed. Often, our code is going to be much more straightforward, so don’t judge too harshly by this example 😉

« Older Entries