What's New in Swift 2.2 for a Swift App Development Company

06 May 2016

What's New in Swift 2.2 for a Swift App Development Company

Sharethis

Posted by Root Info Solutions

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:

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:

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?:

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:

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.