Evolving to Swift 3

in Development

For the past few years, Apple has released new versions of iOS and their Xcode development tool each September, so it’s no surprise that iOS 10, Xcode 8, and Swift 3 recently launched. What was a little surprising, however, was the fact that Apple decided to include a major overhaul of API naming and common syntax.

This left us in a bit of a tight spot — our Swift course, App Evolution With Swift, is a great introduction to building your first iOS app with Swift, but since the Swift syntax changed so much from version 2 (the version first taught in the course) to version 3, we knew we couldn’t just leave the old course up to teach new developers old practices. Fortunately, Apple developed Swift 3 in the open, posting new preview versions of Swift 3 and Xcode 8 — sometimes weekly. This helped us get a jump on the changes, and we’re proud to announce our App Evolution With Swift course is now fully updated for Swift 3!

If you’ve already taken the course, what follows is a quick (dare we say… swift) preview of the main things that have changed in Swift 3.

API Naming Guideline Changes

Many core API method names have changed to better reflect a shift away from the old Objective-C way of naming things. For example, consider this UITableViewDataSource method.

Here’s the Swift 2.0 version:

override func tableView(tableView: UITableView,
  cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell { }

And here’s the Swift 3 version:

override func tableView(_ tableView: UITableView,
  cellForRowAt indexPath: IndexPath) -> UITableViewCell { }

A subtle yet important change. The first tableView parameter now has a corresponding external parameter name _ and internal parameter name tableView, and the cellForRowAtIndexPath external parameter name has been renamed to cellForRowAt so that you don’t duplicate that indexPath part in both the external and internal parameter name.

Named Parameters Everywhere

Starting in Swift 3, all function parameters need to be named.

That means while before in Swift 2 you could write this: func addTwoNumbers(3, number2: 5), in Swift 3 you have to write in names for both parameters, like this: func addTwoNumbers(number1: 3, number2: 5). That’s great because it’s so much more consistent and easy to understand what data a function is accepting.

Sometimes this change even coincides with the API naming guideline changes.

For example, here’s a table view method in Swift 2:

tableView.dequeueReusableCellWithIdentifier("ProductCell", forIndexPath: indexPath)

Can you guess what that one looks like in Swift 3? Well, the first parameter "ProductCell" will need a name, and we saw in the first example that the new naming guidelines favor not repeating yourself, so in Swift 3 we get this:

tableView.dequeueReusableCell(withIdentifier: "ProductCell", for: indexPath)

Again, so much cleaner! We know this method takes two parameters named withIdentifier and for, and we can use code completion or look at the docs to see what data type is expected.


NS-prefixed classes are immediately recognizable to any iOS developer. They are a historical artifact from way back in the ’90s when Apple acquired NeXT and the NeXTSTEP operating system, and thus the prefix NS made its way into Apple’s frameworks. It’s been a good run, but Swift 3 has started the process of renaming many of those methods to versions without the NS in front. For example, NSIndexPath is now just IndexPath, and NSFileManager is now FileManager. I’m sure you get the NSIdea.

These are just a few of the changes that Swift 2 developers need to understand about Swift 3 before diving in, and our freshly updated App Evolution With Swift course and corresponding Watch Us Build episode are a great way to wrap your head around the changes. Let us know what you’re most excited about in Swift 3 in the comments below!

Code School

Code School teaches web technologies in the comfort of your browser with video lessons, coding challenges, and screencasts. We strive to help you learn by doing.

Visit codeschool.com

About the Author

Jon Friskics

Content Producer and Developer at Code School. Enjoys building iOS and web apps, and then figuring out the best way to teach people how to build their own.

Might We Suggest