Good morning.

Welcome to What's New in Swift. Let's start out by talking about the goals for the Swift 3 release. Swift was released as an open source project just six months ago, and a big part of doing that was not just to shove out a bunch of sources to GitHub, but to create a fully open community that drives the evolution of Swift going forward.

Swift 3 is the first major update to Swift that is intended to be a product of that community, and so we'll talk about how that community has evolved and the language, the evolution process that crafts the language going forward, and Chris will talk about what that community has produced for Swift 3.

Another big aspect for this release was bringing Swift to more people. Today's software ecosystems are really diverse and people are doing a lot of different things in different contexts, whether they are building it for the server, they are building apps, and others. We want Swift to be available for everybody, and so we'll talk about some great things that have happened on the Linux side. And this is really the first major update to Swift since Swift was ported to Linux.

Now, looking inward at the release, Swift has been going through some iterate refinement and sculpting over the last two releases, based a lot from feedback from developers who are using it, and also, as you'll see from the Swift community since it was open sourced. A big thing about Swift 3 is we really want to get those core fundamentals into shape, all right, so we can really build on top of them going forward.

And last, and probably the most broadest goal, is we really want to awesomize Swift for awesomeness. All right? Swift is really intended to be a powerful tool in the hand of developers, and in their hands they can do really amazing things. That's what we intended it to be.

Now, this is a really kind of broad goal, and the way we've been directing our efforts here is listening to feedback from those using Swift, app developers, but also how we're using it within Apple. And so I want to talk a few minutes about how we've been using Swift, particularly in the last year in our OS releases and the tools.

Now, the big thing here is it's not just increased adoption at Apple; it's just we're using Swift in a variety of different ways, whether it's in writing apps, we have internal frameworks that are now using Swift, Agents and Daemons, things that just kind of power the underlying experiences in the operating system.

And so if you can look, you know, to Sierra, iOS 10, you can see things like the New Music app using a significant amount of Swift. The Console app in Sierra which is very much tied to the new logging initiatives, also has a lot of use of Swift. Also with the Agents and Daemons, the new picture in picture feature in Sierra is 100 percent written in Swift.

Now, looking to the Tools, Xcode, if you look inside, it's using Swift as well. For example, the new documentation viewer in Xcode 8 is 100 percent written in Swift. And the new beautiful Swift Playgrounds for iOS, that's 100 percent written in Swift as well. So we are really using Swift in many different ways. And this is really focusing our efforts to solve different kinds of problems, whether it's performance issues, such as memory usage, getting the calling conventions right, and so forth, and just making sure that Swift is the right tool in different contexts.

I want to talk about a particular case study, and that's the Dock. And the Dock is interesting for two reasons. The first reason is it's a lot more than people think. It's not just the bar at the bottom of your desktop. It's actually a large amount of the macOS Windows, you know, management experience.

So things like Mission Control, LaunchPad, Spaces, this is all what we consider part of the Dock. The second reason why Dock is interesting is it's actually been a Swift adopter for two releases. It started adopting Swift in El Capitan. So we have two releases to look at and to compare in how it was using Swift.

So a lot of changes happened to the Dock in Sierra. First, almost all of Mission Control was rewritten in Swift, and the accessibility engine was rewritten in Swift. Why did we do this? We just didn't rewrite code just for the sake of rewriting code. The code had kind of grown organically over time as features had been added and it was time to refactor it. But also some new functionality needed to be implemented, and so it was the appropriate time to make this, you know, to do this rewrite.

Now, what does this look like at the project level? So to give you an idea, Dock is about 200,000 lines of code with tens of thousands of lines written in Swift. And between El Capitan and Sierra, the amount of Swift code in the project more than doubled. And this actually, because this is part of a rewrite, this replaced a significant amount of C and Objective-C code.

And the effects here are somewhat non-linear, because there's some refactoring and some new features being added, but we saw there was about 15 percent less code to replace the existing C and Objective-C code in Swift, and this is with new features being added at the same time. And the net result is this project is actually slightly smaller in Sierra than it was in El Capitan.

Now, there's a lot you can read into statistics. I think the most important thing here is the engineers working on the Dock love using Swift. They are not mandated to use it. They volunteered. They really just wanted to use Swift. And their experience is that they feel that they can more easily articulate the code that they want to write and they love the safety features from Swift that gives them more assurance that the code they write is great.

Let's move on to Swift Open Source. If you haven't already, the place to go on the web is swift.org. And there you can find a variety of ways that you can contribute to the project, such as if you want to do the most awesome profession in the world and be a compiler hacker, you can check out the source code and find ways to contribute.

And there's other ways. You know, you can contribute ideas, where do we want to take the Swift language? Now, how we run the project is really important. It's meant to be very egalitarian. We want it to be a very open process and transparent and free, and everyone can really participate in driving the language forward. And they can see the rationale of why changes were made.

This is really important. And so all changes to language, whether you are somebody who works at Apple or you're someone out there who is writing apps and you have an idea of how to contribute to change Swift, it works exactly the same way. And I think this is really, really important. And it also means that non-Apple engineers do have direct access, you know, to commit to the compiler and all those repositories. And so we really wanted to empower the community to drive Swift forward.

Third, and I think this is just as important, we have a very strong code of conduct for the project, and we think it's very important that everyone can contribute without feeling that they are discriminated against or treated in an unprofessional manner, and we enforce this very strongly. And last, the project is under a Permissive Open Source License.

This is really important, because we want Swift to be used in ways that Apple didn't conceive. This is one of the goals of open sourcing Swift. We really want everyone to be able to use it in a lot of ways. And there's strong patent protection for the community as well. So that's why we chose this license.

Now, you can follow along with top of, you know, Trunk Development for Swift in a variety of ways. You can check out the sources. You can build the compiler. We also provide downloadable snapshots regularly, that you can download from Swift or you can use directly in Xcode, or you can use them on Linux. And as other platforms are supported, we will provide those snapshots as well.

What's really awesome in an Xcode 8 is we now have full support for Playgrounds with these downloadable snapshots, which is a really awesome way to experiment with the language as it evolves. Also, you no longer have to restart Xcode if you want to use one of these tool chains, so this really creates a really clean experience with trying out the latest version of Swift.

Now, all the development is happening now on GitHub, and it's not just one project. It's actually a family of repositories, and you can find a description of all of them on swift.org, but they can roughly be categorized into these three sections, the Language and its evolution process, a Package Manager, and a set of Core Libraries. Let me talk about each.

Now, the Package Manager was announced when Swift went Open Source. It's still very early but active in development. There's over 1,000 repositories on GitHub that use the Package Manager. So what is this? It's a cross-platform, Package Manager, for building, you know, packages for Linux, for 0S 10. The idea is that we want to build, enable the community to build, a software ecosystem for Swift. And we think this is really vital for bringing Swift to other contexts, like Swift on the server.

It's designed for very frictionless development. It's like easy to get started, minimal configuration, easy to articulate your dependencies. It's just -- the idea is just write your code and go. And we think the Package Manager is so fundamental to Swift and its long-term success that we are committed to delivering fantastic integration of the Package Manager in Xcode as it matures.

Let's talk about the Core Libraries. So what are these? There's a lot of great APIs in iOS, in macOS, TD OS, and WatchOS. A lot of these are like part of the base substrate of APIs that we think should be available for everyone to get work done. And so the Core Libraries represent alternate implementations that aren't tied to the Objective-C run time of some of these core APIs on Linux, and also other platforms that Swift will be ported to, so notable examples include things like XE tests, so you can write unit tests, a subset of foundation that really is quite portable and not really tied to Cocoa, and a work in progress port of libdispatch so you can use all those concurrency APIs.

Now, the work here is still fairly early. It launched with Swift Open Source, but there's a lot there right now. So for foundation on Linux, it supports a lot a great APIs like manipulating URLs, dates, there's data, UID, and so forth. And we expect this to mature and possibly grow in the future over time as the community wants more functionality.

Now, let's talk about the Language. Now, Chris will talk a lot about specific changes in the language. I want to talk about the evolution process that creates those changes. This happens out on the Swift-evolution repository. So let's say you have an idea of how you want to change Swift.

Like you think there's something in there that sucks and some problem there that really gets in the way of doing core development. Maybe it was a good design decision two years ago, but it should be revisited. Or maybe there's something great that we should add that would enable a whole new set of opportunities for developers. Doesn't matter.

You start the idea by socializing it on a mailing list, kicking it around with other developers who have similar interests, and see, you know, is this a good idea? What are the pros and cons here? And once there's enough critical mass, it gets turned into a proposal. This is just essentially like a white paper, written in markdown, which can be viewed, you know, right in a web browser on GitHub.

And here's an example of actually one of the proposals, and it gets submitted for review via pull request. Now, you notice in the bottom left corner here this badge number, it says SE0046. Each proposal is numbered, and this is how we refer to, you know, the actual specific proposals that created change in Swift.

Chris will refer to these proposals throughout his part of the talk when he talks about the changes to the language. And these proposals are the way that everybody proposes changes to the language, proposes the rationale of why we're doing the change, you know, what the specific change would be, the pros and cons, and once the proposal is accepted, the rationale for accepting it.

So a formal review for a proposal starts just by accepting it into the repository, and the review is really just -- it's open discussion again. It's on the mailing list, but this time it's focused to the specific proposal as written, not just some abstract idea. And after some period of time, the Swift core team, which is a small set of individuals, whose role is just to shepherd the project going forward, looks at the feedback of the community, sees, you know, the pros and the cons, and arbitrates a decision based on what the community wants.

And they look at a variety of things. How does the current proposal fit into Swift? So does it make sense? So sometimes proposals are sent back, hey, you know, the way it currently is, this just doesn't work, you know, so go back and consider some refinements here. Or this will just never fit in Swift at all. But also the proposals are often accepted, sometimes with refinements.

And any time it's sent back or accepted, a rationale is documented. So everyone can look back at the history of the language evolution and understand what was proposed and why it was proposed and why it was accepted or rejected. And you can go and see all the proposals just by going to the Swift-evolution repository. And this is the process that created Swift 3, a process driven by everyone. And to talk more about what that has produced, I'm going to hand it over to Chris.

Thank you, Ted. Well, with everything else going on, unfortunately I didn't have time to prepare notes and slides for you. But I printed out all the proposals and I thought I'd read them to you now. Sound good? [Laughter] Maybe not. So what are we trying to do here? We said before that we want to make the core experience of Swift great. And that isn't just about the language. That's also the standard library, the experience of working with major APIs like Cocoa, and also working with our tools. And so we'll go through and talk about each of these in turn.

Now, our number one goal for Swift 3 is source compatibility. And that's a big goal. That means we want to look at what kind of code you write in your applications and make sure that when Swift 3 comes out, that's the right way going forward. And this is actually a really hard problem, because this isn't just a matter of do we use commas or do we use colons, that kind of stuff.

It's also about real key APIs and doing everything possible to get Swift 3 into that shape so that we can live with it forever and get the churn out from underneath you over with. Now, there's a number of different aspects of this, one of which is that we're going to incorporate this into the Swift-evolution proposal process that Ted discussed before, so that any proposals that come in after Swift 3 really think about source compatibility. Now, I think the biggest aspect, the biggest change in Swift 3 that affects the code that we write on a daily basis is the APIs. And so let's dive into API naming and just get a quick taste of what's going on.

So APIs are an essential part of how Apple thinks about building its platform in building out the key components that you all work with and you build on to make great applications. And the naming rules, and the design approaches that go into that shape them in a really fundamental way.

And so with Swift 3, we looked at what is the best way to write these APIs? Do we want full verbosity? Do we want full terseness and like the smallest code possible? And what we found is that the thing that really matters is clarity. And clarity at the point of use.

And so we've really optimized for capturing the essential important information without encoding lots of boilerplate into APIs. Now, let's dive into a couple of examples, and I'll show you some of the thought process and rationale for what this means in practice. So here are a couple of APIs in Swift 2.

We will start with array and append contents of. With Swift 3, this gets chopped in half. The verb append, the operation is now the operation. Contents of is something that describes the role of the parameter you pass in. Now it's an argument label that gets passed or gets used at the call site. This makes it a lot more clear what's happening. Inserted index, this was already in the proper verb form, but that index didn't add any extra information. It was just repeating type information that would be better to be left off.

In foundation, let's look at NSURL. It has a file URL method or property, and just from looking at it, it's not clear that it returns e-Bullion and so now it starts with is making it really clear. Another simple example is URL by pending path component, it just drops the redundantly encoded return type because it's not necessary. And so there's a ton of different improvements like this that all kind of add up together, and there's a lot more detail and talk coming up right after this at 10:00.

Now, let's talk about Objective-C and CAPIs and how they work in Swift. Because again, that's a key piece of how the APIs you work with look and how you experience them in Swift. We've done a number of great improvements here, so one we call import is member. Here's a typical core graphics API written in C.

In Swift 2 it would come in as this global function, right? Well, this works, but this isn't the kind of API we want to work with as Swift developers, and so we've introduced a new feature that allows the API author to tag their API with this macro that wraps an attribute and now gets imported as a method providing the beautiful object-oriented APIs that you have seen in core graphics and dispatch. This is something you can use in your code too.

Another is generics. We introduced lightweight generics last year with Swift 2, and we used them to import typed collections into Swift. But a number of frameworks at Apple adopted lightweight generics in other ways; for example, auto layout and core data. With Swift 3 we are now able to import the fully general generics right into Swift 3 as generic types, which means that a lot of cast and redundant coding of that type information now can just go away. Let's talk --

Let's talk about constants. A common pattern that we see in a lot of Cocoa APIs are using strings as enums. And we do this because that's in C the best way that we could find to encode an openly extensible enum concept, but there are a lot of disadvantages with this. These "enums," in quotes, become these global constants which then get imported directly into Swift as globals and they get used with these big long names.

This is really unfortunate for a lot of reasons, one of which is it's completely not type safe because you can pass an arbitrary string and it won't work. It's also not great because it pollutes code completion and it just doesn't feel like a very Swift API, very good direction for Swift APIs.

With Swift 3 we solved this. So now an API author can add a simple attribute to their type def and now all of the different uses of this become strongly typed in Swift. So you'll find with NS notification names, a commonly used one, that these now become scoped underneath user defaults in this case, and now they get used with proper dot syntax. And the great thing about this is it's actually type checked.

So there are a ton of improvements throughout the SDK adopting these and other features that you can learn about all week long. There are a number of great talks this week. Let's dive into the core language. So with these changes as context, we went back and looked at parameter labels.

And as a quick refresher, if you had this function in Swift 2, you'd call it and you'd use labels on two out of the three parameters. Why is that? Well, the answer is that we were following the Objective-C naming and design patterns and we wanted to be consistent with Cocoa and the Cocoa experience in Swift. But of course we've just radically changed how Cocoa works in Swift, and so now we're able to bring argument labels to all the parameters, which makes the language a lot more consistent and predictable.

Let's talk about generics. So the Swift generic syntax, I think, is really beautiful and expressive. It allows you to capture the key essence of what a function does in a very concise and very nice way. Unfortunately, though, when you get into more advanced use cases, you start adding generic constraints, and the generic constraints are almost secondary to the behavior of the function in this case, but they push down the primary signature way down into the code and it makes it a lot more difficult to read. With Swift 3, we've extended the syntax and improved this, so now your signature is right up front where you want to see it and the constraints are now secondary to that.

Let's talk about unused results. So here's a simple function. It just adds one to a number and returns it. With Swift 2, you wouldn't get a warning about this code even though it's almost certainly a bug. Maybe you forgot to assign it to a variable. Maybe you're just calling it the completely wrong function.

Right? So with Swift 3 you get a warning by default. It's safe. This is great. And this is also really good because it composes well for more complicated cases as well. So not all functions are pure like this in the functional sense. Some of them actually do have side effects. We live in the real world.

And so you may be wondering, well, if I have a side effect, maybe I'm calling this just for that side effect. Well, that's okay, because you can assign to the underbar, which tells the compiler and humans who have to maintain your code that you thought about the fact that this returned something and you explicitly don't care about it, right? Now, not all functions have this property.

Some functions, which are kind of the exceptions, have a side effect as their primary behavior, and so the return value is a secondary thing that often you don't care about. And so in those exceptional cases, you can actually use an attribute to say, hey, I know that this return value is a secondary thing, never produce a warning if it goes unused, which is a nice system.

So let's talk about the most exciting piece of Swift 3, features that go away. And you may be saying why would you do this, right? But we really want Swift 3 to be great, right? And Swift 3 is the sum of all of its pieces, and many of the pieces were put into Swift before we really knew what the language would build into and where we wanted it to go. And so what we did was we went back and thought about all of the features in the language, no matter when they were introduced, and asked a basic question.

If this feature were not already in Swift, would we add it now? And for some features, the answer was no, and so we're taking them away. And this is a great way, this is a great thing to do, because it simplifies the language for everybody. Now, some of these I realize may be polarizing or controversial. The great thing about Swift-evolution is that we debated these all as a community.

Each of these has a proposal with extensive rationale, and if you really want to go back and read the hundreds of emails on each of these, you can totally go back to the mailing list archive and see what happened. I think that pretty much every side of every perspective was very well represented on these issues.

So now there are a bunch of other small enhancements to language as well, and I don't have time to go into all of them, but we have things like generic type aliases. We have type safe selector and key path references. We have new build configurations, improvements to power matching, a ton of great stuff, and you can read them about them either in the proposals or in the extra release notes.

Now another aspect of the core language is talking about syntax, right? And I think we all love, and I hope you love, the basic syntactic structure of Swift. I think it's one of the things that draws a lot of people in, because it feels familiar and it works really well together.

But unfortunately, not all of the pieces in Swift were considered with the care of the hot path of the syntactic structures we use every day, and so we went back, and repainted everything a nice consistent shade of your favorite color here, and we looked at a lot of the weird corner cases, because those corner cases, if they are inconsistent with the rest of the language, it makes them even harder to use, and these are included in the Swift because they are important. And so we went back and standardized everything, and we really want to get it right, so it's right for the long time. So that's a brief overview of the core language. I want to dive a little bit deeper now and talk about the type system.

First of all, what is the type system? The type system in Swift works together with the type checker to define how types work, and the type checker and the compiler uses the type system to prove your code is correct or validate that it's correct, as well as infer things that you leave out of your code because it's supposed to be implicit. For example, what is a type of A? Swift 3, we wanted to simplify the type system, make it more consistent, and we also wanted to define away common types of problems that people run into that were surprising and led to bugs.

So let's talk about a few examples of this. First is unsafe pointer, right? So I don't know if you realize this but you can actually in Swift 2 assign nil to an unsafe pointer. You can test it directly for nil, and you can actually use unsafe pointers without having any idea whether they hold a nil or not.

This is really inconsistent with the rest of the language and it makes unsafe pointers even more unsafe. Well, with Swift 3, now unsafe pointers cannot be nil, so you use optionals, just like everything else in the language. You get to use if let to safely test them and unwrap them, and you even get all the syntactic affordances we provide optionals, which makes everything just work a lot more predictably. Speaking of optionals, another interesting part of the language is implicitly unwrapped optionals.

Implicitly unwrapped optionals are a really important part of the language, particularly when you are working with two-phase initialization or you are calling an API that hasn't been audited for nullability. Now, here's an overly simplified example where I have an int, implicitly unwrapped optional that I'm getting in, but this applies more generally to lots of different types of things.

Now, the basic way that implicitly unwrapped optionals worked in Swift 2, I think, was understandable for most people. In the case of X, for example, well, the compiler has to force unwrap that implicitly unwrapped optional in order to do the addition, and so it does. In the case of Y, well, it didn't have to, and so if just kind of propagated it down through the code.

Well, this propagation was surprising for a lot of reasons. It also was surprising because more complicated cases often led us to scratch our heads about what the code actually does. Because you don't even know you have an implicitly unwrapped optional in many cases. So here, I have an int and an implicitly unwrapped optional.

Does that implicitly unwrapped optional get forced? Do I get an array of any? Do I get an array of optional? What is going on? Well, you never really know until you go to compile your code and you get some weird compiler error, and this is not the effect that we're going for. So implicitly unwrapped optional is really important as a concept, so we kept it, but we changed how it works, to have a new, simpler model.

The model is now very local. For any use of an implicitly unwrapped optional, if the value can be used as an optional, it is. That's the safe thing. We don't want to be unwrapping values where you don't expect it. However, if the compiler is required to unwrap it for type checking to succeed, it does.

So let's go through some examples again. Here, we have X, the compiler has to unwrap it to do the addition, and so it does. This is the key aspect of what makes implicitly unwrapped optionals different than strong ones. Why? Well, here the compiler can type check the expression as an optional, and so now instead of propagating the implicitly unwrapped optional, maybe deep down through your code and many different levels, it turns into a strong optional, which allows you to think about it and know that that's there. This also leads to more predictable behavior with the array, because now, of course, this can be type checked as a strong optional, and so it does.

And if you actually want it to be unwrapped, well, that's okay too. You can explicitly wrap this in your code with the exclamation mark, and now people who read it can know about that, and your code is a lot better. So that's my quick tour of some of the interesting things going on with the type system. Let's talk about the standard library.

The big news in the standard library is a whole new collection indexing model. And what does that mean? Well, maybe you've worked with indexes. Maybe not. There are a lot of great ways to get indexes. The difference here is in how they move. And previously in Swift 2, you'd call them method on the index, like Successor, to move it forward. In Swift 3, the model is basically the same except now instead of the index moving itself, the collection moves the index with itself.

And why would we do this? Well, there's a number of great things at the Springs. First of all, we get to simplify the standard library. A bunch of types just go away, which is great. Even better, common kinds of problems get defined away. You can now have an inclusive range all the way up to the maximum element, which previously would trigger a trap which nobody expected. We also think this is going to bring better performance, because we can get rid of our tandem releases with many common collections. So we are pretty excited about this.

Let's talk about numerics. We have a new floating point protocol or family of protocols which help define operations to allow you to write generic algorithms across a broad range of FloatingPoint types. Even better, if you are a numerical analysis type person and you understand IEEE FloatingPoint, which is not me and not most people, but it has a lot of great low level operations, like getting the number of ULPS out of the whatever, some really important smart stuff here.

[Laughter] So I don't really understand all that stuff. I think it's really important, though, and people who do really value it. I do understand things like Pi, because everybody loves Pi. And in Swift 2 we always got stuck using MPi, and it really irritated me because it was always the wrong type, and you also had to cast it, and it always led to huge frustration. Well, now, despite all that IEEE stuff, you know, in addition to all that IEEE stuff, we even get great things like Pi on all the FloatingPoint types.

And Swift often has types available. And the other great thing about this is that if you have typed context, for example, here we're returning a CGFloat, instead of doing a cast, you can use CGFloat.Pi, but even better you can allow the compiler to infer that completely for you. It leads to a really nice result.

So as with the language, there's a ton of great improvements throughout the standard library. Some of these can really effect and really improve the code you write in Swift, so I highly recommend sticking around for the other Swift talks which will dive into more information. So this was a quick tour of the language, the standard library, how Cocoa works in Swift, but the next big piece is how Swift and the tools work together. So to talk about that, I'd like to invite up Ewa Matejska. Ewa?

Thank you, Chris. Good morning, everybody. Let's talk about Tools, and what better place to start than what the tools can do for your performance. As you can see, we've been really busy this year, but let's talk about a couple of these. We revamped the dictionary implementation, and we also really focused on optimizing the string hashing algorithms for ASCII strings, and we see some really nice improvements in our micro benchmarks for dictionaries that use strings since last year.

We also added stack promotion for class instances array literals, where we promote from the heap, which is really expensive, to the stack, and we see some really nice improvements when our tests take advantage of that. Also, as I already described, we really focused on our string hashing algorithms, and we see this in a dramatic way in our tests that compared the prefixes and suffixes of strings, like we get 86 times improvement.

Next, I want to talk to you about whole module optimization. This is a feature we introduced last year, but I want to just remind you a little bit about what it is. When you look at this diagram, you can see a really parallel compilation flow, one file in, one file out. With whole module optimization, we expand the scope of compilation from one file to multiple files.

And this is really great because the compiler has a lot more information to write new, innovative optimizations and to make your code run faster. So we think this has so much promise from our internal benchmarking, that this year we are turning it on by default for all new projects. And existing projects will get a modernization suggestion and, as it suggests, we think you should modernize and adopt it.

There's a big caveat, which is compilation time. As you look in this diagram, you probably noticed that the compiler is a bit of a bottleneck. And as you would expect, your compilation time increases. To offset this cost, we have made the compiler a lot smarter and it's caching as much as it can to avoid reoptimization and recompilation. So the result of all this is that although the first time you compile, it will be -- it will take a longer time, follow-up, incremental compilations should be faster.

Moving on to code size, this is an area that got -- we did a lot of work in since Swift 2.2, and we have some nice results. DemoBots is a sample app that you can download from Developer at Apple.com, and it saw a decrease in its application binary size of almost 25 percent since Swift 2.2, so that's some really nice ones here. Well, that's all I have to say about performance, but there's lots more to talk about in Xcode.

So my favorite feature in Xcode this year is the improved navigation of Swift code because it really makes a difference every day in development. Let's take a look at an example. So here's an example where we create an array of integers and then just go Sort. What do you think happens when you right click on Sort and jump to a declaration? In Xcode 7.1, you take in a synthesized header that looks like this. Like what is this? It's an extension to mutable collection type, the sort here return self that generated that element, and the only reference to array is in a comment.

So it doesn't make very much sense and it's not very logical. So in Xcode 8, we're doing a lot better, and now you see there's an extension to an array like you would expect and sorted, because sort was renamed to sorted in Xcode 8, now returns an array of elements. So this really improves how you can navigate the code in Xcode and its readability. It's much more logical.

Also, in the standard library, we added groupings by logical areas. For example, array is grouped under collection. And speaking of the standard library, we have all kinds of new documentation for you. And again, the protocols are locked into the APIs, so you can logically navigate like you would in the synthesized interfaces.

Thank you.

I think you're going to really love this part. Yeah. So how many people have Swift 2.2 code? Probably lots of people. So, of course, we have the migrator for you like always, but this year you get to choose. You get to choose Swift 2.3 or Swift 3.

If you're not quite ready to jump to Swift 3, Swift 2.3 is just Swift 2.2 that works with the new SDKs, okay, and we will be accepting submissions to the app store, both with Swift 3 and 2.3, but you should be aware that there are some very key features in Xcode that depend on Swift 3, like Playgrounds and Documentation and the new features as well, like Thread Sanitizer.

Swift 2.3 is a really an interim solution to allow you the flexibility to schedule time to update to Swift 3. So please schedule it today. Yeah. If you are using Swift 2.3, I have a little tip for you. Here is a sample. It's a little code snippet from the lister sample that's in 2.2.

And when you run the Swift migrator to 2.3, it will suggest you add an exclamation mark after frame, because the core graphics API have improved with additional ability editing. Now this code compiles both with Swift 2.2 and Swift 2.3, but if you have a little more complicated scenario, you could conditionally compile your code with a pound FL statement here. So that's just a little tip.

And when you are ready, when you are ready to upgrade to Swift 3, the migrator is there for you. Just go to Edit, Convert to Current Swift Syntax, and you are taken through the migration experience again. So it's easy. Convert to Swift 3 and schedule it today. So that's all I have to say about tools.

And just to recap, recap, Chris talked about how Swift 3 really focuses on nailing down the fundamentals. And we're doing all this in the open on Swift.org, as Ted described, and you can just go there and get involved in the evolution process. And you can see we've got awesome Xcode integration as well.

So there's lots more information this week. There is just the beginning. And we have lots of sessions throughout the week. I want to highlight one, which is the Swift API Design Guidelines. It's in this room right after this session. And have an awesome week with us. Thank you.