Appendix A. Project settings
Apple engineers provide app developers with an exceptional degree of configurability for their projects and apps. On the flip side, all these customizable settings can be intimidating—the build settings alone could contain approximately 300 customizable fields!
We’ll take a short tour of project settings, but don’t be alarmed: it’s not necessary to understand the detailed implications of every setting you see. In many cases, leaving them at their default is the best option.
If you select the project itself in the Project Navigator, you’ll see the project editor (see figure A.1). Here, you can edit the settings for your project or your target. The Projects and Targets column on the left shows what you’re currently editing, and shows that in addition to your app target, Xcode by default created two targets for your unit and UI tests. You’ll find that you’ll most often be editing the settings for your main app target.
Figure A.1. Project editor
Along the top of the project editor, you’ll find the Settings tabs, where you can choose which settings you wish to edit in the settings pane.
A.1. General
In the main target’s General tab, you’ll find the most commonly needed settings (see figure A.1).
You’ll recognize several of these from when you created your project, along with a few more:
- Deployment Target— Minimum version of iOS your app will work on
- Device Orientation— Which device orientations your app is designed to work in
- Status Bar Style— The look of your status bar, including whether it should be there at all
- App Icons and Launch Images— Where Xcode can find the app icon and launch screen
Note
All the settings in the General tab are in fact generated from other tabs. In earlier versions of Xcode, this tab was called Summary, which was perhaps a clearer indication that this tab summarizes the most relevant information from all the tabs. Not to worry though, any changes you make here will automatically update elsewhere, and vice versa.
A.2. Capabilities
In the Capabilities tab, you can include Apple app services that aren’t included by default. These include iCloud, push notifications, and Game Center. Look at the capabilities available—it’s interesting to look through the list of app services Apple provides to you that could add value to your app.
We looked at adding iCloud and push notification capabilities in chapter 12.
A.3. Resource tags
Here, you can assign tags to certain resources such as data files or images. These resources are then excluded from the main app bundle and can be downloaded when they’re required or on demand. This is a great way to keep your app size down.
A.4. Info
The Info tab defines and configures your app’s final executable file, or bundled executable. You saw several of these settings already in the General tab, and modifying them in either place updates the other. All the info settings are also hardwired to a file you may have noticed in your Project Navigator called Info.plist. This is a special type of file called a property list that contains a hierarchy of key-value properties. If you open the Info.plist file in the property list editor, you’ll notice that it contains exactly the same information as your main target’s Info tab, but in a different order.
When you create an Xcode project, Info.plist is generated with all required properties, but during development of your app you may need to add keys to this list for different purposes.
Several properties in the Info.plist file are by default derived from elsewhere. You can spot these because they’re surrounded by brackets and prefixed by a dollar sign. For example, Bundle Name is derived from $(PRODUCT_NAME), which is defined in Build Settings.
We modified the Info.plist file in chapter 13, to request permission to use the camera, and again in chapter 14, to add app transport security.
A.5. Build settings
Build settings are the instructions Xcode follows to build your app. Though hundreds of settings are available in the main target’s build settings, the good news is that most of the time you’ll leave these settings at their default values. However, at times you’ll need to modify a build setting, so let’s be sure you know your way around.
Tip
Select a setting to learn more about it in the Help Inspector.
A.5.1. Changing your build settings for configurations
By default, settings are divided into two categories under Configurations: Debug and Release. These configurations are defined in the Info tab for the project (see figure A.2) and can be used to apply different rules to your build settings, depending on whether you’re building for an internal debug or archiving your project as ready for distribution.
Figure A.2. Configurations
Most of your build settings are the same for both debug and release, but it’s possible to change a build setting for a specific configuration. Let’s say you want to change the app icon for debug and release builds (see figure A.3).
- Open the build settings for the target and point to the app icon setting. You’ll notice an arrow appear at the left of the line. Tap on this arrow to open the setting’s configurations.
- Click on a debug or release configuration setting to specify a different value.
- Once a setting’s configurations contain different values, it will display the text <Multiple values>.
Figure A.3. Edit build setting for a configuration
A.5.2. Filtering build settings
Build settings aren’t necessarily all determined at the target level. If a specific build setting hasn’t been customized for your target, that setting will be inherited from your project. Similarly, if a specific build setting hasn’t been customized by your project, it will be derived from the built-in iOS default.
At the top of the Build settings window, you’ll see two sets of buttons that help you to explore these relationships. First, you’ll see three options that filter which build settings appear:
- Basic— Shows you only the most basic build settings
- Customized— Shows only the settings that have been customized at the target level
- All— Shows all settings
Be careful not to have Basic or Customized selected when searching for a setting from the search field; though the setting may exist, if it’s not basic or customized, it may not appear.
Next, you’ll find two options (see figure A.4) that determine how the build settings appear:
- Combined— This is the default view, showing you the current status for each build setting, regardless of where in the hierarchy it’s being set.
- Levels— This view of the build settings highlights in columns where each build setting is being set in the hierarchy—at the target, project, or iOS default level. The Resolved column is the equivalent of what you see in the Combined view. The resolved value for each setting is represented in the hierarchy with a green rectangle.
Figure A.4. Filters and Combined/Levels views for build settings
A.6. Build phases
The build phases define the phases Xcode steps through when building your app. Table A.1 A.1describes them in more detail.
Table A.1. Build phases
|
Build phases |
Description |
|---|---|
| Target Dependencies | Relevant for more-complex projects, where a target may have another target as a dependency. |
| Compile Sources | Defines any source files (that is, any Swift files) that Xcode needs to compile. When you add a Swift file to your project, it’s automatically added to compile sources. |
| Link Binary with Libraries | Instructs Xcode to link this app to a library or framework. There are many libraries and frameworks provided by Apple, or you can select a third-party framework by selecting Add Other. This section corresponds to the Linked Frameworks and Libraries section in the General tab. |
| Copy Bundle Resources | Here, Xcode will copy any resources your app requires, such as images, audio, data, or even storyboards. When you add a resource to your project, it’s automatically added to this build phase. |
Sometimes, Xcode makes mistakes when automatically detecting a file’s category (compile sources, frameworks and libraries, or copy bundle resources), and if something seems to go wrong after you add a file to your project, it can be a good idea to verify that Xcode has made correct assumptions about the file in your build phase settings. We looked at adding files to your project in chapter 5.
In addition to the default steps, you can add other steps to the build phases, such as copying files or running a script. We added a run script in chapter 14 to copy frameworks downloaded via the dependency manager Carthage.
A.7. Build rules
The Build Rules tab defines how different file types are processed by Xcode. The default behavior for file types is probably fine for your projects, and it’s unlikely you’ll need to make changes here.