Setting Up Your Workspace in Xcode
- Workspaces Defined
- When to Use a Workspace
- Creating the Lighting Suite Workspace
- Wrapping Up
This chapter is from the book
This chapter is from the book
This chapter is from the book
In Part I, the Tour.app project was just that—an Xcode project. The collection of files and folders in an Xcode project are bound by an .xcodeproj file that contains all the project-wide settings (such as a description of your schemes and targets). So far, the word “workspace” has been used as a general description of the project and the window that contains it all. A true workspace in Xcode, however, is a container that encompasses multiple projects that share common resources.
From this point forward, we’re going to need something a bit more complex than a single project to demonstrate Xcode’s organizational capabilities. We’re going to create an application suite consisting of an OS X application, an iOS application, and a shared framework that encapsulates all the common components.
For this book’s demonstration, we’ll create our own version of one of the most innovative and popular uses of a bright white screen—the comical “flashlight” app. The suite will be composed of Flashlight.app (for iOS devices) and Lamp.app (for OS X). We’ll call the workspace “Lighting Suite.”
Workspaces Defined
Xcode 4 introduced the idea of a workspace as a kind of project binder—a container for multiple projects. A project groups its related files and settings; a workspace binds multiple related projects. A workspace merely contains pointers to Xcode projects. Projects remain distinct in that you can remove them from a workspace without affecting the project’s content or settings. In other words, the project can still be opened and edited outside its workspace. Workspaces give you several advantages over projects that reference files and built products from other projects.
Projects contained within the same workspace share a common build location. This makes it possible for one project to use another’s built products. This one feature makes a world of difference for managing complex applications and application suites. It makes it far easier, for example, to include the built product of a common framework project into one or more of your application projects.
The automatic dependency detection that you’ll learn about in Chapter 13 extends to the workspace level as well. This means that including a product’s framework in the target of an application project within the same workspace usually requires no additional work for Xcode to recognize the dependency. As with dependent targets within the same project, Xcode will see this dependency and build the framework before building the application. In other words, you don’t have to copy shared libraries into each project folder in which you intend to use the library.
NOTE
Xcode may not be able to detect complex dependencies automatically. In such cases, you’ll need to disable the Find Implicit Dependencies setting of the affected scheme and add and sort the interdependent targets manually.
Another benefit of a workspace is shared indexing. A project index is used primarily for features such as code completion (sometimes referred to as “code sense”). Xcode’s automatic code completion and refactoring facilities will take the symbols of all projects included in the workspace into account. This means code completion will automatically find your framework project’s symbols and make them available to you when you’re editing source files in the application project that uses the framework.
Still another benefit of workspaces pertains to schemes (Chapter 13). A standalone project might contain a primary scheme for building, testing, and profiling a primary product in addition to schemes for smaller, dependent targets (such as a Spotlight plug-in). In a workspace, you may only want to see the scheme for each project’s primary product. Using the Manage Schemes panel that you’ll explore in Chapter 13 you can specify whether the schemes for those smaller “sub-targets” are visible at the workspace level or only when the project is opened individually. This can help keep the list of schemes short and manageable, hiding unnecessary detail within the workspace.