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.
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Contents
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.
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 benil
-
nullable
– can benil
-
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?
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.
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.
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!