Welcome to the blog on Root Info Solutions. In less than 6 months after being declared as an open source programming language (December 2015), Swift has shifted swiftly to a major overhaul. Yes, Swift 2.2 has got released. Interestingly, it is an intermediate phase between Swift 2 and Swift 3. Let?s see what it stores for a Swift app development company and how new features can empower its iOS developers to build a new app or redesign an existing one to match the client?s needs.
Compile-time Swift version checks
The disparity in the Swift versions usage often led to confusion amidst Swift app developers and was a prominent cause of delay in Swift app development. Thanks Swift 2.2 has got the solution. Instead of applying runtime version check that was part of its previous version, Swift 2.2 does compile-time version check.
Being a Swift app developer, mark blocks of code to let the compiler easily identify what to read in the primary condition and what in the else situation. For example:
#if swift(>=3.0) print("Running Swift 3.0 or later")
#else print("Running Swift 2.2 or earlier") #endif
Thus, the compiler will read codings written either using Swift 3/higher version or Swift 2.2/lower version. A code failing the language version check remains invisible.
Note: To use this compiler-time check functionality, you need to wait for Swift 3.0 as the current Swift 2.1 compiler will choke on with #if swift(>=2.2) as it can?t understand what does it mean.
Compile-time checked selectors
For Swift 2.1 compiler there is nothing wrong with the below code as it has got the right syntax.
override func viewDidLoad() {
super.viewDidLoad()
navigationItem.rightBarButtonItem =
UIBarButtonItem(barButtonSystemItem: .Add, target: self,
action: "addNewFireflyRefernce")
}
func addNewFireflyReference() {
gratuitousReferences.append("We should start dealing in black-market beagles.")
}
However, the app will crash? Reason - the navigation bar button calls a method addNewFireflyRefernce() ? where one of the Es is missing in ?reference?. Luckily, Swift 2.2 brings a fix for that too. It deprecates using strings for selectors and favors the use of new syntax: #selector. The syntax will check whether the method you want to call actually exists. If it doesn?t exist, then you get a compile error: Xcode will refuse to build your app, thus banishing to oblivion another possible source of bugs.
More keywords as argument labels
Swift has an extended list of keywords like class, func, let, and public with precise meanings that ease argument labeling and help Swift app developers to work together. However, every keyword needs to be placed in backticks like this:
func visitCity(name: String, `in` state: String) {
print("I'm going to visit \(name) in \(state)")
}
visitCity("Nashville", `in`: "Tennessee")
Swift 2.2 doesn?t have a fix list of keywords. Any keyword, with the exception of inout, var and let can be used. If your code has got keywords in backticks, you can remove it using Xcode Fix-it.
Tuple comparison is built-in
Comparison of two tuples becomes easier with Swift 2.2. Every element is compared and a reporting is made available to the Swift app developer. However, not more than 6 elements can be compared. For example, the below code will print ?No match?:
let singer = (first: "Taylor", last: "Swift")
let alien = (first: "Justin", last: "Bieber")
if singer == alien { print("They match! That explains why you never see them together?")
}
else {
print("No match.")
}
One warning: Swift 2.2 will ignore your element names when checking for equality, sosinger and bird will be considered equal in the code below:
let singer = (first: "Taylor", last: "Swift")
let bird = (name: "Taylor", breed: "Swift")
if singer == bird {
print("This explains why she sings so well.")
}
else {
print("No match.")
}
Tuple splat syntax is deprecated
Tuple splat syntax has been removed from Swift 2.2 as it?s no longer in use. Earlier it was used to fill the parameters of a function. The nomenclature of tuples was quite interesting. It was dependent upon the number and type of elements contained in it. For example:
func describePerson(name: String, age: Int) {
print("\(name) is \(age) years old")
}
let person = ("Malcolm Reynolds", age: 49)
describePerson(person)
This syntax ? affectionately called ?tuple splat syntax? ? is the antithesis of idiomatic Swift?s self-documenting, readable style, and so it?s deprecated in Swift 2.2.
C-style for loops are deprecated
Swift 2.2 is planning to bid farewell to C-style for loops as they are rarely in use. Existing C-style loops can be converted into the modern ones by using Fix-it. For example:
for var i = 0; i < 10; i++ { print(i) }
The deprecation has started in Swift 2.2 and is likely to get over in Swift 3.0 ? one more step towards never typing a semicolon again.
++ and -- are deprecated
Don?t get surprised, even if you have to go without ++ and -- in the latest update of Swift. Both have been deprecated, both as prefix and postfix operators. Hence, code such as for var i = 0; i < 10; i++ contains not one but two deprecations. Therefore, we recommend you not to use i++ i-- ++i --i i = i++ in Swift 3 app development.
var parameters are deprecated
Function parameters, represented as var, have also been shown the exit gate in Swift 2.2. Though they provided a helpful shortcut to Swift app developers, they do added some extra dose of confusion. For example,
func greet(var name: String) {
name = name.uppercaseString
print("Hello, \(name)!")
}
var name = "Taylor"
greet(name)
print("After function, name is \(name)")
What would be the print()statement output ?Taylor? or ?TAYLOR?? The inclusion of inout keyword adds complexity to the output. If we use inout rather than var in the example above, and then add a single ampersand, we get:
func greet(inout name: String) {
name = name.uppercaseString
print("Hello, \(name)!")
}
var name = "Taylor"
greet(&name)
print("After function, name is \(name)")
When run, the var example generates different output to the inout example. Reason? Changes to var parameters are applicable inside the function whereas changes to inout parameters influence the original value.
Renamed debug identifiers
Last but not the least, appearance matters for Swift 2.2. Sound strange but that?s what we can interpret from its resolve to deprecate terms like __FILE__, __LINE__, etc., that look harrowing, sorry to say but use of capital letters instills that perception in the mind. With a bid to replace them, Swift 2.2 gives way to #file, #line, #column, and #function. # means invoke compiler substitution logic here.
func visitCity(name: String, in state: String) {
// old - deprecated!
print("This is on line \(__LINE__) of \(__FUNCTION__)")
print("I'm going to visit \(name) in \(state)")
// new - shiny! print("This is on line \(#line) of \(#function)")
Hope, the discussion was helpful, and you have gained the basic nuances required to migrate effortlessly to Swift 2.2. To get live updates on Swift app development, connect with us on Facebook, LinkedIn and Twitter.
