The Xcode Window

Xcode 8 provides a single window for a project. This window provides our view into nearly everything we’ll do with a project: editing code and user interfaces; adjusting settings for how the project is built and run; employing debugging tools; and viewing logged output.

The window is split into five areas, although some of them can be hidden with menu commands and/or toolbar buttons. These areas are shown in an “exploded” view in the figure.

The window is split up as follows:

Toolbar

The toolbar at the top of the window offers the most basic controls for building projects and working with the rest of the workspace. The leftmost toolbar buttons, Run and Stop, start and stop build-and-run cycles. Next are two borderless buttons collectively known as the scheme selector, which chooses which “target” to run (currently PragmaticPodcasts) and in what environment (such as a simulated “iPhone SE,” or the name of an actual iOS device connected to the Mac). Next comes an iTunes-like status display that shows the most recent build and/or run results, including a count of warnings and errors generated by a continual background analysis of the code. Further right, the Editor Mode buttons let us switch between three different kinds of editors, which we’ll describe shortly. Finally, three View buttons allow us to show or hide the Navigator, Debug, and Utility areas. These areas are described next.

Navigator Area

The left pane (which may be hidden if the leftmost View button in the toolbar is unselected) offers high-level browsing of our project’s contents. It has a mini toolbar to switch between eight different navigators. The File Navigator (⌘1) shows the project’s source and resource files and is therefore the most important and commonly used of the eight. Other navigators let us perform searches (⌘3), inspect build warnings and errors, inspect runtime threads and breakpoints, and more.

Editor Area

The main part of the window is the Editor area. This view cannot be hidden. Its contents are set by selecting a file in the Navigator area, and the form the editor takes depends on the file being edited. For example, when a source file is selected, we see a typical source code editor; when a GUI file is selected, the Editor area becomes a GUI editor; and when an image file like a GIF or JPEG is selected, the Editor area displays the image.

The Editor Mode buttons in the toolbar switch the editor pane between three modes: standard, which is the default editor for the type of file that’s selected; assistant, which shows related files side by side; and version, which uses source control to show the history of the file. In version mode, you can choose a side-by-side “comparison” of the local and previous versions of the file, a “blame” view that shows the committer of each line of code, or a log of commit comments alongside the code. The Editor area also contains a jump bar, a breadcrumb-style strip at the top that shows the hierarchy of the thing being edited; for a source file, this might read “project, group, file, method.” Each member of the jump bar is a pop-up menu that navigates to related or recent points of interest.

By default, a new project comes up with its top-level settings selected in the Navigator area, which means that the Editor area defaults to showing settings for things like the app version number, the targeted SDK version and device families, and so on. There may also be a scary-looking “No matching provisioning profiles found” warning, which just means we’re not set up to run our app on a real device yet; we’ll deal with that in Chapter 6, ​Testing the App​.

Utility Area

The right side of the window is a Utility area that provides detailed viewing and editing of whatever is selected in the Editor area. It is split vertically into two parts: the inspector pane and the library pane. Depending on the file being edited, the toolbar atop this area can show different tools in its inspector pane. Basic information about a selected file and quick help on the current selection are always available. For GUI files, there are inspectors to work with individual UI objects’ class identities (⌥⌘3), their settable attributes (⌥⌘4), their size and layout (⌥⌘5), and their connections to source code (⌥⌘6). We’ll be using all of these shortly. At the bottom of the Utility area, a library pane gives us click-and-drag access to common code snippets, UI objects, and more.

Debug Area

The bottom of the window, below the Editor area and between the Navigator and Utility areas, is a view for debugging information when an app is running. Its tiny toolbar has a segmented button that lets us switch between the debugging-oriented variables view that allows us to inspect memory when stopped on a breakpoint, a textual console view of logging output from the application, or a split view of both. We’ll make use of the right-side console view in a little bit, whereas the left-side variables view will be our focus in a later chapter.

So that’s how Xcode presents our initial project to us, but what can we do? Well, there’s a nice big Run button, and it’s not like it’s disabled. Let’s try running the app. Make sure the scheme is some flavor of iPhone from the iOS Simulator section (and not iPad or the name of an actual device); in Xcode 8, our choices range from the iPhone 5 to the iPhone SE, with some different-sized iPhone 6 and 7 models in between. Click the Run button.

The Xcode status area will shade in with a progress bar that fills up as it builds all the files and bundles them into an app, and when it’s done, it will launch the iOS Simulator. The Simulator is another macOS application, which looks and behaves more or less like a real iPhone or iPad. When our app runs in the Simulator, the main screen disappears and is replaced by a big white box that fills the Simulator screen. If the simulated iPhone screen is too big for your computer screen, use the Window > Scale menu (or keyboard shortcuts ⌘1 through ⌘5) to scale down the window to fit.