Heads up... You're reading this book for free, with parts of this chapter shown beyond this point astext.
You can unlock the rest of this book, and our entire catalogue of books and videos, with a raywenderlich.com Professional subscription.
As a developer, there’s only one thing you need to worry about when creating a new project in Xcode: writing the code you need to build an amazing app. Every new Xcode project comes with all the scaffolding you need to run the app on a device.
If you only need to build an app to your device, and occasionally push to the App Store, this might be good enough. With more complicated projects and apps, you’ll need to go beyond what Xcode offers as the default and learn more about build customization in Xcode.
By the end of this chapter, you’ll know how to:
- Build more than one app in a single project.
- Work with build settings.
- Change exactly what happens when you click Build.
- Understand the difference between building your device and archiving for the App Store.
Right now, Emitron has the default build setup of any iOS project. You can do a local build to your device by building and running the app as usual, or you can prepare a build destined for the App Store by using the Product ▸ Archive menu option. In this chapter, you’ll configure another way to build the app: as an Alpha build specifically destined for internal testing.
Different build types
Any release of an iOS app goes through different stages before it’s published to the App Store. How you or your team chooses to handle releases may differ, but many large-scale apps look something like this:
- Dev build: A local build installed on the developer’s device or simulator, with logging and debug features enabled to catch pesky bugs before they become a problem.
- Alpha/QA build: Alpha builds are available internally to the members of the team or company so they can test new features and revisions right away.
- Beta build: Beta builds are usually publicly available versions of your app which gives you a chance to test new features and make sure there aren’t any large bugs lying around.
- Release build: The version of your app that users can download on the App Store.
The different build types can go by many names — these are just some examples. For instance, you might refer to an alpha build as an internal or QA build. The terminology is less important than the ability to set it up, which you’ll learn in this chapter.
If your app utilizes servers, dev and alpha builds should ideally point to a different backend server to prevent interference with production data. If you were working on a banking app, you wouldn’t want to see real money change hands during testing! Using a different server when debugging or doing QA testing can prevent this issue.
Emitron’s release pipeline
Every new version of Emitron goes through four stages based on the different build types.
Multiple builds at once
Multiple build types should be installable on the same device, at the same time. A developer should be able to have their latest dev build on their iPhone, the last QA build that went to the team and the latest release build from the App Store.
Technically, you can’t have more than one version of the same app on one device. iOS uses the bundle identifier to identify apps; which means no two apps can have the same bundle identifier. By using different bundle IDs for each build type, iOS thinks of them as different apps entirely, allowing you to have more than one build on a device. This means modifying the bundle ID is your golden ticket to having multiple types of builds running on the same device. Neat!
Moving between build types
When moving between build types, be aware that unintended changes can slip through.
Different build types in Emitron
In this chapter, you’ll configure the build setup in Emitron to switch between three build types: dev, alpha and release. Each build type will vary in its bundle IDs, their app icons and the method of code signing.
A target is a list of files and instructions that tell Xcode how to build your app or app extension. When you hit Build in Xcode, the target is what you’re building.
Targets in Emitron
Open the sample project for this chapter in Xcode. In the Project Navigator, click on the Emitron project to reach the project screen.
Different target types
The emitron target is an iOS App target, but targets aren’t limited to only producing an iOS app. You can make apps for other platforms in Xcode too, such as a watchOS, tvOS or macOS app.
Targets for the alpha build type
Click Cancel on the New Target sheet.
Any time you build a target, you tell Xcode how to run the build by specifying a large set of build settings. Navigate to the project screen in Xcode again, select the emitron target, and then click Build Settings.
Build settings resolution
Usually, build settings apply to the whole project. In projects with more than one target, you may want to change a build setting depending on the chosen target.
Build configurations are a template for build settings. There are two default configurations in every iOS project: Debug and Release. Using these configurations, you can specify a value for a build setting when performing a Debug build, and a different value for a Release build. This comes in handy because you need a different provisioning profile and code signing certificate when doing a release build as opposed to a dev build.
Creating your own build configuration
Build and run the sample project. Once it’s running on your device, minimize the app to reach the home screen.
Swapping settings by build configurations
Still in the project screen in Xcode, click on the emitron target in the sidebar to the left, and click on the Build Settings tab. Change the view from Levels to Combined to simplify the settings view:
Changing the app icon
You can also change the app icon based on the build configuration. Head back to Xcode. Still in the build settings, in the search bar, search for icon. Next to the App Catalog App Icon Set Name build setting, click the ▸ icon to expand the setting.
A scheme is a collection of targets and a build configuration that Xcode uses when building. Schemes are the amalgamation of everything you’ve learned so far in this chapter. You can think of them as a blueprint that tells Xcode exactly what to do when you click the build button. It specifies the actual targets to build and what build configuration to use.
Schemes come with a set of different scheme actions. When you build, archive or run tests on a project, you’re telling the active scheme to execute a particular scheme action.
Creating and modifying a scheme
The version of Emitron in your sample project files has been localized and translated into Polish, but there isn’t an easy way to test the localization. You could change the language of your device, but it might not be so easy to get it back to English again! :]
Preparing your alpha build
Earlier, you created an Alpha build configuration and used it to change the bundle identifier and app icon, but you can’t make an alpha build until there’s a scheme using the Alpha build configuration.
- Not every build is destined for the App Store. Builds can be separated by purpose into different build types such as Dev, QA or Release.
- Targets represent a product to be built. Xcode offers a large variety of target types including different platforms and extensions.
- Build settings tell Xcode how to build your target.
- Build configurations swap out build settings for different build types.
- Schemes are blueprints instructing Xcode how to compile a target using a chosen build configuration. When you build and run an app in Xcode, you’re executing the Run action for the currently active scheme.
- Different schemes can build the same target with different scheme options. You could simulate a different location for Core Location, change the app language, enable a variety of debugging tools and more.