Hi, I'm Pasan, an iOS instructor here at Treehouse.

And in this workshop, we're going to go over migrating to Swift 3 and Xcode 8.

Over the course of this workshop, we're going to talk about

why you should migrate, how you should migrate your codebase over.

And then spend some time looking at the major and minor changes to Swift 3.

Let's start with why you should consider migrating.

The first thing to note is that Swift is still not ABI-stable.

This means that application binaries created with previous versions of Swift

are not compatible with the current compiler.

ABI stability was originally a goal of the 3.0 release.

So it's important to be aware that it was pushed.

We've now been promised ABI stability in the 4.0 release.

There are good reasons to migrate to Swift 3 as well.

Swift 3 brings a much-needed consistency in API design across the language.

The changes are vast, which is where most of the migration pain will be apparent.

But the guidelines are clearly defined and give Swift a character of its own.

With Swift 1 and 2,

we've mostly been using a variation of Cocoa's design guidelines.

And it felt clunky in a lot of places.

With the goal of cross-platform swift, Cocoa conventions make even less sense.

So the new guidelines aim to resolve that.

We'll go over some of these high-level changes.

The new API guidelines have been applied to Objective-C APIs imported into Swift.

And along with better use of Swift's features,

it is a much nicer experience using Cocoa Touch classes in Swift.

We'll be taking a look at some of these examples as well.

A final reason for moving to Swift 3 is better tooling and language support.

Xcode 8 includes several new and improved features,

like a runtime issue report generator, a brand new memory debugger,

a thread sanitizer to spot race conditions, and an improved view debugger.

If your codebase is in Swift,

moving to Xcode 8 means making a decision on the language version.

So perhaps you know that you want to migrate to Swift 3, but

you're unsure about when you should do this.

How urgent is the need?

Swift 1 to Swift 2 was pretty urgent.

You could not use Xcode 7 unless you migrated your codebase, and

this was quite painful.

It meant choosing between migrating your codebase,

versus improving your app for users by adding new functionality and features.

With Xcode 8, Apple is a bit more forgiving, thankfully.

Xcode 8 supports both Swift 2.3 and Swift 3.0.

It's important to note, though, that we don't know how long that will last.

A future minor version of Xcode 8 may remove this functionality and

only support 3.0.

It really is intended to just give us more time to migrate over,

because the changes are pretty vast.

So while you do have the ability to use Xcode 8 with a codebase in Swift 2.3,

I would recommend getting started as soon as possible.

I've heard everything, ranging from Xcode will support 2 versions until Xcode 9,

to the next minor version will only support 3.0 and up.

Even if you decide that you are going to stick with Swift 2.3 for now,

your hand might be forced.

Most third-party libraries are well underway with Swift 3 versions and

have frozen their 2.3 versions.

You can expect bugfixes, but not much else.

Given the lack of ABI stability, if you use several dependencies,

the burden now falls on you to maintain a fork for as long as you need to.

While there's no urgency to this, another good reason to migrate is to take

advantage of the improved safety offered by improved Objective-C API in Swift 3.

Some of the improvements to the SDK in iOS 10 are available only through Swift 3.

One of my new favorite features is the usage of generics in Core Data API,

something we'll look at in later slides.

This, for example, is only available in Swift 3 for those of you writing Swift.

Let's say you've decided to migrate.

What are you getting yourself into?

Over the next few minutes, let's go over some of the major changes to the language.

This will be a quick overview.

The scope of some of the changes are extensive.

But I've provided links to resources at the end of this deck for you to check out.

We'll start by exploring the new API Design Guidelines,

particularly those that define the new naming conventions.

After that, we'll see how these guidelines have been imported to Objective-C API and

why they're much nicer to use in Swift 3.

Swift 3 also includes new types that makes both the cross-language and

the cross-platform development experience easier, and we'll touch on this.

Finally, we'll take a look at few of the minor changes and some strategies for

migrating.

The most apparent changes are those defined in the new API Design Guidelines.

Not only do they require you to think differently from naming

conventions established by decades of Cocoa and Cocoa Touch development.

But the application of these guidelines mean that usage of familiar API is

different now.

And this affects how our codebases are designed.

Let's start with the fundamentals.

These are overall guidelines that should help you understand the point of view of

the Swift core team.

And thereby, help you get in the mindframe of redesigning your own API.

Before we proceed, as we go through these slides, you'll notice in the bottom

right-hand corner a link in the format SE, followed by a number.

This is a link to the swift-evolution post on GitHub that provides an excellent,

in-depth summary of the changes we're talking about.

If you're interested in learning more about each change,

that's where you should go.

All code should be written so that it reads well.

But Swift 3 approaches this from a slightly different perspective than we

might be used to.

Objective-C classes have both a header and an implementation file.

API design in Objective-C was focused on making methods and

variables descriptive and informative through a header file.

We're all familiar with Objective-C's verbosity.

And this provided for a great deal of clarity and intent.

In Swift 3, the focus has shifted to clarity at the point of use.

We want to design API that is readable, concise, and clear when our methods and

functions are called, rather than when we look at a class' interface.

When Swift was released, the pendulum swung from one end, with Objective-C-style

verbosity, to the other end, where developers often focused on brevity.

Swift 3 makes it clear that brevity should not be a goal in API design.

Instead, it should be a side effect of focusing on clear API

that uses Swift's language features like the type system.

Essentially, at no point should you be focused

on writing the smallest amount of code.

Swift 3 also uses a variation of CommonMark, a dialect of Markdown,

to provide a consistent format around documentation and doc comments.

Since the focus on API design is at the point of use,

Swift 3 relies on documentation comments and

Xcode IDE features to provide full method descriptions in any related documentation.

As I mentioned, these API Design Guidelines are pretty vast.

So let's break it down and look at some of the new naming changes, so

you have an idea of what you're getting into.

One of the major goals of Swift 3 is to prevent ambiguity at the call site and

to promote clear usage.

This means including all the words necessary in the method signature

that are needed to convey intent.

Now, this sounds like Objective-C, but there are further restrictions.

So here, we have an example of API that would be deemed

ambiguous under the new guidelines.

We have a remove method that removes an element at an index position and

returns it.

At the point of definition in the class' interface, this reads well and

it's obvious what the method does.

However, remember that with Swift 3, the focus is at the call site.

At the call site here, it's unclear whether we're

removing a particular element, an element equal to some object,

or whether we're actually fiddling with the index.

Here is the same method formatted for Swift 3.

Swift 3 makes a departure from Cocoa and

Objective-C conventions when it comes to argument labeling.

Consistent label behavior has been established across all parameters,

including the first label.

Whereas in Swift 2 and

prior, the first argument label was omitted by default to match Cocoa.

Here, we've given the method an external argument,

at, to clearly indicate we're removing at a particular index.

We've also defined a typealias to provide increased clarity around the index value.

That first rule of including all the words made it sound like we were striving for

Objective-C's verbosity.

But that's not actually the case, because our second rule is to omit needless words.

That is, redundancy should not be a goal.

Here's a simple example.

Here, we have the signature for

a class method on NSLayoutConstraint that activates an array of constraints.

This would be considered poor API design in Swift 3, why?

We have a lot of redundant information here.

It's clear, from both the type on the argument as well as the label,

that we're activating constraints.

Yet we're being redundant by specifying this in the base method name.

This isn't as bad in Swift 2, because that argument label would be omitted.

But in Swift 3, that's a lot of times that we're saying constraint.

One in the class name, one in the base method name, one in the argument label,

and the final time through the type.

Here is the same method in Swift 3.

The method name is now simply activate.

We're relying on a Swift feature,

the strong type system, to clarify what it is we're activating.

Because the type is sufficient enough, anything else is redundant.

So we've intentionally omitted the external argument label as well.

The final method at its call site reads as a grammatical English phrase,

which is one of Swift's goals.

NSLayoutConstraint.activate(constraints).

Speaking of English phrases,

there are several rules governing naming conventions.

I highly recommend you take the time to go through the guidelines carefully.

Both in the proposal linked below and

the official guidelines page linked at the end of this deck.

New naming conventions affect our codebase in two ways.

One in the code we write, and

second, the code that we call from Cocoa Touch frameworks.

The application of new guidelines affects changes to both how Objective-C,

and even C methods and functions, are imported into Swift.

As well as the usage of these methods by making use of Swift-only features.

One of the more obvious changes that makes for a great example is Core Data API.

In Swift 3, NSFetchRequest is a generic type

with a type parameter that conforms to a new protocol, NSFetchRequestResult.

This means that given an NSManagedObject subclass Foo,

we can create a FetchRequest for Foo like this.

No more stringly-typed entity names.

Furthermore, if we look at the signature for

the fetch method, you'll notice that the return type is not AnyObject,

as it was in Swift 2, but the type of the generic parameter.

This means that if we call fetch on a context and provide a FetchRequest, we're

guaranteed to get an array of the type back, rather than an array of any object.

You'll notice, throughout this example as well,

that the new guidelines have been applied to existing Objective-C API for

a more consistent naming experience in Swift.

Speaking of Any and AnyObject,

Swift now imports any API typed with ID as Any, rather than AnyObject.

For example, here's a bit of code from the NSFetchedResultsController delegate

protocol, sticking with our Core Data example.

Notice that the object changed over here as an argument type of AnyObject.

In Swift 3, this comes in as Any now.

The motivation behind this change is to keep Swiss value semantics consistent

when importing Objective-C API.

It's worth reading the entire proposal to understand the scope of this change.

The reason I bring this up is because the migrator doesn't always play nice.

So it's important to be aware of bugs in Xcode that can affect you.

So here's my experience.

I recently migrated a project from Swift 2 to Swift 3.

The migrator seemingly did its job.

But there were a few cases where it did not convert the types of such

imported API from AnyObject to Any.

There were no compiler errors raised by the inability to convert these methods.

But because the signature of this particular delegate method did not match

the signature of the one in the protocol, my delegate method was never being called.

What's more surprising is that there was no compiler error informing me that I was

not fulfilling the delegate protocol contract.

Took me a while to track that down.

In much the same way, in sets and dictionaries, NSObject and

AnyObject are now imported as AnyHashable and Any.

This is important to know, because if you are writing Objective-C code or

are a library author, there are new Objective-C features to control and

adapt this importing.

All these features make the experience of working with both languages much better.

And should hint at a future where neither language is really

preferred over the other, but up to the developer.

There are several changes around this goal, including one of my favorites,

proposal number 33, which imports Objective-C constants as

Swift types like enums.

One of the more interesting changes to Swift is the overhaul of the standard

library.

This was motivated both by mutability concerns and

the lack of foundation types in a cross-platform experience.

NSDate now has a Swift equivalent, Date, URL for NSURL, and so on.

These new types are value types and play well with Swift's mutability semantics.

You might run into minor errors during a migration process, where you were

previously mutating a reference type that has now been bridged to a value type.

But this is a good thing, in my opinion.

You're aware of this error up front.

Note that you are not required to only use the new foundation types, but

have access to the legacy Objective-C types as well.

These types also play well with each other and

are automatically bridged as you move from one language to the other.

Libdispatch is also improved in Swift 3.

Here, we see an example of libdispatch in Swift 2.

In the first snippet,

we call dispatch_queue_create to create a custom queue.

And then call dispatch_async and pass in the queue to execute some arbitrary code.

In the second snippet, we're executing some arbitrary code on the main_queue.

In both these situations, the libdispatch library is imported as is.

And the C API seems completely out of place.

In Swift 3, the API surface has been transformed to feel much more natural.

We now have a DispatchQueue type with class properties

to return various common queues.

We also have instance methods that dispatch our code, either synchronously or

asynchronously.

While a true concurrency model is still a ways off in Swift 4,

this is a much better experience.

Let's look at one last change that makes a pretty big impact when migrating.

Swift 3 brings some new access control keywords and

changes the meaning of existing ones.

One of the new access control keywords is fileprivate.

A fileprivate variable is only visible inside the file.

This means that you can use fileprivate inside a particular Swift file and

across any extensions of the type in that file.

But this is what private used to mean.

Well, private now means private to the current scope.

A variable defined as private cannot be accessed in an extension of the type.

A second proposal, 117,

introduces a new keyword, open, and changes the meaning of public.

In Swift 2, declaring a class or variable as public

meant that external modules could use the class and override it.

In Swift 3,

public now means that external modules can use the class, but cannot override it.

Instead, a new keyword has been introduced, open.

That means a class can be used and overridden by an external module.

These newer keywords will certainly impact your codebase as you migrate to Swift 3.

Many of the variables, constants, and functions marked as private, but

used in extensions, will now return compiler errors.

Essentially, there's a bit of cleanup to do.

As you can see, there are lots of changes you will have to make,

both to your code and the code you call.

And we've only covered some of the major changes.

There are several minor changes as well that'll undoubtedly impact you.

So how should you go about it?

The first thing is, you should ensure that you have decent test coverage.

You'll want to know that the codebase behaves in the same way after migration.

So make sure you have benchmarks that inform you as such.

Next, start your migration by using the built-in migrator.

It's far from perfect, but

it will take care of most of the renaming of API from frameworks.

But beware,

of course, there might be some edge cases that you'll have to take care of.

Set aside a decent amount of time.

The scope of changes is pretty vast.

It's more painful going from Swift 2 to Swift 3, than Swift 1 to Swift 2.

And you have to do it all at once.

So don't try to get this done while hitting other deadlines as well.

Finally, and

probably a bit more painful, is to figure out a strategy for all your dependencies.

Most third-party libraries have Swift 3 branches that you can already pull in.

But the situation may vary on a case-by-case basis.

While you're certainly not in a great rush to get this done,

remember that any Swift 2 code written right now is technical debt.

So you want to try and get this done as soon as possible.

I've included a few resources so you can read up on the scope of changes.