What’s New in Swift 1.2

Just when we thought Apple was busy working on more WatchKit and Xcode 6.2 betas – Xcode 6.3 beta and Swift 1.2 landed in our collective laps on Monday!

There are a ton of exciting changes in Swift 1.2. It’s still very much a beta, and only the inner circle at Apple know when it will be finalized, so it’s not a good idea to use it in any apps you’re planning on shipping anytime soon.

But it’s still good to keep up-to-date with the changes so you’re when they go live. In this article, I’ll highlight the most significant changes in Swift 1.2:

• Speed improvements
• Improved if-let optional binding
• Changes to as when casting
• Native Swift sets
• Changes to initializing constants
• Objective-C interop and bridging

And to tie it all together, I’ll try out the new Swift migrator tool to see just how well it converts a project written in Swift 1.1 to 1.2, and I’ll let you know how Swift 1.2 affects our tutorials books.

Remember, Swift 1.2 is beta software. The final Swift 1.2 release is still a good way away, and you can’t submit apps built with Xcode 6.3 beta to the store. So again, this isn’t something you’ll probably want to use yet, but it’s nice to keep track of what Apple has in mind for the language and the platform.

Let’s look into the future and get a sneak peek of what’s in store for us Swift developers!

Speed Improvements

Swift 1.2 brings several speed improvements to make both your apps and development even swifter!

• Incremental Builds: Xcode no longer needs to recompile every single file in the project every time you build and run. The build system’s dependency manager is still pretty conservative, but you should see faster build times. This should be especially significant for larger projects.
• Performance Enhancements: The standard library and runtime have been optimized; for example, the release notes point to speed ups in multidimensional array handling. You’ll need to benchmark your own apps since performance characteristics are so different between apps.

Swift code is already faster than Objective-C code in some cases, so it’s good to see continued improvement here!

if-let improvements

The aptly-named “pyramid of doom” is no more! Before Swift 1.2, you could only do optional binding on one thing at a time:

// Before Swift 1.2
if let data = widget.dataStream {
  if data.isValid {
    if let source = sourceIP() {
      if let dest = destIP() {
        // do something
      }
    }
  }
}

Now, you can test multiple optionals at once:

// After Swift 1.2
if let data = widget.data where data.isValid, let source = sourceIP(), dest = destIP() {
  // do something
}

Note the new where keyword that lets you test for boolean conditions inline. This makes your conditionals much more compact and will avoid all that extra indentation.

Upcasts and downcasts

The as keyword used to do both upcasts and downcasts:

// Before Swift 1.2
var aView: UIView = someView()

var object = aView as NSObject // upcast 

var specificView = aView as UITableView // downcast

The upcast, going from a derived class to a base class, can be checked at compile time and will never fail.

However, downcasts can fail since you can’t always be sure about the specific class. If you have a UIView, it’s possible it’s a UITableView or maybe a UIButton. If your downcast goes to the correct type – great! But if you happen to specify the wrong type, you’ll get a runtime error and the app will crash.

In Swift 1.2, downcasts must be either optional with as? or “forced failable” with as!. If you’re sure about the type, then you can force the cast with as! similar to how you would use an implicitly-unwrapped optional:

// After Swift 1.2
var aView: UIView = someView()

var tableView = aView as! UITableView 

The exclamation point makes it absolutely clear that you know what you’re doing and that there’s a chance things will go terribly wrong if you’ve accidentally mixed up your types!

As always, as? with optional binding is the safest way to go:

// This isn't new to Swift 1.2, but is still the safest way
var aView: UIView = someView()

if let tableView = aView as? UITableView {
  // do something with tableView
}

Sets

Swift 1.0 shipped with native strings, arrays and dictionaries bridged to NSString, NSArray and NSDictionary. The data structure nerds asked, “what happened to sets?”

Better late than never, native Swift sets are here! Like arrays and dictionaries, the new Set type is a struct with value semantics.

Like arrays, sets are generic collections so you need to provide the type of object to store; however, they store unique elements so you won’t see any duplicates.

If you’ve used NSSet before, you’ll feel right at home:

var dogs = Set<String>()

dogs.insert("Shiba Inu")
dogs.insert("Doge")
dogs.insert("Husky puppy")
dogs.insert("Schnoodle")
dogs.insert("Doge")

// prints "There are 4 known dog breeds"
println("There are \(dogs.count) known dog breeds")

You can do everything you would expect with Swift sets: check if a set contains a value, enumerate all the values, perform a union with another set, and so on.

This is a great addition to the standard library and fills a big abstraction hole where you still had to drop down to NSSet, which doesn’t feel very native in Swift. Hopefully, other missing types such as NSDate are next on the list to be Swift-ified. ;]

let constants

Constants are great for safety and ensuring things that shouldn’t change don’t change. Our Swift Style Guide even suggests this rule of thumb: “define everything as a constant and only change it to a variable when the compiler complains!”

One of the biggest problems with constants was that they had to be given a value when declared. There were some workarounds, ranging from just using var to using a closure expression to assign a value.

But in Swift 1.2, you can now declare a constant with let and assign its value some time in the future. You do have to give it a value before you access the constant of course, but this means you can now set the value conditionally:

let longEdge: CGFloat

if isLandscape {
  longEdge = image.calculateWidth()
} else {
  longEdge = image.calculateHeight()
}

// you can access longEdge from this point on

Any time using let is made easier, it’s a thumbs up for clearer, cleaner code with fewer possible side effects.