iOS App Development For Dummies (2014)

Part I. Getting Started

Chapter 2. Getting to Know the SDK

In This Chapter

Understanding what’s in the SDK

Getting an overview of how programmers use Xcode for app development

Taking a detailed tour of the Workspace window

Xcode is the integrated development environment (IDE) that you use to build your iOS apps. In addition to building iOS apps, it can be used to build OS X apps. It is used to build Apple’s own apps such as the iWorks suite. And to top it all off, it’s used to build iOS and OS X themselves. Over its history, it has gotten even more powerful. In its most recent versions (4 and 5), it has also been given a modern and easy-to-use interface. It also has served as a test bed for user interface technologies that Apple later brings to its consumer apps.

In this chapter, I take you on a guided tour of the features you’ll find in Xcode — giving you the view from 30,000 feet. I go through it all in detail as you use it throughout this book until your feet are firmly planted on terra firma — at least when it comes to Xcode. The point of this chapter is to provide a frame of reference as you move forward, and a complete reference for you to look back on.

Developing Using the SDK

The iOS Software Development Kit (SDK) provides support for developing iOS apps and includes the complete set of Xcode tools, compilers, and frameworks for creating apps for iOS and Mac OS X. These tools include the Xcode IDE (its integrated development environment) and the Instruments performance analysis tool, among many others.

Xcode 5 (the latest version) is an app that you simply download from the Mac App store. You need the current or first prior version of OS X installed to use Xcode. You should also become a registered developer. To do that, first go tohttp://developer.apple.com/devcenter/ios, look for (and then click) the link to become a registered developer, fill out some registration information, and then start reaping the benefits of being a registered developer, starting with access to tons of documentation sample code and a lot of other useful information. Note: If you want to actually run your app on your iPhone or iPad and submit it to the App Store, you need to join an official iOS Developer Program, which you can do right after you become a registered developer.

Apple links do change from time to time, so if a link I provide in this book doesn’t work, you can always start at http://developer.apple.com and navigate to the iOS Dev Center from there.

Xcode is the latest iteration of Apple’s IDE, a complete toolset for building Mac OS X and iOS apps. With Xcode 5, you can develop apps that run on any iPhone, iPad, or iPod touch running iOS. You can also test your apps using the included iOS Simulator, which supports iOS 6 and iOS 7.

The Xcode IDE includes a powerful source editor, a sophisticated graphical user interface editor, and many other features, including source code repository management. Moreover, as you code, Xcode can identify mistakes in both syntax and logic, and even suggest fixes.

To start with, I give you an overview of Xcode and how you’ll use it to develop your app. As you move from step to step, I provide more detail on how to use Xcode to specifically do what you need to do in any given step.

Using Xcode to Develop an App

To develop an iPhone, iPod touch, or iPad app, you have to work within the context of an Xcode project. Xcode supports the following activities that are parts of developing your app:

· Creating an Xcode project

· Developing the app (designing the user interface using a storyboard, coding, and running and debugging the code)

· Tuning app performance

· Distributing the app

It supports many more activities as well, such as automated testing, but these are the activities I focus on in this book. The following sections tell you more about each of these tasks.

Creating an Xcode project

To develop an iOS app, you start by creating an Xcode project. A project contains all the elements needed to create an app, including the source files, a graphical representation of the user interface, and build settings needed to build your app. You work on your project in the Workspace window, which allows you to create all of these elements as well as build, run, debug, and submit your app to the App Store.

Developing the app

You have a lot to do to develop an app. You need to design the user experience and then implement what you came up with as a user interface. You need to write code to implement the features of the app. You also need to test and debug the app.

Designing the user interface using a storyboard

Xcode’s Interface Builder is the editor you use to assemble your app’s user interface with the help of preconfigured objects found in the Library. The objects include windows, controls (such as switches, text fields, and buttons), and the views you’ll use, such as Image, Web, and Table views. The Interface Builder editor allows you to add objects, configure their properties, and create connections not only between user interface objects, but also between user interface objects and your code.

When you use a storyboard (which you do in this book), most of if not all your screens end up being displayed in the storyboard, and Interface Builder saves your storyboard in a storyboard file (with the .storyboard extension). When you don’t use a storyboard, each screen is saved separately as a nib file (with the .xib extension). Either way, these files contain all the information iOS needs to reconstitute the user interface objects in your app at runtime.

Interface Builder saves you time and effort when it comes to creating your app’s user interface. You don’t have to code each object (which saves you a lot of work), and what’s more, because Interface Builder is a visual editor, you get to see what your app’s user interface will look like at runtime.

Coding

To code, you use the Source Code editor, which supports features such as code completion, syntax-aware indentation, and source code folding (to hide “code blocks” temporarily). You can get context-based help to assist you, and if you need information about a particular symbol, you can either get a summary of a symbol’s documentation directly in the editor, or you can opt for more extensive documentation.

Xcode’s Live Issues and Fix-it features work together to point out mistakes as you enter your code and offer to fix those mistakes for you.

Running and debugging

When you run your app to debug or test it, you can run it in the iOS Simulator on your Mac and then on an iOS-based device (if you're in the developer program). Using the simulator, you can make sure your app behaves the way you want. You can also get debugging information — as you run — in the Debug area. By running your app on a device connected to your Mac (still using the debugger, if you like), you can observe the actual user experience and see how the app will perform.

Tuning app performance

As you are running your app, gauges show you the amount of memory you’re using, what’s happening in your app’s iCloud sandbox, how you’re doing on energy consumption (a critical issue for mobile devices), network activity, and more. The clear, graphical interface of the gauges is a major new feature of Xcode 5.

Distributing the app

Xcode provides various kinds of app distribution, including

· Ad hoc distribution for testing on up to 100 iOS devices.

· The App Store for distributing to hundreds of millions of iOS device users. You can give your apps away for free or let Apple sell them for you.

· Custom B2B Apps for distributing business-to-business apps directly to your business customers who have a Volume Purchase Program account.

You create an archive of your app that contains debugging information, making it easier to track down bugs reported by testers (and users) of your app. When your app is ready to go, you submit it to the App Store. (Before you submit your app to the store, you even run some of the same software-validation procedures on your app that Apple does — passing these tests makes your app’s approval process as fast as possible.)

The Workspace Window

Command central for Xcode is the Workspace window, where you’ll do almost all the things you need to do to develop your app.

In this section, I present only an overview — more or less the map of what’s in the Workspace window and what each bar and button is and does. I came up with this as a way to provide a quick reference to the Workspace window so you can see all its elements, including the various bars and buttons and what they do.

Figure 2-1 shows the window. (If you like, bookmark this page so you can refer to this figure at any time when reading the book.) At first glance, it may seem overwhelming, but take a deep breath and don’t worry: I explain each part. As I take you through using Xcode to develop your app, I go into more detail as needed. So for now, take a quick read through the upcoming sections just to familiarize yourself with the lay of the land and then return to Figure 2-1 as needed for quick reference.

Figure 2-1: The Xcode Workspace window.

Although I have added shadings to the Workspace window components in this chapter for easy reference, figures in the remainder of the book show the components as they appear on your screen.

The Workspace window consists of

· Workspace areas

· The toolbar

· An optional tab bar

The following sections describe each of these elements — the heart of Xcode.

Workspace areas

The Workspace is divided into four areas, as follows:

· Editor area (always shown)

· Navigator area

· Utility area

· Debug area

You can configure the Workspace area in a number of ways. Right off the bat, you can choose to hide and/or show various areas in various combinations. (Note that the Editor area is always present.) The Debug and Utility areas are already configured with panes, but in the Debug area, you can select the pane configuration.

Editor area (always present)

The Editor area is always present. You can choose any of the various content editors to be shown within the Editor area; you do so using the Editor selector, the group of buttons in the toolbar you can see in the following figure.

The content editors you have available are as follows:

· Standard editor: The button for this editor is on the left side of the Editor selector. The Standard editor displays a single pane for editing. You have probably worked with standard editors in many environments and IDEs.

· Assistant editor: Select this editor using the center button. This adds an additional pane to the Editor area so that you can view two files at the same time. You can also split one of the panes so that you can work with three, four, or more files at the same time (the size of your monitor limits the number you can work with at the same time). The Assistant editor has some navigation features that I explain in Chapters 7 and 9.

· Version editor: Open this editor using the right button on the Editor selector. This enables you to compare two different versions of a file.

I later explain the tasks you can perform within these areas.

Additional areas to view as needed

You use the View selector (see the following figure) to toggle between showing and hiding any of the optional areas. These optional areas are as follows:

· Navigator area (left button): This area can display any of a number of navigators that let you navigate through your project, through breakpoints, and other items. It is described in the following section (“Displaying an area’s content”).

· Debug area (center button): Displays either or both of two panes depending on what you choose to see. You change panes using the Debug area Scope bar, shown in the following figure.

The Debug area Scope bar toggles each pane’s visibility. You can choose either or both of them:

· Debug pane: This shows you the values for variables as they are set and changed while the app runs.

· Console pane: This shows you messages generated by the app for the console (including debugging messages you can insert).

You can control the visibility of each pane, but you can’t reorder them. If the Variables pane is shown, it is always on the left, and if the Console pane is shown, it's on the right. If only one pane is shown, it takes up the entire width of the Debug area.

· Utility area (right button): Is further configured with two panes (either can be expanded to hide some or all of the other):

· Inspector pane

· Library pane

I explain what you see in each of those panes when I explain the Utility area section, later in the chapter.

When you hover your mouse pointer over a toolbar button, a tooltip describes its function.

Displaying an area’s content

Each area displays certain content, and each area has its own way of displaying its content:

· The Navigator area has navigators.

· The Editor area has content editors.

· The Utility area has

· Quick Help or Inspectors in the Inspector/Quick Help pane.

· Libraries in the Library pane.

· The Debug area has

· Debugger variables in the Variables pane.

· Debugger output in the Console pane.

The following sections tell you about these areas in more detail.

Navigator area navigators

The Navigator area contains a host of navigators that organize the tasks and components you use within your Xcode project. You use a Navigator selector bar to select the navigator you need. The following figure shows the various navigators you can choose from. The navigators you most frequently use are described in this book. Here is a summary of them:

· Project navigator: Here’s where you manage all the files in your project. You can add files, delete files, and even organize your files by placing them into groups. Selecting a file in the Project navigator launches the appropriate editor in the Editor area.

· Symbol navigator: Lets you zero in on a particular symbol — an element such as a variable, method, or function name — in your project. Selecting a symbol highlights it in the editor.

· Find navigator: Finds any string within your projects and frameworks.

· Issue navigator: Displays issues such as diagnostics, warnings, and errors that arise when you’re coding and building your project.

The following navigators are beyond the scope of this book:

· Test navigator: Xcode 5 allows you to integrate automated test suites into your project. Unfortunately, the Test navigator and automated test suites are beyond the scope of this book, but don’t worry: You can still build great apps and test them manually.

· Debug navigator: Displays the call stack — information about what method has called what method — during program execution.

· Breakpoint navigator: Manages and edits the breakpoints — markers you add to your code that stop program execution at a certain point in your program — in your project or Workspace.

· Log navigator: Examines the logs that Xcode generates when you run and debug your app.

Editor area content editors

The Editor area has a number of editors you use to edit specific content. Content editors are context based where the context is determined by the type of file you are editing. This means that the selection you make in a Navigator or Editor jump bar — the toolbar that appears at the top of each Editor area pane and is used to navigate through the files and symbols in your project — determines the Content editor. The following bullet list names each Content editor that is described in this book and outlines the tasks associated with each one (note that not all tasks are applicable to iOS app development):

· Source editor: Write and edit your Objective-C source code; set, enable, or disable breakpoints; and control program execution.

· Project editor: View and edit settings such as build options, target architectures, and code signing.

· Interface Builder: Graphically create and edit user interface files in storyboards (and XIB files if you are not using a storyboard).

· Property list editor: View and edit various types of small, highly structured property lists (plists). (You’ll use one for some of your program’s data.)

· Viewer: Display files for which there is no editor (some audio, video, and graphics files, for example) using the same Quick Look facility used by the Finder.

For the sake of completeness, the other content areas that are beyond the scope of this book are briefly described here:

· Core Data model editor: Implement or modify a Core Data model.

· Mapping model editor: Graphically create and edit a mapping between an old Core Data store and a new one.

· Script editor: Create and edit AppleScript script files.

· Scripting dictionary editor: Create and edit the scripting definition (.sdef) file — used by AppleScript — for your app.

· Rich text editor: View and edit rich text (.rtf) files, much as you would with Text Edit.

Utility area

The Utility area has two panes: the Inspector pane and the Library pane. Part of the Inspector pane is always visible, but you can totally collapse the Library pane if you want by dragging it to the bottom of the Utility area.

When working within the Inspector pane, you click a button in the Inspector selector (shown in the following figure) to select a particular inspector. (Note that a previous navigator selection or Content editor selection may determine which inspectors are available.) Your choices are as follows:

· File inspector: For viewing (and managing) file metadata, such as a filename, type, and path.

· Quick Help (second button): For viewing (applicable) details about what has been selected in an editor, such as an abstract or concise description, where and how it is declared, and selection-based information such as an element’s scope, the parameters it takes, its platform and architecture availability, references, sample code, and so on. The following selections are supported:

· Symbols, in the Source editor

· Interface objects, in Interface Builder

· Build settings, in the Project editor

Additional inspectors are available in some editors; for example, Interface Builder offers the following:

· Identity inspector: For viewing (and managing) object metadata such as an object’s class, runtime attributes, label, and so forth.

· Attributes inspector: For configuring the attributes specific to the selected interface object. For example, some text field attributes include text alignment and color, border type, and editability.

· Size inspector: For specifying characteristics such as the initial size and position of an interface object, its minimum and maximum sizes, and various autosizing rules for the object.

· Connections inspector: View the outlets and actions for an interfaceobject, make new connections, and delete existing connections. (Connections “connect” your program code to user interface objects you create in Interface Builder.)

When working within the Library pane, you click a button in the Library selector bar (shown in the following figure) to select a library of resources you can use in your project. The following libraries are available:

· File templates: These templates are for the common types of files listed as choices in the New File menu. To add a file of that type to your project, drag it from the library to the Project navigator.

· Code snippets: These are short pieces of source code for use in your app. To use one, drag it directly into your source code file.

· Objects: This library contains the kinds of interface objects you’d use to make up your user interface. To add one to a view, drag it directly into your storyboard or nib file in the Interface Builder editor.

· Media library: This library contains a whole slew of graphics, icons, and sound files. To use one, drag it directly to your storyboard or nib file in the Interface Builder editor.

Debug area

The Debug area is where you’d try to track down the bugs in your code and squash them. A selection in the Debug area Scope bar determines the information the debugger displays as described previously in this section.

The pop-up menu in the Variables Pane Scope bar lets you display in the following ways:

· Auto: Display recently accessed variables

· Local: Display local variables

· All: Display all variables and registers

The pop-up menu in the Console Pane Scope bar lets you display

· All Output: Target and debugger output

· Debugger Output: Debugger output only

· Target Output: Target output only

You also find other controls and filters for what is displayed; explore them on your own.

Xcode has extensive contextual help articles that you can view by Control-clicking in the Workspace window on the item you need help on.

The toolbar and Tab bar

The toolbar (see the following figure) includes Workspace-level tools for managing and running schemes (instructions on how to build your app), viewing the progress of (executing) tasks, and configuring the Workspace window. That’s a lot of tools, so to keep things straight, it's best to think of the toolbar as actually having three parts: A Flow control part, an Activity Viewer part, and a Workspace Configuration part.

Flow controls are for defining, choosing, running, and stopping projects. A scheme defines characteristics such as build targets, build configurations, and the executable environment for the product to be built in.

The Flow controls are as follows:

· Run button: Clicking the Run button builds and runs the targets. (A target, in this context, is the product you want to build as well as the instructions for building that product from a set of files in a project or Workspace for the currently selected scheme.) Pressing and holding the mouse button opens a menu (which is also available in the Product menu) that allows you to run, test, profile, or analyze your app.

· Stop button: Terminates your executing app in either the Simulator or the device.

· Scheme menu: Lets you select the scheme and build destination to use.

The Activity Viewer part of the toolbar shows the progress of tasks currently executing. This viewer displays status messages, build progress, and other information about your project. Click the Issues icon in the Activity viewer to open the Issue navigator (explained earlier in this chapter, in the “Navigator area navigators” section).

You use the final part of the toolbar — the Workspace Configuration part — to configure the Xcode Workspace window to suit your needs. You can use these controls to select an editor type, show or hide optional view areas, and open the Organizer window. (See the “Displaying an area’s content” section, earlier in the chapter, for more on your choices here.)

The Tab bar is great for keeping track of where you’ve been and what you might want to go back to. Note, however, that showing the Tab bar is optional. If you decide that the Tab bar is something you just can’t do without, choose View⇒Show Tab Bar from Xcode’s main menu. You can reorder tabs, close them individually, or drag them out of the bar to create a new window.

If you lose the toolbar (or Tab bar), you can always add it back to any window by selecting View⇒Show Toolbar (or View⇒Show Tab Bar). The View menu also allows you to configure the Workspace window.

The Organizer window

The Organizer window (see Figure 2-2) enables you to do supplemental tasks such as accessing documentation and managing devices, archives, and project-related metadata.

Figure 2-2: The Organizer window.

To display the Organizer window, choose Window⇒Organizer from Xcode’s main menu. The Organizer window includes three individual organizers, which enable you to do the following:

· Devices organizer: Provision a device, manage your developer profile, install iOS on the device, and manage your app and data on a device.

· Projects organizer: Lets you locate your projects without having to remember where they are in the file system and offers snapshots — a Save feature that enables you to save different versions of your projects.

· Archives organizer: Submit your app to the App Store or testers and manage your product archives.

As you can see in Figure 2-2, the Projects organizer shows a list of projects at the left. When you select a project, you can see its location on disk, snapshots that you may have taken or that Xcode has taken, and perhaps most importantly, derived data that has been generated by Xcode.

To create a snapshot, choose File⇒Create Snapshot. To revert to a snapshot, choose File⇒Restore Snapshot. This will take you back to that version of your project. This provides similar functionality to the Source Control menu that lets you work with Git or Subversion.

Derived data is a feature to remember. Xcode caches some intermediate values during its build process. It actually caches two sets of values. When you make modifications to your project, you can use Product⇒Clean to remove many of the cached values. (In fact, some developers routinely use the key combinations to Clean and Build their projects all at once. They are Control+Shift+K and Control+B.)

In addition to cleaning your project, you can remove the second cache of values — the derived data you see in Figure 2-2. If you make a change to your project and don't see anything different, clean and purge derived data: Often that will do the trick.