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.

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.

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.

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.

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

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.

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???
}.resume()

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!) )")
}.resume()

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

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()

    pointer.dealloc(1)

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

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())")

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.

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 {
              object.process(i)
            }
          */
          println(myObject.description)
        */

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() {
      super.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 "192.168.20.21"

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
myconnection.retrieveInformationFromServer()

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.