Apple released the first official developer preview of Swift 3.0 bundled with Xcode 8, and although it contains a bunch of great improvements, like function parameters required by default, new Foundation types, and integration with the new Swift Package Manager, it also contained one really big change that’s going to impact nearly every Swift app that hopes to migrate to 3.0: API naming changes.

If you’re creating an app from scratch, this probably won’t be that big of a deal since code auto-completion will lead you in the right direction, but if you open up a Swift 2.x app, you’re likely to see a bunch of warnings and errors. For example, this is what we saw when we opened up the GoodAsOldPhones app from our Swift course, App Evolution with Swift.

No good! Let’s look closer at what these seven warnings and seven errors mean.

External Parameter Names

The AppDelegate.swift file has a bunch of warnings that all look something like this:

What’s happening here is that the first parameter passed into the function no longer has an external name. This is really just a minor detail since you don’t call this method directly, and it’s a quick fix to make the compiler happy. You can either manually edit that first parameter name to _, or just let Xcode handle this for you.

More Concise API Naming

Our ProductsViewController.swift file contains a few methods with changed names too. The tableView(_:numberOfRowsInSection) method is the same underscore change as before, but there are some new, more subtle changes in here too.

For example, here’s what one method looks like before:

And here’s what it looks like after:

If you look closely, you’ll notice there are two differences beyond just the first external parameter.

1. cellForRowAtIndexPath has been changed to cellForRowAt
2. NSIndexPath has been changed to IndexPath

Although it might not be obvious at first, the renaming of cellForRowAtIndexPath to cellForRowAt is basically the same thing that was happening with the underscores. The cellForRowAt part of the function declaration is the external parameter name — so if you wanted to call this method directly, that’s the name you’d use for that parameter. The name of that parameter that’s internal to the function, indexPath, hasn’t changed from Swift 2 to Swift 3, so if your code in that function block uses indexPath then it won’t need to change.

These kinds of name changes are all over Swift 3.0 and are where you’ll spend most of your time making updates. You can also see this in two of the other errors on the first load of our project in Xcode: override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) { } becomes override func prepare(for segue: UIStoryboardSegue, sender: AnyObject?) { } , tableView.indexPathForCell(cell) becomes tableView.indexPath(for: cell), and tableView.dequeueReusableCellWithIdentifier(_:forIndexPath:) becomes tableView.dequeueReusableCell(withIdentifier:for:).

The change from NSIndexPath to IndexPath, on the other hand, is a bit different. NSIndexPath is an Objective-C class that was originally just bridged so that it could be used in Swift, but with Swift 3.0 there’s a new value-based type (as opposed to class-based) called simply IndexPath. It’s still found in the Foundation framework, but because it’s just a struct, it’s immutable by default and you don’t need to worry about how it gets referenced in other places, because it doesn’t — it just gets copied if needed.

Better Handling of C-style Functions

Finally, Swift 3.0 makes a great step toward limiting the amount you have to deal with C-style APIs. For example, in our ContactViewController.swift file, we’re using the CGSizeMake() function and passing in two numbers for the width and height, and in Swift 3 we get the error CGSizeMake is unavailable in Swift. Instead, we can use the CGSize() struct and initialize it with named width and height parameters, like this: CGSize(width: 375, height: 800), and that error goes away. That -Make function was just a helper to begin with, so this is another welcome change in the language that makes Swift more predictable.

After each public release of a new Swift 3.0 developer preview, we’ll link to a new post that describes some of the bigger changes and shows you how they affect some of the sample applications we’ve made, and we’ll also link to a swift-3.0-developer-preview branch in our sample code repo that shows those changes in effect for each new developer preview.