What’s New in Swift 1.2

What’s new in Swift 1.2? Read on for the highlights of the latest changes to our favorite programming language! By Greg Heo.

Leave a rating/review
Save for later
Share
You are currently viewing page 2 of 2 of this article. Click here to view the first page.

Objective-C interop

As Swift matures, the default classes will slowly shift towards the native Swift implementations. And that’s already happening!

In Swift 1.2, Objective-C classes that have native Swift equivalents (NSString, NSArray, NSDictionary etc.) are no longer automatically bridged. That means passing an NSString to a function that expects a String will now fail!

func mangleString(input: String) {
  // do something with input
}

let someString: NSString = "hello"

mangleString(someString) // compile error!

If you want to do this, you’ll need to be explicit with the type conversion:

mangleString(someString as String)

Again, Swift is becoming the first-class citizen here: basically, Swift strings will work whenever some kind of string (String or NSString) is expected. The only change here is when you have those old NSString instances to work with.

NSString quaint

Dealing with optionals

If you’ve been following all the changes to Swift until now, you’ve seen arguments change from UIView to UIView! to UIView? and back again. We were spoiled with being able to message nil in Objective-C, but Swift is much stricter about things.

If you’re maintaining Objective-C code, there are some new qualifiers for you to use when specifying the type for arguments, variables, properties, etc.:

  • nonnull – will never be nil
  • nullable – can be nil
  • null_unspecified – unknown whether it can be nil or not (the current default)

For example, consider how these Objective-C declarations would map to Swift:

  • nonnull NSString *string – a regular object, String
  • nullable NSString *string – this is an optional, String?
  • null_unspecified NSString *string – unknown, thus implicitly unwrapped, String!

If you don’t have Objective-C code to maintain, you’ll still benefit from Apple adding these qualifiers to the Cocoa headers. That will make your Swift experience that much cleaner with fewer implicitly-unwrapped values.

Swift migrator

Xcode 6.3 beta includes a Swift migrator to help automate some of these changes to Swift 1.2.

I made a copy of the official RWDevCon app project and opened it in Xcode 6.3 beta. How far would I get with a build and run?

migration-12-errors

There’s a new menu option: Edit\Convert\To Swift 1.2…. First you select a target and then it’s very similar to how refactoring works – Xcode will churn away and then come back with a preview. You’ll see the old code and new code side-by-side with the changes highlighted.

In this project, all the automated conversion did was suggest changing as to as! all over the place. There was one case of nil coalescing that the migrator didn’t understand:

let date = (data["metadata"] as NSDictionary?)?["lastUpdated"] as? NSDate ?? beginningOfTimeDate

That’s a pretty complicated expression! The migrator got confused and assumed there were two expressions there. The solution? A semicolon, of course!

let date = (data["metadata"] as! NSDictionary?)?["lastUpdated"] as? NSDate ??; beginningOfTimeDate

That’s some kind of syntax error that doesn’t compile. The other additions of as! made sense (and showed how much I rely on forced downcasts!) but this one line needed to be fixed manually.

Note: Your mileage may vary with the migrator on your own projects, of course. Feel free to share your experiences on our forums!

What does this mean for tutorial updates?

We’re very excited about these updates to Swift. However, we won’t start updating our tutorials, books, and videos until the gold master (GM) release of Xcode 6.3 and Swift 1.2 at the earliest.

To be updated sometime after the GM release of Xcode 6.3 and Swift 1.2 – stay tuned!

To be updated sometime after the GM release of Xcode 6.3 and Swift 1.2 - stay tuned!

The team at Apple will continue to tweak things in future beta releases and in our experience, it’s best to wait until the GM to get a good sense of what will ship. We’ll still be keeping an eye on each new beta, and we can’t wait to have our tutorials be compatible with the final release version of Swift 1.2!

If you’ve purchased PDF versions of iOS 8 by Tutorials, Swift by Tutorials, or any book released after and including iOS 7 by Tutorials, you’ll receive updated versions free of charge as and when they’re released. You’ll also see a note added to the top of our free tutorials stating which version of Xcode they’re compatible with.

Where to go from here?

Remember, Swift 1.2 is bundled with Xcode 6.3, which is still a beta – that means you can’t ship your apps with it yet! But you can try things out on a copy of your project and get a feel for how much work you’ll have to do after the final release.

In the meantime, why not try out the beta and see what you think about the changes to the language? You can always contribute back and file a radar with Apple to report a bug or make a feature request – there’s nothing quite like the thrill of having your radar marked as a duplicate, except perhaps when it gets marked as “fixed” and you see your radar number in the next set of release notes. ;]

What do you like or dislike about Swift 1.2 so far? Let us know in the forum discussion below!

Greg Heo

Contributors

Greg Heo

Author

Over 300 content creators. Join our team.