I’ve been teaching iOS for many years—in the United States, in Europe, and in Latin America primarily—and I can tell you from personal experience that the arrival of Swift 3.0 is going to be met with excitement across the globe. While new versions of a language can seem intimidating, Swift is open sourced, so we know what’s coming, and we can watch it as it happens. In this post we’ll take a look at the features that have been added, and the bugs that have been excised, so we can understand what Swift 3.0 will mean for all of us. But first, a little personal history!
Flashback: On the eve of a Swift Conference
About two years ago, I was staring at my Mac, and feeling pretty satisfied. I had just completed my “Intro to Swift” workshop for the NSSpain Conference, and I was confident the material was strong. Three hours’ worth of condensed Swift wisdom providing highlights of the new language, and representing a clear path forward towards adopting Swift, and moving away from Objective-C.
At that time I was still living in Madrid, and the drive to Logroño (where the conference was being held) would take me about 3 hours. My workshop started the next day at 9 am, so I had plenty of time. I gave a last loving look at my computer, then suddenly saw a notification on my screen I hadn’t seen before: “New updates are available!”
“Go ahead and install!” I told myself. “That way you’ll have the latest version tomorrow!”
What could possibly go wrong?
Well, you probably know where this is going. The latest version of Xcode wouldn’t open my playground project. My code was broken. The playground wouldn’t compile. I looked around my suddenly forlorn room and thought to myself, “I’m doomed.”
Fast forward: Here comes Swift 3.0!
If you’ve been doing Swift development since the beginning, this tale probably seems familiar. Developing for a language while it’s still being designed can be exciting, but there are perils. At that early stage, backwards compatibility was not a consideration! However, it’s a new era now, and we have a much better language today than we had with Swift 1.0.
Great features have been added, and most importantly, bugs and mis-features were mercilessly excised. The process was painful along the way—books had to be rewritten, courses had to be redesigned, and code had to be refactored. But, as we close in on the annual Worldwide Developers Conference held by Apple in San Francisco (WWDC 2016), I think it’s safe to say we’re all looking excitedly forward to the arrival of Swift 3.0. As recently noted in a ComputerWorld article:
Apple is expected to introduce Swift 3.0 at WWDC 2016 and to release it in Fall. One of the more dramatic goals in this iteration is portability, to “make Swift available on other platforms and ensure that one can write portable Swift code that works properly on all of those platforms,” the Swift Programming Language Evolution pages reveal.
What does Swift 3.0 mean for us?
As mentioned above, Swift has been open sourced, so we can now know ahead of time what will change and when. We can collaborate, or at least observe the evolution of the language and plan ahead. One of the most significant things to know about the arrival of Swift 3.0 is that it will be the last version of the language to break existing code. So while you will have to substantially change your code, at least you’ll know ahead of time what will break, and you can take heart that this will be the last time!
Changes in Swift 3.0
Most of the changes that affect application developers in Swift 3.0 fall into 3 major categories:
- Integration with Objective-C existing code
- Features being removed
- Future Transformations
Let’s take a look at each of these categories.
Integration with Objective-C
It’s safe to say that Swift and Objective-C are very different languages, and getting them to work together is no easy task. But, Swift 3.0 will definitely make some key things easier. For example, the way Objective-C method names are translated into Swift will change and the resulting Swift names will feel less alien.
Names will get shorter and won’t have types in them. For instance, in Objective-C, it makes sense to call a method of NSString “stringWithFormat:”. That “string” part is there because Objective-C’s compiler considers type information merely as suggestions, while Swift is far more strict.
Therefore, there’s no need in Swift to include type names in method names. It is redundant and will rightfully be removed.
In a nutshell, with Swift 3.0, methods imported from Objective-C (and that includes almost every single framework out there!):
- will be shorter
- will provide default values when it makes sense
- will better handle receiving and returning nil.
In other words, they will be “swiftier!”
It should be noted that there’s nothing you can really do to get ready for this. You just have to wait. However, the conversion of your code should be automagically performed for you by Xcode.
Features being removed
The removal of features is always a bit problematic, as one developer’s beauty mark is another’s unsightly wart. But regardless of how you feel about it, these features are going away!
C-Style For Loops
C-Style for loops are going away, so it’s definitely time to get used to for-in loops:
// This will cause a warning in Swift 2.2 and an error in 3.0 // Deprecated in 2.2 and removed in Swift 3.0 for var i = 0 ; i < 10 ; i++ { print(i) }
The rationale for removing them is that they are prone to off-by-one errors, and there is a safer alternative.
So, if you are using them, it’s time to stop, and use a for-in loop instead!
for var i in 0..<10{ print(i) }
The increment (++) and decrement (–) operators
Increment and decrement operators are closely tied the to the C-Style for-loops, so it makes sense for both to be removed.
The rationale for getting rid them is that they are prone to confusion and they’re the cause of subtle bugs. And really, what is the difference between ++i and i++ anyhow? You shouldn’t have to care about that.
So, start getting rid of them in your own code:
++i //becomes i = i + 1
Range initializer
The Range struct is also related to for-loops. Oddly enough, it represents a certain range through which you can iterate.
Therefore, if you want to iterate from 1 to 9, you may express this in 2 ways:
// from 1 to 9 (included) for var i in 1...9{ } // from 1 to 10 (not included) for var i in 1..<10{ }
The … and ..< operators initialize a Range instance. Until recently, you could also use a regular init:
var z = Range(start: 1, end: 5)
But, not anymore. This init is deprecated in 2.2 and will go away in 3.0. If you use it, it’s time to stop, and start using the operators.
Syntax for curryed functions
This is one of those wart/beauty mark things, and its demise will likely infuriate some hardcore functional programmers.
(Historical note: The concept of a curryed function was named after the mathematician Haskell Curry, who also inspired the programming language called Haskell!)
Let’s start with a regular function that takes 2 integers and returns the sum:
func sum(x:Int, y:Int)->Int{ return x + y }
So far so good. However, the same concept could be expressed with a function that instead of taking 2 arguments in one gulp, takes them one at a time. In this case, it would take x and return a function that takes y and adds it to x.
func currySum(x:Int)(y:Int) -> Int{ return x + y }
The magic cookie is the (x:Int)(y:Int) part. This is going away.
Not sure if this is useful? In functional languages that support currying natively, this is an extremely powerful tool to specialize behavior. In Swift however, we have other options for specializing the behavior of our code: namely inheritance and protocols.
Var in function arguments
Most of the time, the arguments to a function are immutable. For example, in our previous function, sum cannot change x or y.
On the other hand, if you want to allow the function to modify the parameters, it’s usually because you need to observe that modification from the outside.
Swift has 2 ways of doing this:
//The function can modify the parameters, but you won't see the modification //from the outside. This is useless and is going away. func f(var x: Int)->Int{ x = x + 42 return x + 1 } var z = 0 f(z) z // z is still 0!
The other option, which allows us to see the changes from the outside, is by using inout:
func f(inout x: Int)->Int{ x = x + 42 return x + 1 } var z = 0 f(&z) z // z is 42!
The bottom line is this: if you are using var parameters to a function, you should stop now. Change it to inout, and make sure you understand what inout does.
Future Transformations
As is clear from what we’ve just outlined above, Swift 3.0 is largely about removing old features, and less about adding new ones. There are actually very few completely new features being added. If you are a Swift developer, probably the best thing you can do to familiarize yourself with what’s coming, and to understand the changes, is to read the Swift Guidelines. This document essentially defines what “swifty code” means. You should read it, print it, have it next to you, and of course, follow it in your own code.
As noted at Swift.org, “One of the goals of the Swift 3.0 release is to provide a set of API design guidelines for writing Swift code.” This is a pretty big deal, which the headline of another Swift.org article makes clear: It’s Coming: the Great Swift API Transformation.
When looking at our APIs, it’s easy to see there’s room for improvement, both in the way the compiler imports Objective-C APIs—where the results just don’t seem quite comfortable in Swift—and in the Swift standard library, which lacks a level of regularity and coherence that Cocoa users have come to expect.
Note for Udacity students of our Beginning iOS App Development and iOS App Developer Nanodegree programs: Swift 3.0 will not be supported until its official release. Projects should continue to be submitted in the latest, stable version of Swift. We are awaiting the newest release with as much excitement as you are, and we look very forward to updating our course content right after the release, and to teaching you the ins and out of Swift 3.0!
Conclusion
Swift 3.0 will be a big change, and an exciting one. It’s still a change that will break our code, but it should be the last one, and honestly, the changes really are about removing undesired features, and that’s definitely progress!
Mainly, what we want to focus on are the results, and there’s nothing but good news there—the language will emerge simpler and more powerful, and without this unnecessary weight, it will fly higher and “swifter.”
Put another way, it’s a great time to be a Swift developer!
