I’m a big fan of Swift 3. There’s a bunch of relatively small syntax changes that make the language more consistent. The most important of these is certainly the consistent handling of parameter labels in functions (yay!). Another small change I really like is that the @warn_unused_result behavior is now the default. It’s one of those little things that make it harder to screw up unless you explicitly opt in. The biggest modification to the standard library is the new indexing model for collections.

From an app developer’s perspective, however, the biggest changes are how Swift imports Objective-C code (including Apple’s Cocoa frameworks) and the fantastic improvements Apple has made to Foundation and other frameworks to make using them in Swift feel more natural:

The Grand Renaming

The Grand Renaming is the automatic (with optional manual adjustments) application of the Swift API naming guidelines by the C and Objective-C importer. The names of most Cocoa APIs will be more concise in Swift, removing “needless” words that duplicate information that is already present in argument and return types.

Foundation value types

Many Foundation data types are now exposed in Swift as value types, dropping the NS prefix and behaving as you would expect. The value types bridge to their Objective-C counterparts, just like NSArray, NSDictionary, NSSet, NSString, and NSNumber already do.

I love the rationale Apple gives in SE-0069 for doing this:

We know from our experience with Swift so far that if we do not provide these value types then others will, often by wrapping our types. It would be better if we provide one canonical API for greater consistency across all Swift code. This is, after all, the purpose of the Foundation framework.

Type-safe string constants

Stringly-typed Objective-C constants can be annotated to be imported into Swift as enums or structs, providing type safety and namespacing without losing the ability to add new constants to an existing “namespace”. This may not sound like much, but I think this change is actually one of the most beneficial in day-to-day use, if only because code completion becomes more accurate.

Apple has added the necessary annotations to many (all?) of their frameworks. For example, NSCalendarIdentifierGregorian becomes Calendar.Identifier.gregorian, and UIApplicationDidFinishLaunchingNotification is now NSNotification.Name.UIApplicationDidFinishLaunching.

Type-safe selectors and key paths

There is a new syntax for Objective-C selectors and key paths that can be checked for typos by the compiler. No more string literals!

Import C functions as methods

C functions can be annotated to be imported as methods, providing an object-oriented interface that feels completely natural in Swift. Apple has adopted this in Core Graphics. SE-0044 mentions the importer’s ability to infer these mappings automatically on an opt-in basis. I haven’t investigated this, but this could mean that existing C libraries could adopt this with minimal effort.

Swiftified Dispatch API

The GCD API has been thoroughly revamped for Swift.

I love all of these changes. Taken together, they go a long way in bringing Cocoa closer to idiomatic Swift.¹ If you had told me in 2014 it would take Apple only two years to turn their frameworks into (almost) first-class Swift citizens, I don’t think I would have believed it.

The migration from Swift 2 to Swift 3 will probably be painful, but I think it will be worth it (and we don’t have a choice anyway, do we?). Almost every line in your code that calls into a Cocoa API will have to change, and the lack of ABI stability means that you have to make the switch at the same time for all your dependencies. The Swift 3 migrator in Xcode 8 should be able to handle most of the grunt work, and the fact that the compiler knows about the old names is also a big help. If you don’t know the new name of an API, simply type the old name and apply the fix-it.

To learn more about the API design guidelines and how Apple has applied them to their frameworks, watch sessions 403 (Swift API Design Guidelines) and 207 (What’s New in Foundation for Swift). They are both excellent.

Two different names for the same API

I used to get annoyed when people would speak of “Objective-C naming conventions” when what they really meant were Cocoa naming conventions. Verboseness is not an inherent property of Objective-C the language, but rather a quality of the Cocoa frameworks that is largely independent of the language used to implement or call these APIs. It is easy to imagine two frameworks that use the same language, yet have vastly different naming conventions. Objective-C is special in this regard because practically all libraries of relevance follow the Cocoa conventions, so they effectively are the Objective-C conventions. Still, mixing these concepts annoyed me.

Now that the same API has vastly different names in Objective-C and Swift, this actually makes a lot more sense to me. Again, Doug Gregor in session 403:

Every programming language has its own distinctive character. It has its own syntactic feel. But it’s more than the syntax. It’s also the kinds of tradeoffs that that language decides to make. Does it skew toward safety, performance? Do you care about some mathematical terseness or something that is clear and easy to read? You take a look at Swift code, and it’s instantly recognizable. … But it’s not just the language contributing to it. It’s really the APIs you use day in and day out. And these APIs have to meld with the character of the language, so you get a consistent, whole experience of working with beautiful Swift code.

Open-source Swift

None of the changes I mention in this article were revealed at WWDC. On the contrary, they have been developed in the open during the past six months, and Apple has actively asked for and listened to input from the community. The Swift Evolution process is a great gift to the developer community, whether we actively participate in it or just read along.²

Imagine for a moment Apple had not open-sourced Swift, or that they had open-sourced it but continued development behind closed doors. We would not have known about any of the changes before WWDC, nor would we have had the opportunity to voice our opinion about them. Who knows if Swift 3 would have turned out as well as it has?

Meanwhile, not surprisingly for a young language, the notion of what constitutes “idiomatic” Swift has shifted in the past and may continue to do so. ↩︎
Reading every message on the mailing list is a huge time investment that few people can afford. I recommend you subscribe to Jesse Squires’s Swift Weekly Brief. Jesse does a great job summarizing the most important discussions and new proposals. Or just look at new proposals directly in the Swift Evolution repository from time to time. ↩︎