Hour 4. Using Xcode 5

Xcode is a complete development environment that includes editors for text-based code, user interfaces, and Core Data data models. It comes with debugging tools, as well as a variety of extra tools you need for building and managing your projects.

As of this writing, the current version of Xcode is 5. Xcode 4 was a major change from Xcode 3, including a new single-window interface and the integration of the user interface design tool, Interface Builder (previously a separate program), into Xcode and the addition of storyboarding for iOS apps. Xcode 5 is another major change that continues the simplification started in Xcode 4. In Xcode 5, debugging tools are more closely integrated with Xcode itself along with more extensive support for Git repositories (this is discussed throughout this hour). In addition, the interface of Xcode 5 shows how some of the major design principles of iOS 7 can be applied to Mac apps. (Xcode has always served as somewhat of a testbed for new interface technologies.)

The download of Xcode typically contains the SDKs for the current and various previous versions of the operating systems for iOS and OS X. For that reason, during the development process of a new OS, revisions to the SDKs are typically reflected in revisions to Xcode. Furthermore, in 2012 and 2013, a further pattern emerged that may or may not continue. In both of these years, the new version of iOS was released a few weeks before the new version of OS X. A version of Xcode was released for the new version of iOS and the current version of OS X. A few weeks later, a minor (“dot”) release of Xcode reflected the new OS X version.

Most of the time, you use Xcode to build projects from built-in Xcode templates that include several frameworks for OS X or iOS. You write code that customizes and adds on to those frameworks for your own project’s needs.

With Xcode, you create projects. Each project can have several targets. In the simplest case, you have a single target for your project, but you can also have several targets (such as a full version and a lite version or an OS X version and an iOS version). You can switch among the targets to build them separately in Xcode.

---

Try it Yourself: Create a New Xcode Project

These steps provide a quick review of how to get started with an Xcode project. You’ve seen them before in Hour 1, “Overview of the Developer Program.” These steps provide a bit more details about the options you have as you create a new project.

In Hour 5, “Using Compiler Directives,” you’ll go through them again in even more detail. Partly this is to introduce you to the process, but it’s also because the purpose of building the project changes from hour to hour. In Hour 1, the purpose was to get you started as quickly as possible with Xcode. In this hour, the purpose is to build a project so that you can use the Xcode source control options to manage changes. And in Hour 6, “Exploring Messaging and a Testbed App,” the purpose will be to create a testbed app that you can use to experiment with Objective-C syntax.

Here’s how to create a new Xcode project:

1. Launch Xcode.

The first time you launch it, you see the splash screen shown in Figure 4.1. The check box at the bottom left enables you to choose whether or not to see it in the future. If you do not see it, you can always reopen it from Window, Welcome to Xcode or -Shift-1.

FIGURE 4.1 Create a new project from the Xcode splash screen.

2. Click Create a New Xcode Project to open the window shown in Figure 4.2. Select the operating system and template you want to use.

FIGURE 4.2 Review the iOS templates.

3. Select the templates for each of the operating systems. For this experiment, choose the Master-Detail Application template for iOS.

Figure 4.3 shows the templates for OS X.

FIGURE 4.3 You can switch to OS X templates.

4. On the next screen (see Figure 4.4), name the project and provide additional information.

FIGURE 4.4 Set the name and options for your project.

---

Tip

The choices and settings differ for iOS and OS X projects as well as for different templates within them, but you always name the project.

---

5. Provide a location for the project and create a source code repository, as shown in Figure 4.5. From the pop-up menu, choose My Mac for the location.

FIGURE 4.5 Review the location and create a Git source code repository.

Make sure to check the Create Git Repository on My Mac check box source code repository. There is more on Git in particular and source code repositories in general in the next section.

---

Xcode supports both Subversion and Git with a common interface for both. However, it creates repositories only for Git, which is why it is used in this hour. Both Subversion and Git can be controlled from the command line in the Terminal app. Because Subversion is a client/server version control system rather than a distributed one, Git and its distributed architecture make it easier to integrate into Xcode in a totally automated manner.

A key aspect of source code management is the ability to check out files from the repository and modify them in your own directory. When you are done, you can check the code back in. In both the check-in and checkout processes, you are allowed to add a comment about what you have done, and perhaps what you plan on doing next. (Using these comments is definitely a best practice.) In addition to your optional comment, the source code management software automatically captures the date and time of the check-in/checkout as well as the user’s name. Thus, you have a management record of the files.

In the case of branching, you create an independent branch or series of check-ins and checkouts that remain within the overall project. Depending on the project and the development, you might eventually merge a branch back into the main branch, or a branch might become the main branch. However it is handled, the intention of branching is to create multiple development paths within a single project. In the case of forking, you might take an existing project, copy it (with permission, of course), and then continue development on the separate fork.

The problem of source code management was addressed in two primary ways. Starting in the mainframe era, the notion of management of any kind of data was generally solved by storing the data in a centralized location (think databases) and in a client/server scenario.

With the advent of fast networks, it became feasible to decentralize the storage of the shared data, and that is what Git does. There is no centralized repository; rather, there can be many repositories, each of which is complete.

In practical terms, for most people working on their own Xcode projects, there is only one repository: their own. There is no need to sync it with other copies of the repository because there are none. This means that although Git can manage multiple repositories on a peer-to-peer basis, the only commands that you need to worry about are the commands to check in or check out a file, create a branch, or merge a branch.

The final thing you need to worry about is the check box shown previously in Figure 4.5. Check it to create your Git repository on your own computer—and you are ready to go.

Everything is a version or a revision. If you want to split hairs, you can even suggest that the first version of a file posted to a repository is itself a revision—a revision from nothing to that first version.

Trust the version control. For many people, the hardest thing to learn is to stop managing files and versions themselves. Before embarking on an attempt to solve a problem, many developers are used to copying the project files to a new directory so that, if there are problems, they can revert to a known version. This is no longer necessary. You can create a branch if you want, but you can also check out files to modify them and discard the modifications. All of the file and naming manipulation can be handled by the version control system.

Because you will be relying on the version control software to keep track of the versions of your code along with your comments as you check files in and out, you do not need to name files to reflect their test status. This can be a difficult habit to break, but unless you do, you will not reap the benefits of source code management software. Furthermore, you will make your development environment more complicated.

Establish a naming convention for your files and stick to it. With Xcode, the naming convention can be very simple: Accept the Xcode default names. You can set up a class prefix as shown previously in Figure 4.4 to add a default prefix to new files. Make certain that the prefix has to do with the files (for example, who owns licensed code in them) and does not reflect the state of the file, such as test or development. Those considerations can be managed very well with source code control. Prefixes enable you to prevent namespace collisions between existing code and your new code. They also can help you keep track of where code you have included from other developers and open sources comes from.

Thus, when you create and name your project, consider that you are naming what will be the project in all of its configurations—test, production, enhancements, and so forth. Use the production name in most cases.

Without making any changes, build the project. Click the Run arrow at the left of the toolbar in the Xcode window and select where to run it. If you have created an iOS project, your choices will be an actual device or the simulator, which has a variety of hardware configurations built in to it, as shown in Figure 4.6.

FIGURE 4.6 Build and run the project.

You may see a message about a missing provisioning profile. If you are just testing Objective-C code, you can ignore that message. If you are using the frameworks that implement iCloud and access to shared services, you must resolve the issue; for the projects in this book, however, you should be okay.

When it runs, you’ll see the app as shown in Figure 4.7. You can use the simulator’s menu commands to rotate the simulated device.

FIGURE 4.7 View the app on the simulator.

After you start to use Git, you will see what it can do (and how you can do it).

---

Try it Yourself: Use Git to Track Changes

Now that you have an app up and running, the best way to learn about Git is to use it. Before continuing, make certain that you do have an app created, as in the Try It Yourself activity, “Create a New Xcode Project.” Then, follow these steps:

1. Select the working copy of your app and choose Configure from the submenu, as shown in Figure 4.8.

FIGURE 4.8 Configure your repository.

You may see repositories other than the one you have just created.

---

Tip

If you do not see the project you have just created, create a new project and make certain to indicate that you want a Git repository.

---

2. Check that the local repository has been created, using the command Source Control, History as shown in Figure 4.9.

FIGURE 4.9 Verify the local repository.

3. Make a change to a file in the project.

In Figure 4.10, you see a traditional C language-style comment added at the top of AppDelegate.h. Note the badge (the letter M) indicating a modification to the file in the project navigator. (It might take a moment or two for it to show up.)

FIGURE 4.10 Make a change to a file.

4. Commit the change by choosing Source Control, Commit.

5. Review the changes.

Figure 4.11 shows you the changes (right) and the previous version (left). Check that they are OK. If they are, type a commit message at the bottom of the window and click Commit in the lower right. You use the check boxes in the project navigator to add or remove changed files from the commit. You also can use the check mark in the gutter between the changes and original version to accept or reject an individual change.

FIGURE 4.11 Review the changes.

6. If you do not provide a description of your changes, you will not be able to commit them (see Figure 4.12).

FIGURE 4.12 You must have a commit message.

7. Provide the commit message and commit the changes. The M in the project navigator will disappear (there may be a brief delay).

8. Review the history with Source Control, History, as shown in Figure 4.13.

FIGURE 4.13 Review the history of changes.

You can review individual changes to each file in a commit.

There’s one additional point to bring up. You can configure each of your working copies using Configure <Your Project Name> in the submenu shown in Figure 4.8. As you can see in Figure 4.14, one of the configuration settings lets you choose which side the original code and the modified code is shown on.

FIGURE 4.14 Configure the display.

---

You have seen the basics of using Git: creating a repository, making a change, and committing it. Moving beyond the basics is not so much a matter of getting more complicated but, rather, of mastering a few special cases.

When you review your changes before committing them, it is sometimes easy to decide whether to commit or discard them. There are also cases where you know as you are embarking on a series of changes that they might not work. In such a case, it is often not just a matter of a few lines of code, but a matter of significant changes to several files—sometimes over a period of time as you explore a new architecture or interface. In those cases, branches are a good solution. You create a branch and work within it. You can commit changes as you go along. When you are at a stopping point, you might decide that the new branch is the way to move forward, and you can merge it back into the main branch.

On the other hand, you might decide that the branch has been a good experiment and learning process, but it really is not the way you want to move forward with the project. In such a case, you can revert to the main branch and continue committing from the point before you split off the new branch or you can merge in the changes. You can delete the unused branch or keep it around for reference and possible future use.

---

Try it Yourself: Use Branches

Before creating a new branch, you might want to commit all uncommitted changes. You do not have to do so, but it is often easier to make certain that the project is in a stable and known condition. If you have a choice, work from a version that works even if it does not contain every feature. Then, you can create a branch and, if you break the code, at least you can return to something stable. Here are the steps to follow to create a new branch:

1. Use the submenu shown previously in Figure 4.8 to create a new branch.

2. Name the new branch (see Figure 4.15). (Spaces are not allowed in branch names.)

FIGURE 4.15 Name the new branch.

3. You are automatically switched to the new branch. You can verify this by choosing Switch to Branch from the workspace submenu. As you see in Figure 4.16, all branches are listed in the center of the sheet; the current branch is identified in the text at the bottom. You can switch back and forth. Figure 4.16 shows the perspective when you switch back to the master branch after having created a branch for testing.

FIGURE 4.16 Switch to a branch.

4. Modify a line of code to your project and commit it with a comment. If you added a comment line to AppDelegate.h to test committing changes, you can delete it now and commit that change.

5. Use Source Control, History to view changes, including this one.

6. Using the Source Control submenu, switch back to the main branch. The sheet shown in Figure 4.16 shows the master branch as a branch to which you can switch from the current branch (TestBranch).

7. Use Source Control, History to view the history of the current branch. Because you have switched back to the master branch, the last commit from Step 6 on TestBranch is not shown.

8. From the Source Control submenu, you can use Merge from Branch or Merge into Branch to combine two branches. Note that from the master branch, Merge into Branch is not possible.

---

The first step in using a remote repository is to either create one or gain access to one. Fortunately, this is remarkably easy to do. If you search the Web for “Git Hosting,” you find a variety of vendors that provide the service. Their prices vary, so it is worth your time to look at their rates. Perhaps the biggest provider is Github.com. In common with some other services, they offer a free account for open source projects. For private repositories, their prices currently start at $7 a month.

Version control is essential on large-scale projects, and often open source projects are very large scale. If you want to participate in an open source project, the first step often is connecting to the source code repository and downloading the existing code.

Some organizations run their own semiprivate repositories. For example, a school might set up Git on one of its servers and allow students and faculty to connect to it.

If you want to create a remote repository, normally you open an account with a vendor or with your organization. You then create the repository using whatever tools are provided to you. After it is created, you or others can connect to it and get to work.

The standard practice with Git is to clone a repository on which you want to work. Each distributed copy of the project is managed on its own, and the changes are then merged back. With Subversion, you check out the code. With Subversion, committing changes to your local copy automatically merges them back to the main version. (You might want to review the commit interface, as shown previously in Figure 4.11.)

With Git, the commits to your local copy of the repository are distinct from the updating and merging of the remote repository, although the interface that lets you review, merge, and discard changes is similar. After you have committed your local changes, you can use Source Control, Push to move them back to the shared repository.

---

Try it Yourself: Check Out or Clone a Repository

After you have located a shared repository, the next step is to check out a copy (from a Subversion repository) or to clone a Git repository. Here are the steps to clone a Git repository:

1. In the Accounts tab of Xcode Preferences, use the + at the bottom left to create a new repository. The shortcut menu shown in Figure 4.17 appears.

FIGURE 4.17 Add a repository.

2. Specify the location of the repository you want to clone. You can either use the HTTPS or the ssh address shown in github or your own remote repository.

3. When requested, provide the username, password, and a brief description of the remote repository.

---

You now work with your copy of the repository as you would with any other repository on your local computer. Use Source Code, Push with Git to merge your changes to the remote repository. With Subversion, this is provided as part of the regular Commit command.

You can also use Source Control, Check Out and choose the Repositories tab to check out a project as a new Xcode project on your Mac. You can find more information on Git at http://git-scm.com/.

There’s one final point to mention. You saw in Figure 4.5 that you can automatically create a Git repository on your Mac when you create a project. If you are running Git on a server, you can choose that server to create the new repository. Eventually, that pop-up menu will contain the names of all local servers that are running Git.

A. When you identify versions of your software, you can keep track of the project’s evolution. More important, all of the code is in one place, and you do not accumulate a variety of copies of your project inside folders with names like Friday Test, Restructured Database, and the like. Perhaps most useful is that you can back out changes without searching through various disk archives and backups.

Q. When do you use a branch?

A. A branch is a series of updates that start from the master (or another branch) and continue with revisions. You can merge a branch back into the master or other branch, or simply abandon it and continue with the main branch.

2. Why is there a difference between Commit for Subversion and Git?

2. Because Git is a distributed architecture, you have a complete copy of the repository on your local computer and can merge changes without disturbing the shared repository (which, in fact, is shared mostly in the fact that it is one of many repositories).

Browse Github.com to see the features it offers (and that many other hosting services offer). Open source projects are often available for download, so experiment by connecting to an open source repository with Github or another product and browse the files.