Swift 2 Blueprints

4.6 (7 reviews total)
By Cecil Costa
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Exploring Xcode

About this book

In this book, you will work through seven different projects to get you hands-on with developing amazing applications for iOS devices.

We start off with a project that teaches you how to build a utility app using Swift. Moving on, we cover the concepts behind developing an entertainment or social networking related application, for example, a small application that helps you to share images, audio, and video files from one device to another. You’ll also be guided through create a city information app with customized table views, a reminder app for the Apple Watch, and a game app using SpriteKit.

By the end of this book, you will have the required skillset to develop various types of iOS applications with Swift that can run on different iOS devices. You will also be well versed with complex techniques that can be used to enhance the performance of your applications.

Publication date:
October 2015


Chapter 1. Exploring Xcode

Programming is not only about code, it is also about methodology. It doesn't matter how many years you've been programming with Xcode, there is always a new feature that can speed up your development, mainly nowadays that there is a new version every few months. Don't forget that Swift is a new language created to replace the old Objective-C, which means that Xcode also needs to adopt new features for this new programming language.

This book is about creating applications with the Swift programming language using Xcode 6 as an IDE. The idea behind these apps is to show how to create different kinds of real apps from scratch and this chapter presents with you some tricks on how to use Xcode.

Even if you are already a developer with years of experience in Xcode, it is worth reading this chapter because there is always a different way to do a task and it can be very helpful. So, let's start reviewing some Xcode and Swift features. In this chapter, we will cover:

  • Keyboard shortcuts

  • Versioning your project

  • Testing with Playground

  • Debugging

  • New Swift features

  • Some final comments


Keyboard shortcuts

Have you ever thought of how much time a developer expends in moving the mouse pointer? It can be a lot of time. How about reducing some time by memorizing a few key combinations. Of course, don't expect to memorize all of them in a day. You can practice them when it is necessary; you will see that, after a while, you will save a lot of time. Of course, command + X, command + C, command + V, and command + Q are not going to be mentioned for they are assumed to be known.

The first shortcut we are going to learn is command + B, which is to build the solution without running it on the device or simulator. This key combination is very useful when you want to check whether the project has any errors, but you don't want to waste time installing the app.

Sometimes, mainly when you have Swift and C on the same project, the compiler caches the object files wrongly, so the best solution would be to clean everything up and recompile again. To clean your entire project, use the command + shift + K combination. Cleaning is a fast process, nevertheless, you have to remember that afterward you need to rebuild your project, which might take a while.

If you want to build your product and run it, you have two options. The first is command + R that compiles your project if it is necessary and installs it on the device or simulator; this combination is equivalent to pressing play on the left-hand side of the toolbar. The second option is control + command + R, which installs the last build but doesn't rebuild the project; it is very handy when your project takes a long time to compile and you just want to reinstall it again for testing.

Now, let's learn some key combinations that will affect Xcode, visually speaking. On the left-hand side, we have the Navigator. As you know, here is where you can access the project files, the search results, and the compilation status. The following screenshot shows a sample of the Navigator:

If you need more visual space, you can hide the Navigator area with command + 0, or you can show this area using the same combination. It is very useful when you have a small screen like a MacBook screen and you need to work with the interface builder or Playground.

As you can see, there is a bar on the top (called the Navigator bar), which allows you to access different sections of the Navigator. You can click on each icon or you can save some time by pressing command + a number from 1 to 8, 1 being the project navigator (folder icon), 2 the symbol navigator, and so on till 8, which is the report navigator.

Every Navigator section has a text field at the bottom to filter the content that is being displayed on the Navigator. You can reach this text field very fast by using the command + option + J combination. So, based on the previous combination, when you need to access a file, you can go to the project navigator by pressing command + 1 followed by command + option + J.

To finish with the Navigator area, you should know that you have a shortcut to go to the project navigator and highlight the current file, it is command + shift + J.

The area on the right-hand side is called the Utility area and its combinations are similar to the Navigator area. This area can be hidden or shown with command + option + 0, its sections can be accessed with command + option + a number from 1 to 6, and its filter can be reached with command + option + L. The following screenshot is a sample of the Utility area:

The area located between the Navigators and the Utility area at the bottom of the Xcode screen is called the Debug area. This area can be shown or hidden with command + shift + Y. Here, you have some debug combinations like command + Y to enable or disable breakpoints or pause or resume the application with control + command + Y. There are more debugging keyboard shortcuts; as they require the use of fn keys (F6, F7, F8), it can be complicated according to your keyboard. Here, you have a sample of the Debug area:

Now, the central area, which is the most important one, is called the Editor area. Here, as you know, is where you type your code. Scrolling up and down could waste a lot of time, so let's learn some shortcuts that will make us find our code faster. The first combination is command + F that opens a text field to search in the current file.

When you need to search in the whole project, you can use the command + shift + F combination, which is much faster than a click on the loupe icon and a click on the text field. Another similar combination is command + shift + O (letter O, not the number zero), which is called Open Quickly…. This combination opens a text field in front of your editor area and allows you to search for symbols. It also allows you to type the first letter of each symbol word, like the following example in which NSHD was typed and it was able to find NSHomeDirectory.

Open Quickly searches for symbols in the current project and also inside the frameworks. But if you like to jump to a symbol (method, property, global variable, and so on), you can use control + 6 as it opens the combo box that is located at the top of the editor area like in the following screenshot:

To navigate through the files you've been using, you can use control + command + ← to go to the previous files or control + command + → for the next one. Alternatively, you can slide with two fingers on use the touch pad if you have one.

When you have a code that is quite difficult to understand because it is not well-formatted, you can use the control + I combination. If you have selected some lines, only these lines will be arranged. If no line is selected, then the current line of code will be formatted.

To finish this shortcuts section, it is worth mentioning that you have command + \ to toggle breakpoints and command + / to toggle the selected line comments.

Don't worry if you think that there are too many combinations to memorize or if some of them are hard to do, you can always check the combination and customize it if you want by opening the Xcode menu, selecting preferences, and opening the Key Bindings section like in the following screenshot:


Bear in mind while customizing your shortcuts that when you work on another computer, you will have to set them up again.


Versioning your project

Every project should have a version control system, even if you are the only developer. Xcode works with Git as a default VCS, which has a special way of working.

Firstly, you have to know that Xcode offers you just the basic usage of Git; there are times when you might need to use the command line.

You can use Git in two ways: locally only or remote and locally. The first one is usually done by single developers and can be done very easily by checking this option when you have to select a folder for your new project. The following screenshot shows the option that needs to be checked in the file dialog:

The second way of working with Git is to use it remotely and locally. What does it mean? It means that you can create versions of your code locally and when you think that it is ready to be shared with the other members of the team, you can send it to the server. To do so, you have to configure a server by yourself or you can use this service from a third-party company, such as GitHub or BitBucket.


Recently, Apple announced the Xcode server, where you can configure your Git server and also a continuous integration system. Explaining how to configure this server can be very exhausting and is out of the scope of this book. However, if you would like to create your own server, you can have a look at this possibility.

As a developer what you need to work with a remote repository is its URL. You have to request it to the system administrator or you can copy it from the website where you created it. GitHub, for example, shows it on the right-hand side with a button to copy the URL on the clipboard, as you can see in the following screenshot:

Once you have the URL, you can check it out by selecting the Check out an existing project option on the start up screen, as shown in the following screenshot. Or, you can click on the Source Control menu and select the Check out... option.

Once you have your project checked out and have started working on it, it doesn't matter whether it was created from a server or locally only. You will notice that when a file is modified, letter M will appear next to your file name on the project navigator. Letter A will also appear when a new file is added to the project. The next screenshot shows a sample of some files that were added or modified:

Note that letter M can also appear next to your project; it means that something in the project.pbxproj file, which is inside of your project package. This file contains the information of your project like the source code files with their path and the settings; hence, you have to deliver it every time you add a file or change any setting.

To commit the modified and new files, you just need to use the command + option + C key combination. A dialog asking for a description of the modifications will appear, leave a message in a way that another developer understands what was done.


Avoid committing without leaving a comment, or just leaving a nonexpressive comment like "modifications." Comments are very useful to check the project's progress and fix bugs.

These commits are done locally by default. It means that only your computer knows about your modifications. If you want to send your commits to the server, don't forget to check the option that is under the comment box, as it is demonstrated in the next screenshot:

The other way around, which means receiving updates from the server, is called pull. To do a pull from the server, you just need to press the command + option + X combination key.


Testing with Playground

Playground is a new Xcode 6 feature that allows the programmer to see the Swift code result before it is added to the project. This way, you can test your code separately from the project, receive real-time execution and feedback, and apply it when you are really convinced.

You can use Playground as if it were a separate project by navigating to File | New | Playground…. This way, you can do your tests without saving it with the rest of the project.

The other use of Playground is to add it to your project, so you can save your tests with your project. To do this, just add a new file with command + N, select the iOS Source section, and select Playground, as shown in the following screenshot:

Even if Playground is inside your project or workspace, it won't be able to use your project classes. It means that you might have to copy some files into your Playground and be aware of the modifications, as they are considered to be different containers with their own dependencies.


Don't use Playground to benchmark or test sensors. It wasn't done for this purpose.

Let's make a sample to create a customized view with Playground. We will create a class called CustomView, which inherits from UIView. Add a yellow background and a red border. Place the following code to start testing with Playground:

class CustomView: UIView {
    override init(frame: CGRect) {
        super.init(frame: frame)
        self.layer.borderColor = UIColor.redColor().CGColor
        self.backgroundColor = UIColor.yellowColor()

    required init(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")

Just below the code, you can create a frame and instantiate it:

var frame = CGRectMake(0, 0, 100, 100)
var myView = CustomView(frame: frame)

On the right-hand side, you will see the word CustomView appear. Move the mouse over this word and you will see two small icons appear. One of them is an eye called Quick Look. If you click on it, an image of your view will be displayed, as you can see in the following screenshot:

Here, for example, we can see that something is missing: the red border! The reason is that we are yet to set its width. Let's return to the initializer and add a border to our view:

        super.init(frame: frame)
        self.layer.borderWidth = 2
        self.layer.borderColor = UIColor.redColor().CGColor


Downloading the example code

You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

Now, you can check your view again using Quick Look. But if you want to get faster results, you can click on the circle icon that is to the right of the Quick Look icon. You will see your square under its declaration. Have a look at the following screenshot to see the expected result:

Let's make another change and see how fast Playground gives us results. Add a round corner to your view with the following code:

self.layer.cornerRadius = 15

As you could see, the Playground took approximately 1 second, as it needs to recompile the code, execute it, and retrieve the result. Don't think about what the sample does by itself. What you do have to think about is how much time you expend testing it on an app every time you have a change and how much time you expend testing it on Playground.


For more information on how to use Playground, you can read Swift Cookbook by Packt Publishing.



Debugging is an everyday task for a developer that is usually done to fix a bug. There is no right or wrong way for debugging, and there is no formula to find where the issue is. On the other hand, we have some tricks that can help us find where the bug is. In this section, you are going to see some of them. They can be very useful if you would like to modify any app in this book and you don't get the expected result.

First of all, let's see a common problem. Swift was created to be compatible with Objective-C and Objective-C in its early days was created to be some kind of Smalltalk over the C layer. The idea at that time was to create a language where containers and functions didn't need to be of only a specific type like an array of integers, even the value returned from a function could be of any type. You can see, for example, NSArray, NSDictionary, and NSSet that can store NSString, NSNumber, and the objects of any other class in the same container.

How Swift receives this kind of information? One way is by using generics but, usually, they are received as AnyObject. Sometimes, the debugger is not able to show you the right variable type. For a better example, have a look at the following code:

var request = NSURLRequest(URL: NSURL(string: "http://date.jsontest.com/")!)
NSURLSession.sharedSession().dataTaskWithRequest(request) { (data, response, error) -> Void in
    var json = NSJSONSerialization.JSONObjectWithData(data, options: .MutableContainers, error: nil)
    // json Type???

In this case, you can ask yourself what is the JSON variable type? Of course, the first step is to check the debugger information, but you might get some information like the following one:

You can check with the is operator like if json is Int, but it can be very exhausting and, sometimes, even impossible. For scenarios like this, you can use the _stdlib_getDemangledTypeName function, which displays the variable type name. In this case, we can add the following println instruction to our code, as it is shown in the next code:

    var json = NSJSONSerialization.JSONObjectWithData(data, options: .MutableContainers, error: nil)
    println("json variable type: \( _stdlib_getDemangledTypeName(json!) )")

Now, you can see on the log console that, in this case, it is a dictionary as follows:


In Swift 2, many functions have changed their input or output header from AnyObject to a specific type, making life easier for developers.

Another important thing to bear in mind is lldb, which is the debugger command line. It can look complex and not much intuitive, but when you get used to it, it is very useful and logical. For example, you can set breakpoints using a pattern like br s -r viewDid* to add breakpoints in functions like viewDidLoad and viewDidAppear.

Of course, there are tasks that you can do with lldb and also with Xcode like using the lldb command po [[UIWindow keyWindow] recursiveDescription], which gives you the window view hierarchy, or simply using the new Debug View Hierarchy button (displayed next) that comes since Xcode 6, which gives you 3D information on the current view.

Once it is pressed, you can rotate the image and have an output similar to the following screenshot:

A very common problem in our apps is the excess of memory usage. When we start receiving memory warnings, we need to check the amount of memory that is being increased in some parts of our code. To do it, just keep a function to retrieve the memory whenever you want. The following code is valid to retrieve the amount of memory that is being consumed:

func getMemoryUsage() -> mach_vm_size_t{
    let MACH_TASK_BASIC_INFO_COUNT = sizeof(mach_task_basic_info_data_t) / sizeof(natural_t)

    let flavor = task_flavor_t(MACH_TASK_BASIC_INFO)
    var size   = mach_msg_type_number_t(MACH_TASK_BASIC_INFO_COUNT)
    var pointer = UnsafeMutablePointer<mach_task_basic_info>.alloc(1)
    let kerr = task_info(mach_task_self_, flavor, UnsafeMutablePointer(pointer), &size)
    let info = pointer.move()


    if kerr == KERN_SUCCESS {
        return info.resident_size
    } else {
        let message = String(CString: mach_error_string(kerr), encoding: NSASCIIStringEncoding)!

Then, call this function in some parts of your code where you think there is memory wastage and print it like the following code:

println("File: \(__FILE__) at line \(__LINE__) memory usage \(getMemoryUsage())")


There are third-party products that can also help you to debug your app like Fabric (http://www.fabric.io) that sends reports on user crashes to the developer.


New Swift features

Swift is a new language, but it has been changed a few times. While this book was being written, Swift had passed through the 1.2 and 2.0 versions. These versions have some syntax differences compared to the previous ones.

Before the Swift 1.2 version, you couldn't use more than one let statement on an if statement, so you probably had to write codes like the following one:

    if let name = product.name {
      if let category = product.category{
        if let price = product.price {
          if price >= 0 {
            println("The product is valid")

Now, you can reduce the number of lines and write a code like the next one:

    if let name = product.name, category = product.category, price = product.price where price >= 0 {
      println("The product is valid")

Constants can be initialized after their declaration and before using them, like the following code:

    let discount:Double
    if onSale {
      discount = 0.2
    }else {
      discount = 0

Downcasts and casts that don't return options must use the as! operator instead of the old as operator. It means that the casting from typical functions that return AnyObject must use the new operator. For example, the call to retrieve the index paths of a table view will be as follows:

var paths = tableView.indexPathsForRowsInRect(rect) as! [NSIndexPath]

If you have a huge project done with the first Swift version, you might be scared about the number of errors you have for small things like using the new as! operator. Fortunately, there is an option to update our Swift code in the Edit menu in order to convert our code to the latest Swift version syntax, as it is demonstrated in the following screenshot:

When Swift was announced, it brought with itself new data types that replaced the equivalent Objective-C containers, such as Array for NSArray, String to replace NSString, and Dictionary for NSDictionary, but there was a missing type: NSSet. Now, there is Set that follows the same rule as its colleagues: it must specify the data type that it will store (generics) and it is interchangeable with NSSet.

A new attribute was introduced in the Swift language, it is called final. If you have a final class, no class can inherit from it. If you have an attribute or a method, you can't override it.


Some final comments

Working with someone else's code might be a difficult task; you have to figure out what is the logic of the previous developer and how you could change the code to fix a bug, for example. This is the reason why developers must think like a team, act as a team, and work in a team. What does this mean? As a part of our tasks, we should help the next developer by adding comments for them. Swift has its own features based on comments.

Firstly, an interesting part is that Swift allows nested multiline comments. It means that a comment like the following one is not going to stop before println like the other languages do:

          This code was removed due to it is a bit buggy
            for i in myArray {

Another good thing that we could do with comments is to mark the current state of development. This is equivalent to the #pragma preprocessor in Objective-C. Let's start with // MARK: -, this allows us to add a title before each section of our class. For example, imagine that we have a big class, so we can use this mark to show which methods belong to the base class, which ones belong to the delegates, and which ones are private methods. In this case, we would have a code similar to the following one:

    // MARK: - Overriden functions
    override func viewDidLoad() {
    // continue overriding some methods
    // MARK: - Delegates
    func tableView(tableView: UITableView, willDisplayCell cell: UITableViewCell, forRowAtIndexPath indexPath: NSIndexPath){
    // continue writing some delegates methods
    // MARK: - private methods
    private func createTitle(cellNumber: Int) -> String {

In this case, when you click on the editor's combo box (or press control + 6 as we learned before), you might see a combo similar to the following screenshot:

This kind of mark can also be used to reach a differentiated code (something you might check frequently) but, in this case, it is recommended to use it without the dash character, something like // MARK: Important code, and it can be done anywhere, even in half a function. Removing the dash from // MARK: removes the dividing line in the combo box.

When you have an incomplete code or task, you can mark it with // TODO:, meaning that something is pending in this area. For example, imagine that there is a code that is hardcoded and it is desired to load the information from a configuration file. You might have a code similar to the following:

// TODO: Retrieve this IP address from the configuration file
return ""

The next mark we have is // FIXME:, it represents that this part of the code has a known issue and it should be fixed. Something like the following:

// FIXME: The app hangs when there is not internet connection


Try to search for TODO: and FIXME: frequently or do a script that searches for them. There are times when there are too many codes to fix and nobody cares about it.

While you finish this part, don't forget that a well-documented code is a helpful code. When you hold the option key and click over a symbol, you will see some information on that symbol, like the NSURLRequest box shown in the following screenshot:

You can display equivalent information from your classes, methods, and properties by using HereDoc. The idea is very simple; you can take advantage of the comments by starting with ///, followed by its description as follows:

/// A class that represents a garage with its cars
class Garage {

Of course, this format is fine when the description is short. However, if you need to write a more exhaustive description, you'd better use the multiline comments starting with /** and closing it with */.

You can also describe the arguments and the value returned with :param: and :returns: as shown in the following code:

     Sell a product and remove it from the current stock.
     Remember that:
     - The product must be available
     - the quantity can't be 0 or negative
     :param: product The product you are selling
     :param: quantity Number of units or kilos to sell
     :returns: if the purchase was done correctly
    func sellProduct (product: Product, quantity: Int) -> Bool{

For example, this code will generate the following box:



In this introductory chapter, we discussed about the basics of Xcode. You learned important keyboard shortcuts that helped us speed up the development. You learned how to set up a project and how to work with this IDE like testing with Playground and using the Git version control.

In the next chapter, we are going to start our first app from scratch. You will learn some of the basic features of the Swift programming language.

About the Author

  • Cecil Costa

    Cecil Costa, also know as Eduardo Campos in Latin countries, is a Euro-Brazilian freelance developer who has been learning about computers since getting his first PC 286 in 1990. From then on, he kept learning about programming languages, computer architecture, and computer science theory. Learning is his passion as well as teaching; this is the reason why he worked as a trainer a books author. He has been giving on-site courses for companies such as Ericsson, Roche, TVE (a Spanish television channel), and lots of other companies. He is also the author of the book Swift Cookbook first edition, Swift 2 Blueprints and Reactive Swift Programming. Nowadays, Cecil Costa teaches through online platforms, helping people from every part of the world. In 2008, he founded his own company, Conglomo Limited (www.conglomo.es), which offers development and training programs both on site and online. Over his professional career, he has created projects by himself and also worked for different companies, from small to big ones, such as IBM, Qualcomm, Spanish Lottery, and DIA%. He develops a variety of computer languages (such as Swift, C++, Java, Objective-C, JavaScript, Python, and so on) in different environments (iOS, Android, Web, Mac OS X, Linux, Unity, and so on) because he thinks that a good developer needs to learn every kind of programming language to open his mind, and only then will he really know what development is. Nowadays, Cecil is based in the UK, where he is progressing in his professional career, working as an iOS Team Lead. I would like to thank mr George Boole for making everything true or false and to Leonard Kleinrock for creating the idea of internet.

    Browse publications by this author

Latest Reviews

(7 reviews total)
Book Title
Access this book, plus 7,500 other titles for FREE
Access now