Swift 2.0: Apple’s Advanced Programming Platform for Developers
Azilen Technologies, azilen-logo
  by Editorial Team  August 24, 2015

Swift 2.0: Apple’s Advanced Programming Platform for Developers

Feature Image

Over the years, Apple has been devising various gadgets and methodologies for the technology sector. Consequently, it has held the nerve of the market with its innovative digital products and software. Further, the company has also been reinventing its products with advanced features to make them more functional. The Swift 2.0 is one of the latest instances in this regards.

Unveiled at WWDC 2015, Swift 2.0 is an enhanced update with integrated functionalities of its previous version Swift 1.2, thereby providing broader platform for programmers for generating the code. The upgraded version of programming language has been designed more powerful and interfacing for the users.

Check out some of the embroiled specifications of the recently released programming language which include:

Guard Keyword:

Apple introduced a new keyword guard in Swift 2.0 which enables early returns.

Further, it has been specifically designed to filter invalid parameters being passed to a method; hence it becomes easy for everyone to understand when they see its ongoing performance.

Any optional variable unwrapped by guard remains the same in scope after the completion of its process. Meaning, an optional variable could be used ahead after checking its authenticity.

For checking any condition you could now use guard rather than using if. Check out the following code snippet:

func saveInfo() {
guard name.characters.count > 0 else {
print(“You need to provide a name.”)

Defer Keyword:

This is another keyword introduced to Swift 2.0 after guard. Its functionality is more like that of finally keyword in try … catch block in many other modern programming languages. However, defer also includes some other specified features.

Defer has been specialized to execute the block of code before the termination of current scope. Hence, any block of code which used to be executed with the method finally, could now be generated by using defer.

Check out the below example in this regards:

func writeData() {
let file = openFile()
defer { closeFile(file) }

let employeeInfo = fetchEmployeeInfo()
guard employeeInfo = empInfo else { return }

let departmentInfo = fetchDepartmentByEmployee(employeeInfo)
guard departmentInfo = deptInfo else { throw DepartmentError.UnmappedEmployee }

Although, in the above code, defer has been mentioned at the beginning, but it will execute before the method exit.

The closeFile() function in defer block executes even if any of the return statement is called before the termination of method block. That means it does not identify the method end by its scope end but identifies the same by control flow exit from method.

This is what defer is all about. Apparently, if you return from a method at the end or part way through, or if you exit method by throwing an error, you could expect of a deferred work to take place, which would not be seen in case of finally block. This is how defer embroils a bit more than finally block.

Protocol Extension:

Despite based on the platform of object oriented programming, Swift 2.0 appears to be a protocol oriented programming language, when it comes to its protocol extension.

The earlier versions of Swift used to have protocols as interfaces, which define the properties and methods executed from class, struct, or enum. Whereas, you have the options to extend protocols thereby adding default implementations for properties and methods in Swift 2.0. Though, this feature was already available with classes and structs, but once added with protocols makes better approach. While it may initially seem as a minor feature, protocol-extensions tend to change the way of code generation.

The following lines of code explain the same.

protocol Product {
var productId : String { get }
var name : String { get }
var price : Double { get }
var percentageDiscount : Double { get }
var isDiscountAvailable : Bool { get }

protocol Discountable {
var discount : Double { get }

extension Product where Self : Discountable {
var isDiscountAvailable : Bool { return true }

struct iPhone6 : Product, Discountable {
let productId : String
let name : String
let price : Double
let percentageDiscount : Double
let isDiscountAvailable : Bool

var discount : Double {
return ((price * percentageDiscount) / 100)

Two protocols have been created in the above block for product and discount calculation on product. Further, a protocol extension has been used to define that if in case a struct, class or enum implements both protocol product and discountable then the default value of isDiscountAvailable property is always set to true. Hence, it could be very well seen that the adding new protocol extensions make Swift 2.0 a protocol oriented programming language.

Error Handling With New Type ErrorType To Throw Everything:

Error handling is the common feature in all modern programming languages, and swift too is not an exception. It uses enums for error types to assure that error catching is complete.

Consider example in action below:

enum AppError : ErrorType {
case UserError,
case NetworkError

Apart from the new error type, Swift 2.0 also introduced three of the five new keywords: do, catch, try, throw and throws. Additionally, do in do…while is now replaced with repeat keyword which is again replaced with try of try..catch. Consequently, one more new keyword has been introduced for do of do…while replacement that is repeat and is sentenced to repeat…while.

func performSignUp() throws -> Bool {
guard self.isNetworkReachable else { throw AppError.NetworkError }
guard self.signUpSuccessfull else { throw AppError.UserError }

return self.doSignUp()

In example above, the throws keyword is used in method signature that specifies that this method may throw an error at runtime, and while on the other hand, the throw keyword is used in method definition which throws error in a specified predefined condition.

This part of example only show that how we can manage to throw our own user defined errors in Swift 2.0, but to handle or catch an error at runtime. Just take a look-

do {
guard self.performSignUp() else {
print(“Your are successfully signed up, thank you.”)
} catch AppError.NetworkError {
print(“We have faced some network related issue, please check your internet connection, and try again later.”)
} catch AppError.UserError {
print(“Please verify your user details, and try again.”)
} catch {
print(“Something went wrong, while signing up.”)

To handle or catch an error we use do…catch statement in Swift 2.0. In addition, catch allows specifying an error type to catch/handle. But jut hold on! Swift 2.0 also have one more feature to describe a generic error which we may not specify at design time, but can be identified at runtime. This is also known as exhaustive error handling in Swift.

Let’s see an example to understand this in detail :

enum AppError : ErrorType {
case UserError,
case NetworkError,
case Undefined(String)

func performSignUp() throws -> Bool {
guard self.isNetworkReachable else { throw AppError.NetworkError }
guard self.signUpSuccessfull else { throw AppError.UserError }
guard self.password.character.count > 5 else { throw AppError.Undefined(“There is problem with your password.”) }

return self.doSignUp()

let userInfo = try! performSignUp()

Using try! keyword specifies that the call cannot fail then whatever may be the reason. This is a decision which needs to be taken on a case-by-case basis by the programmer.

So, try! keyword is the best to be used for indicating Swift that this call will not fail.

Automatically Synthesized Headers:

In objective-C, header files provide a list of functionality exposed by the class mentioning about the available methods along with the parameters that they take, but with none of the code.

Swift doesn’t have header files, which means you write all your code in a swift file, without worrying about updating the header files. Instead, keyword like private is used to show how methods should be exposed to the outside world. But in loosing header files, swift lost the functionality of determining the functions included inside a class. So, to avoid going through the whole file, just in case to know about the functions, Apple provided a solution for this issue through Xcode. It is able to show the synthesized header files by scanning through code and producing virtual header files that summarize the exposed methods with none of the code, just like you see if you try to inspect any of the Apple’s own classes.

In order, to create a header file for swift class in Xcode 7, go to Navigate > Generate Interface.

Availability Checking:

Before Swift 2.0 if checking of the version compatibility was used to check by generating a code that determine the OS version like:

if NSProcessInfo().isOperationSystemAtLeastVersion(NSOperationSystemVersion(majorVersion:9, minorVersion:0, patchVersion:0)) {
print(“Do you stuffs…”)
} else {
print(“Current system version is lower than iOS 9”)

This used to lead to a lot of problems at developer’s end, and required the developer to know about the availability of the particular API on the least version specified in the app setting.

With Swift 2.0 and Xcode 7 Apple introduced API availability checking. If you set your app’s deployment target to a lower iOS release than the base SDK, Xcode will automatically scan every API you use to make sure it’s available in your lowest deployment target version. This piece of information was there in Apple’s API headers since many years, but it’s now only being exposed to the compiler. With this information compiler you could make sure that your project doesn’t contain any code that can’t run because of missing APIs.

By default, Swift compiler will compare your actual usage against your minimum deployment target and if it finds any unavailable API, then it will give you an error.

We can now check the version with available keyword in Swift 2.0, easily and there is no need to remember the lengthy code just for checking OS version. Let’s see this with an example below:

func performTask() {
guard #available(iOS 9, *) else {
// Do your stuff here…

In the code above #available will check whether, we are on iOS 9 or later, or any other unknown platform like WatchOS – that’s the * at the end, and it’s required. But this will only prevent a particular part of code in a function. But what if you want to prevent entire function or class from a lower OS version?
Swift 2.0 has province for such scenarios too.

Now with Swift 2.0 we can mark a check on entire method or class using @available keyword as shown in example below:

@available(iOS 9, *)
func iOS9Work() {
// do stuff

Renamed Syntax:

As mentioned earlier, with Swift 2.0 there are many things renamed in the syntax. The do…while is now changed to repeat…while, println function is no more available from Swift 2.0 rather now its renamed to old simple print function with an addition of a default argument set to true which indicates whether to print a new line or not. The Printable protocol is now renamed to CustomStringConvertible.

To conclude, Apple with its iOS application development along with Mac OS brings in Swift 2.0 with wide range of features. Meanwhile available for developers, Apple confirms that Swift 2.0 would be an easier programming platform for the programmers.

Come Partner With Azilen

We serve consultation from small and medium start-ups to veteran product owners with our Pro-360 Approach, which is adapted to your product and business!