Creating Our First Project

Back in the first chapter, we used the AVPlayer to play some audio from the Internet. Building on that, we’re going to spend most of the rest of the book writing a podcast client application. We’ll fetch podcast feeds—XML files with descriptions of episodes and links to their audio files—download the audio, and play it. It’s quite possible you already use one of the many popular iOS podcasting apps, such as Overcast, Pocket Casts, Castro, or Apple’s own built-in Podcasts app.

Part of the appeal of developing a podcasting app is that it will do the kinds of things that nearly all iOS apps do: they request data from the Internet, model it in a way that’s convenient for our program logic, present it in an attractive format for the user, and then let the user interact with it. For us, that’ll be fetching and parsing podcast feeds, showing them in tables, and letting the user select shows and episodes. And in another app, those same general techniques might be how the user finds and purchases goods and services, interacts with social networks, researches information, and so on.

Also, we’re going to have lots of screenshots from our favorite iOS and developer podcasts, so maybe you’ll find a new show you like along the way. So let’s get started.

To begin work on a new app, we need to create a project using the menu sequence File > New > Project (⇧⌘N). There’s also a button on the Xcode greeting window for starting a project, so that’s another way to do it.

When we create a new project, a window opens, and out slides a sheet that asks us what kind of project we want to create. This project template sheet, shown here, has a set of tabs for the various Apple platforms: iOS, watchOS, tvOS, macOS, and cross-platform. Within each tab, there are various starter project types split into sections like Application and Framework & Library. Since we’re building an iOS application, we’ll select the iOS tab and then look at the choices in the Application section. For our first example, we’ll select Single View Application, and then click Next.

After we click Next, the sheet then asks us for details specific to the project, as shown in the following figure. Some of these change based on the project type; in general, this is where we need to provide names and other identifiers to the app, indicate which device formats (iPhone and/or iPad) it’s for, and so on. For our app, here’s how we should fill out the form:

• Product Name: A name for the product with no spaces or other punctuation. Our product will be called PragmaticPodcasts here.

• Team: Once we’ve set up to run apps on physical iOS devices (which we’ll do in ​Running and Testing on the Device​), this will be used to indicate which development team’s identity is used when installing to the device. Until we’re set up, however, this can be left blank.

• Organization Name: This can be a company, organization, or personal name, which will be used for the copyright statement automatically put at the top of every source file.

• Organization Identifier: This is a reverse-DNS style stub that will uniquely identify our app in the App Store, so if someone else submits a PragmaticPodcasts, the two apps won’t be mistaken for each other because they’ll each have a unique Bundle Identifier, which is the auto-generated fifth line of the form. If you have your own domain, you can use it for the company identifier; otherwise, just invert your email address, such as in com.company.yourhandle.

• Language: There are two choices for this pop-up menu: Swift and Objective-C. We’ve covered Swift for the previous three chapters, so let’s choose that here.

• Devices: This determines whether the template should set us up with an app that’s meant to run on an iPhone (and iPod touch) or iPad or be a “universal” app with a different layout for each. Not all templates offer all three options. With the variety of iOS devices currently available, Apple is pushing hard for developers to build universal apps that run and look good on a variety of screen sizes—all four sizes of iPhone and two of iPad—so select Universal here.

• Check boxes: Do not select Use Core Data, which is a data-persistence framework that is beyond the scope of this book. When we’re done, feel free to move on to Marcus Zarra’s excellent book, Core Data in Swift: Data Storage and Management for iOS and OS X [Zar16]. Go ahead and check both Include Unit Tests and Include UI Tests. These will make it easier to expose our app to automated testing, which we’ll do in Chapter 6, ​Testing the App​.

After clicking Next, we choose a location on the filesystem for our project. There’s also an option for creating a local Git source code repository for our files. Source control is beyond the scope of this book, but in short, if you want a local history of all your changes, select the check box. If you don’t need a local repository, or (better yet!) if you plan to check your code into an external source control system such as GitHub later on, leave the box unselected.

Once we specify where the project will be saved, Xcode copies over some starter files for our project and reveals them in its main window.