Swift Interoperability In Depth

Session 407 WWDC 2014

Swift and Objective-C work together at multiple levels to ensure that you can create great apps for iOS and OS X. Dive deep with us to see how to use fundamental Core Foundation and C types in your Swift code. Learn how bridging values work and gain a practical understanding of how Swift and Objective-C can accelerate your app development.

[ Silence ]

[ Applause ]


So I'm Doug Gregor.

I'm an engineer on the Swift Compiler Team, and we're here to talk about Swift Interoperabiity.

We're going to talk about a couple of different things here.

So, of course, Swift is a new language for Cocoa and Cocoa Touch development.

Now, Cocoa's not written in Swift.

It's written in Objective-C, a language you've been using for years and that all of your apps are written in.

So, interoperability between these two very different programming languages is absolutely critical.

So we're going to talk about how that interoperating works at the language level.

We're going to hit a number of different topics today.

We're going to talk about working with Cocoa, seeing how the Cocoa APIs or Objective-C APIs look and feel in Swift and how to work with them, as well as working with some more Swift concepts like dealing with AnyObject and doing dynamic checks on your types.

Then we're going to talk about bridging of the core Cocoa datatypes and NSArray, NSDictionary, NSString into their Swift-native equivalents.

Then we'll move on to subclassing, so writing Swift classes that subclass from Objective-C and how they're mapped back into Objective-C so that you can use these two languages together.

And, finally, we're going to talk about Core Foundation and Core Graphics, and this general notion of CF Interoperability within the Swift programming language.

Let's get started talking about working with Cocoa.

So Swift provides seamless access to Objective-C APIs through the Objective-C Module System we introduced last year.

So you can pull your Objective-C APIs whether they be from Cocoa or your own into Swift and use them.

And then Swift maps those Objective-C APIs into the Swift syntax.

This covers both the objective parts of Objective-C - the classes, protocols, methods, and so on, as well as the lower level C things like functions, enumerations, structs, pointers.

So you have access to all of your Objective-C APIs.

Now when you look at one of these Objective-C APIs in Swift, it's going to be different from Objective-C.

There are inherent syntactic differences between these two language, of course.

Swift also has some modern features that we use when expressing those Objective-C APIs in Swift that will make it look a little bit different, as well as the bridging of core Cocoa types that I mentioned earlier.

Now, despite all of these differences that you see when looking at the APIs, it's still Cocoa, it's still Cocoa Touch.

And the same conventions and idioms still apply, so what you know of Cocoa works in Swift.

It's just a different programming language for the same great platform, the same great frameworks.

So we're going to walk through part of something we know and love, and that's the UIDocument class.

Here's a tiny slice of it in Objective-C.

We're going to walk through how and why that maps into Swift.

First thing, something simple, a property: fileModificationDate.

It is an NSDate!.

This comes into Swift as a property.

It's the var keyword.

The NSDate class, of course just comes into Swift.

Nothing interesting there except for this little exclamation point that you may have noticed.

Now that exclamation point is an Implicitly Unwrapped Optional.

What does that mean?

Well, let's look at Swift in Objective-C.

They're different languages with some different ideas in them.

So in Swift, when you have a value of class type, so I have an NSDate!

That can never be nil.

So a very strong constraint.

And it makes life a bit simpler when you know that thing is not nil.

Now, when you want to deal with nil, you have an NSDate!

that could be nil, you use an optional type, and optional types are covered extensively in the "Intermediate Swift" talk.

We're going to cover them a little bit more now.

That's the Swift side of things.

What about Objective-C?

Well, it does not have the notion of a never "never-nil" pointer like we have in Swift.

And so we have a little impedance mismatch here.

The Objective-C APIs don't have the notion of this is not nil, but we need to bring them into Swift.

And so, we have the implicitly unwrapped optional with the exclamation point here.

And this gives us a nice balance.

It means that we can express the notion of nil and you can test it against nil to do those checks.

However, you can also just directly access properties or directly call a method on it, or you can convert it down to NSNil, and we'll unwrap that optional object automatically for you doing the checking.

So it's a fairly syntactically lightweight way of dealing with nil in a language where nil is a much more explicit entity like in Swift.

Let's look at another property.

So here we have the fileType property that's in NSString.

This is going to come into Swift as a native Swift string.

Now, again, we have the implicitly unwrapped optional here so that nil can be passed through since NSString doesn't have a notion of nil inside it.

And there's a number of Objective-C types that get mapped slightly differently into Swift.

So there's some very, very fundamental types like BOOL and NSInteger that map into the Bool and Int types within Swift.

So we're working with all the Swift types.

There's id and Class, which we're very familiar with in Objective-C.

These map over to AnyObject!

and AnyClass!, something we're going to talk about in a couple of minutes.

And we also have the core Cocoa types that are bridged, like NSString and NSArray, mapping to their Swift-native equivalents.

Again, we'll talk about that later in this talk.

Let's take a look at methods.

There's an Objective-C method fileNameExtensionForType, saveOperation.

It comes into Swift here as, again, a method.

Now, one important thing to know here is that all of the selector pieces from the Objective-C method are here in the method's signature in Swift.

The first selector piece has become the so-called base name of the method.

The second selector piece, SaveOperation, has become a label on the second argument.

A really important thing here is that these labels and their order are enforced at the call site.

So, you must call it as fileNameExtensionForType, saveOperation, just like you do in Cocoa with the exact same ordering, so to preserve that nice readability from Cocoa that we all know and love.

Now the other thing to note here is the consistency here on the Swift side.

All of the names and the colons and the parentheses and the commas are in exactly the same places in the declaration of the method in the middle and in the call site of the method at the bottom.

So the kind of consistency we like out of building a new language.

Let's look at a little bit more complicated method here where we have some blocks going on, some more interesting things, and map that into Swift.

And here there are two different things I want to talk about.

The first thing I want to talk about is the naming of these argument labels and the internal parameter names.

So here in Objective-C you always have a selector piece, goes before the colon.

And then you have the name of the - at the internal parameter that you use when you're defining the method in your .m file.

In Objective-C you always have to write both of these, of course, and many times they're the same.

So you have some redundancy.

We do a little bit of syntax optimization here in Swift, so you just write the name once.

It serves both as the label and the internal name.

If you want those names to be different, fine, we can handle that, too.

You just write the two names next to each other.

The first one is the label because that's what's important for the caller to use.

And then the second one is the internal name that you're going to use within the implementation of your method.

The next thing I want to point out here is the Block.

So here we have a method that takes a Block, and Blocks in Objective-C get mapped into Closures in Swift.

You see, again, this is an implicitly unwrapped optional so that you can pass a nil Block in here.

Now the really great thing about getting Objective-C Blocks mapped into Swift Closures is that we get all of the great closure syntax that is provided by Swift, including trailing closures when your block is the last parameter.

So all of your block-based APIs that you've written, all the ones from Cocoa, when they're following the convention of putting the block last get this nice trailing closure syntax in Swift.

Let's talk a little bit about Initializers.

So in Objective-C we have init methods and init methods have a lot of conventions built around them.

They start with the word "init."

They should be returning instance type, although that's a fairly new invention.

So sometimes they're still returning ID.

And when you're implementing these things, you have a lot of requirements.

You need to call "super init."

You need to reassign "self."

You need to check "self," you need to return "self."

So all of this screams, we need something formalized in the language.

And so Swift has this notion of Initializers.

And we import Objective-C init methods as Swift Initializers.

How do we get from the top Objective-C code to the Swift code in the bottom?

Well, we find the init, so we match the init name and the camel-case string here.

We actually look forward a little bit to see if it's really initWith because that's extremely common.

And then we take the rest of that Selector, and lowercase the first character in it, and turn that into an argument label for the Swift Initializer.

Now, why do we do this?

Well, let's look at how we build objects in Objective-C versus in Swift.

So in Objective-C you do an alloc on your class and then you immediately send it an init message to initialize the Object.

These two steps are almost never separated.

Now in Swift we have our Initializers and we use this Unified Object Construction syntax where we write the name of the Class and then we pass arguments directly to the Initializer.

And notice here, we're using the argument label of fileURL to say which Initializer we're actually using and then give it the argument.

And, of course, we folded the alloc and the init together in this one nice syntax that also happens to work for all other types of in Swift whether they be structs or enums.

Okay. So let's talk about factory methods because this is the other way that we build Objects in Objective-C.

So here we have something from UIColor.

I've stepped away from UIDocument.

And they have colorWithRed blue green alpha.

And, of course, we can go and construct that by calling UIColor colorWithRed green blue alpha.

All of this can be directly imported in Swift.

It would just be a class method, colorwithRed, and green blue alpha as argument labels, and we could just call it on the class.

This would be fine.

However, we don't really love that they're two completely different kinds of initialization.

So we recognize the common patterns in how factory methods are described in Objective-C, and bring them in as Swift Initializers.

And the really great thing here is we get that common Initialization syntax for all of these Objective-C APIs.

You don't have to think, "Is there an init method for this?

Or is there a class method for this?"

It's there as an Initializer.

Do you like that?

[ Applause ]

Let's go a little bit down the stack and let's talk about Enums.

So here's the UIDocumentSaveOperation enum as defined in Objective-C.

And if we look at this we see a whole lot of redundancy.

This UIDocumentSave prefix is used for the enum and for both of its enum values.

Why is this?

Well, this is C.

The enum values in C are in a global namespace.

We can't call these enum values just ForCreating and ForOverwriting because that's going to stomp on some other completely different enumeration somewhere else in the system and cause havoc.

So we do this common prefix by convention.

It helps code completion find the right thing.

But when we're talking about Swift, it's also a great cue for us that we can do better.

And so we can import this NS-ENUM as a Swift enum chopping off all of those common prefixes to get us nice short names for the cases.

Now the reason we can do this is because the enum cases in Swift are scoped within the enum type itself.

How does this play out in actual code?

Well, okay, if we call fileNameExtensionForType saveOperation, we can refer to, say ForCreating, with its fully dotted name - class name.enum, the same dotted syntax we use for a number of anything in Swift.

But Swift has type inference.

We know that this method takes the UIDocumentSaveOperation, so there's absolutely no reason to write that.

You can just pass .ForCreating and we will infer the enum type from that.

I'd also like to talk about NSError.

So this is our pattern in Cocoa for dealing with errors.

And so there are many methods throughout Cocoa and throughout your own apps that take an NSError , and that's a C pointer to an NSError object.

We bring this in with a special type in Swift.

In fact, if you type alias for a much longer type name call NSErrorPointer.

We're going to see NSErrorPointer twice in this talk.

For now we're going to talk about how to use it when we're calling into the API.

And it's not actually all that much different from Objective-C.

So, if we bring this up, we declare a local variable.

It's called error.

It's a type NSError optional.

And we pass its address in when we're calling contentsForType error.

And so in this code we check whether we're getting back some contents from this.

Then we can deal with those contents.

If we fail to find any contents well, we probably have an error.

So we can go unwrap that optional error and present it to the user.

And if we fall through the else here, now we're in trouble because something failed and we have nothing we can do about it.

We hope that doesn't happen.

But this is the pattern you'll be using when dealing with NSError in Swift.

If you truly don't care about the error, you can also pass nil.

So we've walked through a lot of little pieces of the Objective-C mapping into Swift.

And there are a lot of rules that we've talked about that you're certainly not going to remember.

That's perfectly fine.

Xcode has your back here.

Use the tools to help you.

So if you're in Xcode, you're in some Swift Code, you can Command+Click on a class name.

And we'll show you the Swift projection of the underlying Objective-C class.

So take your favorite Cocoa class and look at how it maps into Swift.

Get a feel for the language, an intuitive feel for how these languages work together and you'll get into Swift really fast.

And the great thing is, all of these tools, all the rules I've talked about, apply equally to any Objective-C API when it comes into Swift.

It doesn't matter if it's Cocoa.

It doesn't matter if it's your own API.

The same rules apply, and you can view your own Objective-C APIs in Swift to get to know them better.

Now this works best when you're following "modern" Objective-C practices.

So these are using features like Properties, instancetype, marking your enumerations with NS-ENUM or NS-OPTIONS to describe more semantic information about what these enums actually mean in C.

We've also introduced NS-DESIGNATED-INITIALIZER this year to mark your designated Initializers and formalize a Designated Initializer pattern, both in Objective-C through additional warnings, and as the initialization model for Swift.

So, of course, we want you to follow all of these "modern" Objective-C practices but we don't want you to have to go it alone.

And so this year we introduced the Objective-C Modernizer that helps find these cases in your code where we could possibly modernize them to work with all these "modern" Objective-C features and give you a better projection into Swift.

And that Modernizer is discussed in the "What's New in LLVM" talk earlier today.

Highly recommend you catch it on video if you missed it.

With that, let's talk about id.

What is id in Objective-C?

It's kind of a placeholder in some sense.

It means, I have a value.

I know it's an object but I don't know or I don't care what the static type of that object is.

It's going to vary at runtime most likely.

And there's a couple of core operations that you can perform on id.

You can do upcasting on it.

So, if I have this variable object of type id, I can put an NSURL into it.

Later I can go reassign it and I can put a UIView on it.

That's perfectly fine.

They can both be upcasted essentially to id.

They're both objects.

I can do Message sends to id just directly by doing a Message Send.

I can subscript an id if I really feel like.

In Swift, any object is the equivalent to id.

And it provides these same core operations - Upcasting, Message Sends, Subscripting - that you can do on id in Objective-C.

Now one of the things we know from using id in Objective-C is that you sometimes have to be a little bit careful because if you send a message to an object that doesn't have a corresponding method, you're going to get a runtime failure that this is an unrecognized selector.

Now in Objective-C we have an answer for this.

Using this respondsToSelector idiom.

Do an if. Check whether it respondsToSelector, then do it.

In Swift we like to do a little bit better.

So let's take the same call and let's do a removeFromSuperview() call on this object.

And the thing to note here is that removeFromSuperview() on an object of unknown type, it may be there, it may not be there.

Well, how do we deal with this notion in Swift?

We use an "optional" that says there may be a value there; there may not be.

And so the reference to removeFromSuperview() on object is in effect, optional.

That means we can use the optional Chaining Operator here to - [ Applause ]

What we're doing, of course, is we're folding the respondsToSelector check in, so we do the reference, go look for RemoveFromSuperview.

If it's there, go on, call it.

If it's not there, stop evaluating this expression.

We're done.

Now, something that id does that AnyObject does not do is implicitly downcast.

So I have Object, which is a type AnyObject, and I'm trying to assign it into a UIView.

This is going to produce a compiler error because this is a unsafe downcast.

How do we deal with this?

Well, there's really two cases here that need that you need to think about.

One case is, I know it's a UIView but for some reason that strong type information got lost when going through some API somewhere.

If I know for sure it's a UIView, I can use the cast operator, "as", to say, "Treat this object as a UIView."

We're going to do these kind of class check at runtime to make sure that's absolutely true.

But the type system will believe you at this point.

Now if you don't know whether this object is a UIView or not, you can use the "as?"

to perform a conditional downcast.

[ Applause ]

Think you guys have figured it out?

But just to be sure, this is doing "is kind of" class check.

And it's wrapping the result in an optional UIView.

It's nil if the check failed.

It has the UIView if the check succeeded.

We can do an if-let here to completely do this entire thing safely, and view in here is the UIView we were looking for.

So let's take a little bit of detour and talk about tiny bit of protocols.

Here's an Objective-C Protocol for a UITableViewDataSource and its Swift equivalent.

Not a whole lot new here.

But there are two things that I do I want to point out.

The first thing I want to point out is optional and required.

So in Objective-C optional and required are essentially modes in the protocol.

You say @optional, and everything that follows is optional up until the point where you hit an @required and then everything is required.

And we're not totally thrilled with this decision now.

And the basic reason is that you can't just look at one single declaration in the protocol and know whether it's optional or required.

You have to go scan up your protocol to find it.

And so we did something a little bit different in Swift in that requirements in protocol are required by default in Swift.

If you want to make them optional, then tag them with the optional attribute to make them optional.

The other thing I want to point out here.

We're doing a little bit of Protocol Inheritance and we're inheriting from NSObjectProtocol.

So in Objective-C we will have NSObject the class and NSObject the protocol.

And they have the same name so we have to add the "the class" or "the protocol" at the end when we talk about it.

The language keeps these in syntactically distinct points so the language isn't confused.

But in Swift we wanted to bring all these things into the same namespace because that's far more convenient for the general case.

And so we needed to rename something.

And essentially when there's a conflict between a class name and a protocol name, we'll append protocol to the name of the protocol.

Why did we do this?

Well, let's take a look at another use of id that we see in Objective-C, and that's protocol-qualified id.

So this dataSource here is an object of some unknown type.

But we know that the type conforms to the UITableViewDataSource protocol.

We describe that a little bit more directly in the Swift language by just saying the dataSource is a UITableViewDataSource!.

That's it.

Now some of you here noticed with protocol-qualified id, you can have many different protocols if you want.

We can use the protocol keyword with angle brackets to describe more than one protocol.

Now, one of the things we do with Protocol Conformance is we have an object of unknown type and we want to determine, does it conform to the protocol?

This is the "conforms to protocol check" in the Objective-C runtime.

In Swift, we do this same thing with the conditional downcast operator.

So we can just ask, is my object the UITableViewDataSource" conforms to protocol check, happens in the runtime, captures the results in an optional.

Here we can go easily do that, call one of the methods and compute the number of rows in the first section of this TableViewDataSource.

Let's make our example a little bit more interesting.

Let's compute the number of rows in the last section.

So here we need to compute the number of sections that exist in the TableView, subtract one off of it, and then we can ask for the number of rows in that section.

Now there's a problem with this code.

And the problem is the number of sections in TableView, as you might remember, is an optional method.

It might not be there at runtime.

So we're going to need to compile error out of this because we need to deal with the optionality of this protocol method.

And we deal with this the same way we deal with optionality everywhere else in the Swift language, using the mechanisms we have.

So here we're going to use the chaining "?"

operator. We're checking, does my DataSource have a number of sections in TableView method?

If so, call it, given the TableView, and then we capture the result in numSections so we can compute the last section number and get the number of rows in the last section of our TableView.

That's about all we're going to talk about with Protocols here.

If you're interested in Protocols and some of the amazing things they can do, there's an "Advanced Swift" talk tomorrow morning.

It goes into more depth on those and their interaction with the generic system.

So, wrapping up here, AnyObject is Swift's equivalent to id.

The functionality is similar.

The ideas are similar and the uses are similar.

However, it's more safe by default.

Now we didn't talk about it, but there's also AnyClass, which is Swift's equivalent to class and has most of the same behaviors.

Now the other thing that we've seen is how Optionals are used throughout the language to represent dynamic checks.

We've taken "is kind of" class checks, conforms to protocol checks, responds to selector checks, and folded them all into the notion of Optionals within the language with their optimized syntax to make them easy to use and easy to do the right thing.

With that, let's switch gears a little bit and talk about Bridging of Cocoa data types.

Now first, let's talk a little bit about the native Strings, Arrays, and the Dictionaries within Swift.

The goal of Swift is to have one set of general-purpose native value types that you use for nearly everything.

These need to be safe by default.

This means bounds restricting for arrays, automatic memory management, and so on.

They need to have predictable performance so that you can look at code and have a sense of how it's going to behave with no surprises, how it's going to perform.

And, of course, we want arrays and dictionaries to be collections and they need to be strongly typed collections that work with any type.

We can't limit them just to objects because sometimes you need an array of strings or ints.

And we don't have a seed to fall back to for the cases where the other tools don't work.

This is it.

Now, to support having this one notion of one set of general purpose native value types, we're going to bridge from Cocoa's NSString, NSArray, NSDictionary, into the Swift-native equivalents.

So let's first talk a little bit about the native string type itself.

So, String is an efficient, Unicode-compliant string type.

Core string type of Swift has Unicode built in through and through so it makes it easy to work with.

We provide flexible and efficient high-level APIs to work with strings.

You can easily do concatenation, searches, prefix matches, sub-strings.

And the strings provide value semantics, which makes them easier to work with.

And value semantics is generally a fairly simple notion of, you know, if I have two variables of string type, modifying one of them doesn't affect the other one, all right.

This is very nice for a fundamental data type.

Now, of course, you can also think of strings as a unit, but you can also think of them as being composed of characters which, in fact, they are.

And so we can go walk over a string and using the for loop, and get all of the characters out of the string.

And you get the answer that you would expect.

There are five characters here even though there's no emoji at the end.

So I want to talk a little bit about characters and code points because the character that you're getting out of here is a full Unicode character.

It's not a UTF-8 code point or UTF-16 code point that you have to deal with.

It is a Unicode character.

And now, one of the challenges with the Unicode characters is, you really can't encode them efficiently in a way that treats a string as just an array of characters.

It would be too large.

And so what you generally see is that a string is encoded as, say, UTF-8 or UTF-16.

But working with those UTF-8 or UTF-16 code points, that requires Unicode expertise to get right all the time.

And so we made a really interesting decision here.

We decided not to provide the super low-level operations like length and characterAtIndex to let you poke directly at the UTF-16 or UTF-8 code points, or whatever is stored in the string because doing so causes big problems.

Instead we want you to use the high-level APIs and let the library do the hard work of dealing with all the intricacies of Unicode.

Of course, there's still common operations you want to use.

You may want to count the number of characters in a string, so there's this countElements algorithm.

It works on any sequence and allows you to, well, just count the number of characters in a string, and this produces the right answer, which is there are five characters in this string.

Some of you will want to work with code points, right.

You may be Unicode experts and that's wonderful.

You can get access to the code points.

There's a property UTF-16 that gives you a lazily computed view on the string producing the UTF-16 code points in that string.

And we can go walk over the 16-bit unsigned integer code points.

We can print out the number of code points here and, of course, you'll get the answer "6" because there are six UTF-16 code points in this string.

The last thing I want to talk about with strings is the relationship between string and NSSring.

So NSString has a wealth of really great text processing APIs that you've probably been using for years.

So we've made all those Foundation APIs directly available on the string type, so the APIs you know and love are there, and you can use them.

Now in doing so, we've made them a little bit more Swift.

We've tightened up the type signatures so that if you're going to split a string into its components, well, you're getting it back an array of strings rather than just an array of somethings.

Now you may have developed your own categories on NSString with additional functionality that you use within your own applications.

You can get to those with a simple Cast.

So you can take a Swift string, turn it into an NSString, so this is just a conversion, and then call your NSStringMethod.

If you find yourselves doing this a lot, feel free to just go ahead and extend the underlying string type.

Add your StringMethod, make it a little more Swift with strong type signatures, closures if you'd like.

But this should help you feel at home in Swift fairly quickly and use the String type.

Now let's move from String to a container.

Let's talk about Arrays.

So here we have toolbar items that is in an NSArray.

That's going to come into Swift as an array of AnyObject.

Now these two types are fairly similar.

You can iterate over them and what you're going to get out of it are values of type AnyObject.

They're objects but you don't know what kind of object it is.

You can subscript into them and, of course, you will get an AnyObject.

Now, in Swift, you tend to deal in typed arrays more often.

And so there are some other operations that the core language needs to provide for you to make this clean.

So maybe I'm composing my toolbar items into a Swift array and that Swift array is going to contain UIBarButtonItems.

That's what actually goes into the toolbar items property.

I can work with that Swift Array and then I can assign it into the AnyObject array.

So this is essentially doing a safe upcast of any array of ToolbarItems to any array of AnyObjects.

It also happens to be calling into Objective-C, which we'll get to in a minute.

Now we also see the flip side of this where we want to, say, iterate over all the ToolbarItems in this particular view controller and here we're going to get AnyObject values and, we talked about cast earlier, so we can downcast each of them.

This is fine but it's a little bit on the tedious side.

And so we have specialized syntax here to downcast an entire array at a time doing the "is kind of" class checks necessary to make this safe lazily behind the scenes.

And then you can walk over all with them.

[ Applause ]

Now, we've seen NSArrays in the Objective-C side, Swift arrays on the Swift side.

Let's take a little bit of a peek under the hood at how this actually works because you're going to be writing a lot of Swift code that interacts with a lot of Objective-C code and we want this to perform well.

So there's a Swift array.

And the Swift array actually has two internal representations.

Its first representation is probably what you'd expect out of Swift.

It's a native representation.

It has a length, which is the number of elements in the array.

It has a capacity that's used so we can algorithmically efficiently add things to the array.

And then it has the buffer of elements that are in the array.

And, of course, those buffered elements, whatever kind of array it is, that's how much storage they take.

If we have an array of 32-bit integers, each element takes 32 bits of storage.

There's not extra boxing going on here, no extra performance loss.

It's just a native buffer.

Now we also have this second representation and we do a couple of pointer tricks so that we can fit it into just a tiny amount of memory.

And that's the Cocoa representation.

So any Swift array can actually be an NSArray underneath as representation.

And all the operations on an array handle both of these representations.

So if I subscript my array and it happens to be an NSArray, we'll use object and index behind the scenes.

So you get the result that you want.

If we do append to such an array, well, we can flip the representation quickly and give you that efficient append operation.

So given these two representations, we can talk about the notion of bridging, of converting between an NSArray, as Objective-C would see, and a Swift array that you use within Swift.

There's two directions here: going to Objective-C and coming back.

So first, let's talk about coming back.

So we have an Objective-C method.

In this case, it's the getter for toolbar items.

In Objective-C, that returns NSArray.

In Swift, that's going to come back as an array of AnyObject.

How do we do this?

Well, given our two representations, it's extremely efficient to do it because we have our representation that can just take that NSArray directly.

All we need to do is one copy operation to make sure the contents don't change underneath us if it's a mutable array.

But the common case here is that it's not a mutable array.

It's an immutable NSArray and so this copy operation is trivial.

It's a message send, it's a retain, and that's it.

So its conversion is extremely fast.

Let's talk about the other direction, going from a Swift array to an NSArray.

So this would happen when we take, say, our ToolbarItems.

It's a Swift array.

And we call the Objective-C setter, which expects an NSArray.

Well, now we have an interesting question because there's two possible representations here.

There's the really easy answer.

It's already in the Cocoa representation and we can just hand off the NSArray, no work at all.

But the native one, that a different question entirely.

We could copy the whole buffer but that would be awful.

We could possibly go allocate a little shim object.

That's also possible.

Instead, we decided to make our native representation into a little bit of an Objective-C object [laughter].

It's already an NSArray.

And we've optimized the allocation here so we can build these objects super fast and just pass off our native representation as if it were an NSArray and it works beautifully on the Objective-C side.

[ Applause ]

I think that's enough of Bridging.

Let's talk about subclassing.

Okay. So, Swift objects are all Objective-C objects.

Now what this means is that, if you define a class in Swift, it has basic Objective-C interoperability built in.

We use the same layout as an Objective-C class so there's an "isa" pointer in there.

The "isa" pointer points out to Objective-C metadata.

There's the same underlying infrastructure, the thing that makes "arch" work and the basic frameworks work with retain and release.

You can expect a class.

That sort of thing.

They're all available.

Now, if you really want to make use of your classes from within your Objective-C code, well, then you should inherit from an Objective-C class, whether it's NSObject or some other class.

And this is going to expose your class to the Objective-C world and make all the things you write in Swift available also to your Objective-C code.

So we're going to continue with our UIDocument example from earlier and we're going to create a little MyDocument class that inherits from UIDocument.

And we're going to talk about a couple of the things that subclasses do.

They override methods.

So here we're going to override the handleError, userInteractionPermitted method.

And you do this exactly the same way as you'd do it if you were overriding a Swift method.

It doesn't matter.

The syntax is the same.

The fact that the super class is written in Objective-C?

Completely irrelevant to the syntax of the language and how you work with it.

Now one thing to note in Swift is that the "override" keyword is mandatory.

Why do we do that?

There's a couple of reasons for doing that.

One of the reasons is because when you look at a method, you probably want to know if the intention here is to override your super class's behavior because that's a really important part of your API.

It's a really part of understanding what this method is supposed to do.

Now the other thing it does is it helps overriding accidents.

For example, I meant to override something from my super class, but I typed part of the selector wrong and the method name no longer overrides.

My code isn't running and I have no idea why.

Well, with mandatory override, we catch that.

If you didn't override something and you thought you did, compiler will complain.

There's also the real surprise which is when you override something from your super class that you didn't even know existed.

And this is the case where you just wrote a method and maybe in this release that method happens to exist or maybe it doesn't exist in this release, but some joker added it to the next release in the frameworks that you use and now you're overriding something that you didn't know existed at the time.

We can catch that by requiring override throughout the language.

We could also talk a little bit about overriding properties.

So, in Swift, you don't override the getter or the setter separately.

Instead you override the property itself and then you provide a getter or a setter as appropriate.

So here we're doing something very simple.

We're overriding the description property and providing a new getter for it.

Now what this means to the Objective-C runtime, to your Objective-C code, is that you've overridden the getter.

But the semantic model in Swift is different.

It's based on overriding the actual thing that was declared.

In this case, the property.

As I mentioned before, NSError is going to come back.

So we have contentsForType error we're going to override in our subclass.

And remember that the Objective-C method took NSError, a C pointer to an NSError which could be nil.

The way we work with these in Swift is that the NSErrorPointer class provides a couple of operations that you would expect out of a pointer.

You can test it for nil, as we do in the if check here, to see whether we were actually given a valid point error where it's being given nil by our caller.

Now, if it's not nil, we can point at the memory location associated with that pointer by referring to it as error.memory and we can read from that memory or write to that memory by just reading or signing to it.

Now, and this error pointer is going to take care of the nitty-gritty details of making this auto-releasing to fit in with the code conventions of Cocoa NSError handling.

So it's actually fairly easy to deal with the C pointer from within the Swift world.

Now let's take a look at the Swift class that we've been building here.

We have MyDocument.

It inherits from UIDocument.

It has a property in it.

It has some method overrides.

It's just a Swift class through and through.

But all of this is accessible directly in your Objective-C code.

So if you project this into Objective-C, it would look like this.

All the same elements are there.

We have properties.

We have methods.

Now there's some interesting things to point out.

Well, for one, we have this item's property that is in an NSArray.

Remember, we talked about bridging here.

The original Swift code had an array of strings.

We bridged that seamlessly over to an NSArray that contains NSString objects for your Objective-C code to use.

So you can use strong typing in the Swift world and it maps over to the natural thing within the Objective-C world.

The other thing I want to point out is this really ugly name up top you've noticed.

So this is a mangled name.

Usually you're going to see this as MyApp.MyDocument, unless you're poking at the internal somewhere.

And the purpose of this mangled name is to put everything in a namespace of some sort so you don't have to prefix all of your class names.

Instead, what Swift does is it puts the module name, which is your target, your framework, or your app - that name into the names of the classes it creates so you can use the simple names that you want to use throughout your application and not worry about a conflict with something else in the system somewhere.

[ Applause ]

When you're writing your Swift Classes, you do need to be a little bit cognizant of the limits of Objective-C.

Swift has a lot of cool features; you might want to use them -Tuples, Generics and so on.

And if you go crazy in your classes and you use these features, you might be a little surprised that this generic method that returns a tuple doesn't show up in your Objective-C code because Objective-C has no way to express that signature.

There's nothing we can do.

We don't have tuples in Objective-C.

So if this happens to you and you're surprised by it, there's an attribute you can add to your method.

It's the objc attribute.

And what this does is it asks the compiler to check and make sure that this method or property or initializer or whatever is expressible in Objective-C so it can be used from your Objective-C code.

And if it's not expressible in Objective-C for some reason, the compiler will give you a hard error to tell you this is not something you can use from Objective-C.

Now the objc attribute actually has a second purpose.

And that's controlling the names that you see in the Objective-C side of things.

So, here's a property enabled.

It has a getter.

It has a setter.

In Objective-C this is going to come through as a property named "enabled," a getter named "enabled," and a setter named "setEnabled:" That's not Cocoa convention.

You'd really rather the call, the getter, "isEnabled".

And so to do that we just use the objc attribute, provide it with the selector "isEnabled" so we can control the mapping ourselves between these two languages.

I don't expect you to do this often, but it's there if you need it.

You can also do this for the name of a class.

And what we have here in the parentheses, in the objc attribute, is the non-named space name of a class.

So why would you do this?

Well, perhaps you're porting part of your application from Objective-C to Swift for some reason.

And so you had ABCMyDocument.

Now you just want to call it MyDocument because you're sick of typing ABC.

However, you have some archives that you still want to have work, because this is going to be a drop-in compatible implementation.

In Swift, for your Objective-C class, you can use the objc attribute to give this class the runtime name of ABCMyDocument and keep all of your archives working.

One last thing I promised to talk about, and that's CF Interoperability.

So by CF we're referring to all of the C-like APIs that work with the C objects.

So, this is Core Foundation.

This is Core Graphics and other frameworks, maybe some of your own frameworks.

And let's take a little look at using CF, particularly Core Graphics in Objective-C.

I'm going to do something really simple here.

I'm going to draw a gradient in a rectangle using Core Graphics.

Here's my start.

I need to go build up the ColorSpace and build up the Gradient.

Now there's a couple of things of here that I find non-optimal.

So the one thing is bridge casts.

So we're in ARC.

It's partly great.

It's handling our NSArray for us.

We're using the nice array literal syntax.

But now we need to do bridge casts between CGColorRef and id so we can put things into the NSArray.

And we have this CFArray cast sort of doing toll-free bridging there between the NSArray and the CFArray.

And there's also this semi-amusing thing that we're using three different kinds of arrays in four lines of code.

And you can write this - you can try to write this better.

I couldn't, actually, find a way to make it cleaner than this.

And it's really unfortunate because the NSArray gives us some useful behavior.

ARC is managing its lifetime for us.

That's great.

We need the C Array because we need to put CGFloats in it, and we can't do that within NSArray.

And finally, we need to do the toll-free bridging over to CFArrayRef because that's what we use with Core Graphics APIs.

Now, moving along, we can create some points with CGPointMake and, of course, even though you're under ARC where memory management is automatic, it's not automated for CF things.

So we have to remember to release the ColorSpace and release the Gradient.

We feel like we can do a little bit better in the world of Swift.

So let's start again, this time in Swift.

And first, let's build our colorSpace.

So here we're just calling CGColorSpaceCreateDeviceRGB().

Nothing different about that.

However, the type that we infer for this ColorSpace variable is CGColorSpace.

Note the lack of a ref at the end of this.

This isn't some opaque pointer.

This is the CGColorSpace class that we've created.

What's the nice thing about being a class?

Well, that means we're in the ARC model and we're going to automatically manage the memory for you.

[ Applause ]

Let's go a little further and create that Gradient we talked about.

So here, remember, we need to pass a couple of arrays through.

We can use this nice Swift array literal syntax to form an array containing startColor and Color.

We're doing all of the bridging automatically here for you.

So we've created the NSArray we need.

We've toll-free bridged it to the CFArray behind the scenes so you don't have to deal with the fact that there are so many array types running around.

Did the exact same thing for the C parts.

So here we just have an array of floating point values.

So it's treated as a native Swift array of CGFloats that we bridged seamlessly to the underlying C array that this C function expects.

Let's keep going with our example here.

CGPoint. You can use CGPointMake if you want.

It's perfectly fine.

It works exactly the same way as it does in Objective-C.

However, whenever we import a struct, like CGPoint is a struct, we provide it with initializers that have labeled arguments.

And so a better way to build CGPoints in Swift is to just construct a CGPoint value using that same construction syntax we've been talking about throughout this talk.

And then use the argument labels x and y to make it absolutely clear what you're doing.

And this brings a little bit of a flavor of that nice Cocoa readability using argument labels into the underlying CF APIs.

And that's it for our example in Swift.

It's smaller.

It's easier.

There's far fewer concepts that you have to deal with because we've automatically taken over the management.

[ Applause ]

Now you may have some of your own APIs that we refer to as explicitly bridged.

So these are CF-like APIs where we're not quite sure whether you're following all the CF memory conventions because, unlike the world of Cocoa which is fairly tame, and we've been following conventions fairly well for many years, we haven't been following them so well in C as a community.

And so we may have this function GetRandomColor, produces some random color.

When we pull this in, the Swift compiler doesn't know whether we can really trust that this returns plus zero or not.

It has get in the name but we're not sure.

And so we do the safe thing and we import it as an Unmanaged<CGColor which means we can't directly manage the memory here because we don't know what the conventions are.

So what is this Unmanaged thing?

So Unmanaged is actually a generic struct over an arbitrary T.

Now the details of generic structs we don't need to go into now.

They're covered in the Advanced talk which I highly recommend.

What we want to look at right now is just the simple API of this Unmanaged type.

We have two core operations - takeUnretainedValue, which you use for +0 returns, and takeRetainedValue which you use for +1 returns.

Now, when we call our CGColorGetRandomColor, we want to immediately use one of these two functions.

So we know that GetRandomColor returns a plus zero, so we're going to do a takeUnretainedValue of it.

Now the reason to do this immediately after the call is this gets us a CGColor which takes us right back into automatically managing memory for you.

So the window in which you have to do something with manual memory management is tiny.

It's just this one little line of code where you establish what the convention is for CGColorGetRandomColor.

Now, if you own CGColorGetRandomColor, you can audit your APIs to make sure they follow the Core Foundation naming conventions for memory management.

And when they do, you can use these annotations here in core foundation - CF-IMPLICIT-BRIDGING-ENABLED and DISABLED.

Put this over a whole header once you've audited all the methods in that header.

And when you do that, well, now your function when you use from Swift, gets you right back into the managed world directly.

So you have the great automatic memory management that Swift can provide for CF.

So let's wrap up here.

We've talked about a lot of different topics.

We've talked about interoperability between Swift and Objective-C.

We've talked about a whole lot of rules about how that works.

But let the tools and documentation help you.

They can show you Swift and Objective-C side-by-side so you can get a feel for how your Objective-C APIs work in Swift.

We've talked about some of the details of bridging Core Cocoa data types and using Swift's native types.

And we talked about automated CF memory management available in Swift.

For more information, check out the "Swift Programming Language Book," and also the "Using Swift with Cocoa and Objective-C" guide that goes into more details on the interplay between these two programming languages.

Thank you.

[ Applause ]

Apple, Inc. AAPL
1 Infinite Loop Cupertino CA 95014 US