Favorite Swift 3.0 Features

Last week at WWDC was a massive whirlwind of learning, trying, and meeting. I had some time today to decompress and think more about some of the things that were released last week, starting with the Swift 3.0 beta.

There are a lot of amazing changes in Swift 3.0, but I wanted to highlight the ones that made me especially happy (i.e. I probably excitedly tweeted about it but want to say more than 140 characters about it).

Anyway, without further ado…

Importing Objective-C Lightweight Generics


Prior to Swift 3.0, Objective-C has had light-weight generics as a feature, which allows you to write code like ListViewController<Word *> * in Objective-C, but they used to appear to Swift code like ListViewController without the generic type parameter. In Swift 3.0, ListViewController<Word *> * will appear to Swift code like ListViewController<Word> instead, which is a huge improvement.

I’m particularly excited that Swift 3.0 will prevent me from writing layout code with NSLayoutAnchor that accidentally tries to constrain an X-axis anchor (like leadingAnchor) to a Y-axis anchor (topAnchor) because hey, we all make mistakes.

Type-safe layout code? I dig it.

If you’re interested in learning more about NSLayoutAnchor check out the official docs. 👀



Have you ever had to write stringly-typed KVO code like this?

person.addObserver(self, "phoneNumber.areaCode", options: .New, context: &context)

This is very prone to human-error like typos which will lead to crashes. Swift 3.0 adds a new expression #keyPath() which allows us to write the below code instead.

person.addObserver(self, #keyPath(Person.phoneNumber.areaCode), options: .new, context: &context)

Not only do we get the the benefits of static type-checking, we get autocomplete as well! Safe and lazy: my favorite kind of programming environment.

Import as Member


Have you ever had to write Core Graphics code in pre 3.0 Swift? I have, and it felt like I was writing C code! 😱

Lucky for us, Swift 3.0 adds the ability for C API authors to specify what the API should look like in Swift so it feels more natural, and well, more Swift-y. Look how much nicer the Core Graphics example looks now!

(If anyone knows if there is a replacement for UIGraphicsBeginImageContextWithOptions please let me know. EDIT: Thanks @alexito4 for the tip on UIGraphicsRenderer!)

Also, if you want to see an even bigger transformation of Core Graphics code, I recommend watching the Swift API Design Guidelines talk. The “Import as a Member” part is somewhere in the last 15 min or so.

Speaking of Swift API Design Guidelines, Swift 3.0 fundamentally changes the way that Swift code reads for the (way way way) better.

New API Design Guidelines


Swift 3.0 has three core principles:

  1. Clarity at the point of use (call site)
  2. Clarity > Brevity
  3. Reliance on contextual cues

I think the best way to experience these principles is to download Xcode 8 and run your code (maybe a small Playground at first) through the Swift 3.0 migrator. I tried it on a small project, and this is what I ended up with.

(Here’s the entire diff if you’re interested.)

You have to do some manual changes too (like choosing the right prepositions), but overall the migrator is 💯 and will do everything it can to make the transition process as smooth as possible.

Anyway, what do we read here?

  • “truncate to 8”
  • “sanitized string for key”
  • “hash for key”
  • “matches in line”
  • “localized strings in line”

Ah, grammatical code to my ears. 🎶

I love it.

If you want to hear more details about Swift 3.0’s philosophy, I again recommend watching the Swift API Design Guidelines talk. The official Swift API Design Guidelines page is a great companion reference as well.

… and many more

There are a tonne more features that were added in Swift 3.0, and you can learn about them on swift-evolution. Although I don’t follow the mailing list, I love skimming through the accepted and rejected proposals to see what kind of thought and reasoning went into each design decision. It’s especially interesting to read through the tradeoffs and alternatives that were considered, since this process applies to all sorts of engineering beyond programming language design.

I think it’s also worth noting that a lot of the “new” features that were added to Swift relate to having better Objective-C and C support, which may sound counter-intuitive/productive at first. But I think if we want the future to be Swift-y, we need to make sure that existing apps and frameworks that are written in Objective-C and C can seamlessly and naturally fit together with the Swift world, so that the entire community — not just the entirely-Swift apps — can proceed fearlessly into the new world. I think Swift 3.0 does a great job of building that bridge.

Anyway, thank you for reading! What are your favorite changes and additions to Swift? Let me know in the comments below. 🐥💛💭