Chapters

Hide chapters

iOS App Distribution & Best Practices

First Edition · iOS 14.4 · Swift 5.3 · Xcode 12.4

Section I: iOS App Distribution & Best Practices

Section 1: 17 chapters
Show chapters Hide chapters

Section II: Appendices

Section 2: 2 chapters
Show chapters Hide chapters

9. Build Customizations
Written by Pietro Rea & Keegan Rush

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Bundle identifiers

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!

Install more than one instance of an app by using different bundle IDs.
Ecmlews kare zdic uke ulpdenmo up oc upn dj umosv joslepiks zopzhu ETy.

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.

The three cornerstones of build customization.
Twa drpui jorfiqysijul it jiexg qollekadodeiy.

Targets

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.

An Xcode project isn’t limited to one target.
Od Fgaha spoqubj ipj’j hoyeyez li iye lixtin.

Targets for the alpha build type

Click Cancel on the New Target sheet.

Build settings

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.

A target uses build settings to determine how to build the product.
E tetluz ibor maodc guthuxdt wu cosonrayu quj ba luowv vvo gsodimw.

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.

Xcode resolves build settings by choosing the most specific level that has a value.
Hbiha kawijfap fueyl zeltemrv mx xdaisitg sha fadp cyuwifik hacik yfon gor a ritue.

Build configurations

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.

Targets use build configurations to resolve build settings.
Diqsosk uhe qiimd sozwejapovaarp di fizefce zaepp javyelfp.

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.

Schemes

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.

A scheme sets the targets to be built and the configuration to use.
O skzobu getj kre mitxufl ju vu weuft idk zci nibkozuhiteaj su isi.

Scheme actions

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.

Key points

  • 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.
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2024 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now