Enrolling in an Apple Developer Program

To start, one person must enroll in either the iOS or OS X developer program; this person becomes the team agent for the team. The team agent may enroll in both programs if your team intends to develop apps for both operating systems. During this step, the team agent signs the legal agreements required to become an Apple developer and prepares the financial paperwork so that the team can be paid for purchases from the App Store.

The team agent is special; they have unrestricted access to the team and are legally responsible for the team. The team agent also performs most of the tasks to organize the team. If desired, after others have joined the team, the team agent can delegate some of this authority to other members of the team, allowing those others to perform these tasks instead.

The team agent might need to sign updated or new licensing agreements, particularly when the team wants to incorporate specific technologies into an app. For example, an app that uses the iAd service requires your team agent to sign a separate agreement.

Adding Members to a Team

After the team agent has joined a developer program, they add other people to the team and set their privileges. If you are the team agent and the sole developer on your team, no additional configuration is needed, because the team agent always has access to all account features. However, you should continue to read this section to understand the kinds of tasks you may need to perform throughout the rest of the development process.

To add a new person to the team, the team agent sends an invitation to the person; part of sending an invitation includes setting that person’s privileges on the team. When the person accepts the invitation, they are automatically added to the team.

Organizing the Team in iTunes Connect

The privileges set in the previous section primarily pertain to the development process: They define who is allowed to sign apps, who is allowed to create signing certificates, and so on. However, the team agent also manages access privileges to the iTunes Connect website. For example, changing the price of an app is a task you likely want to limit to a small number of people on your team. Access to the iTunes Connect website is configured separately and is designed to be more fine-grained than the access you set in Member Center. On iTunes Connect, each person on the team can be assigned one or more roles; each role has different privileges. Table 2-3 describes the roles at a high level.

Table 2-4 lists the most common modules you need to access in iTunes Connect, along with the roles that are allowed to access each module. The legal role is not shown, because only the team agent has those rights. All participants have the ability to edit their own personal details stored in their accounts in iTunes Connect.

Organizing the Development Team

Now that you understand the roles people can assume in Member Center and iTunes Connect, you should consider how you want to organize the team. Organizing the team requires more than setting privileges described above. The size of the team affects how you organize it and its assets.

The smallest team is a single person—you. You act as the team agent and have full privileges to perform any task. The disadvantage of a one-person team is that you have to do all the work. You need to set up the assets needed to sign and publish an app, configure all the information in iTunes Connect, develop an app, and market it.

A more common configuration is a small developer team. On a small team, the team agent is also a programmer, but defers some of the administration overhead to another person on the team. The team agent handles all of the financial and sales operations for the team, while the team admin ensures that the developers on the team have what they need to get the job done.

If your team is large, you can divide the tasks further. Some people on the team might not be programmers, including the team admin. The sales and financial roles might be filled by people with a business background. You might even have in-house testers who are not also programmers. The task of creating and shipping apps could be delegated to one or more dedicated team admins. You might even partition the work further and divide the team between iOS and OS X development.

As the team grows, the need for coordination between the different people on the team increases. In particular, the cost of development errors increases when you have more programmers on the team. For example, if you are the sole member of the team, you can store all your work on a single computer and do all of the work there. Xcode even allows you to create a local source code repository to store your code. But what happens when the team grows in size?

When the team grows to a moderate size, you need more infrastructure. You want a separate computer to act as a remote source code repository; members of the team pull down the code from the remote repository to their computers, make changes, and send those changes back to the server. But when multiple developers are syncing code, the chance of an error being checked into the code increases. To minimize problems, you usually want multiple branches of development, including stable branches that hold the code you use to build your shipping app and experimental or developmental branches used for new development. These strategies require a deeper understanding of the underlying source code repository and require you to define specific policies that describe how code gets integrated between the different branches you maintain.

If your team grows very large, checking erroneous code into developmental branches could impair your team’s productivity. By the time you discover an error, it might already have been synced to other people’s computers. After you correct the error, propagating the fixes to everyone on the team still takes time. The frequency of such incidents and the time lost for each incident increase as the size of the team increases; these losses, when aggregated, cripple your team’s effectiveness. To avoid this lost productivity, you should add additional infrastructure for code management. For example, you might adopt a process of continuous integration by creating a dedicated build machine (known as a build bot) that automatically checks out each change and rebuilds your app. By building new changes as they arrive, you discover errors earlier; you might even configure the server to back out such changes before others on the team pull down the offending code. If your project includes unit tests or automated user tests, the build computer can also run those tests to verify that your source code still passes the tests. This process, known as smoke testing, increases the team’s confidence that code stored in the development branches builds and works properly.

As the team grows larger, you want to automate tasks that are repeatable, predictable, and costly to perform by hand. By automating common tasks, you reduce the burden on the team and allow it to focus on designing and implementing code.

Creating Your Team’s Signing Certificates

Apps distributed on the App Store must be cryptographically signed. You may also need to sign the app during development.

• On OS X, an app must be signed during development if it uses iCloud or application sandboxing.

• On iOS, all apps must be signed during development.

Regardless of which platform you are developing for, everyone on the team should understand the code signing process. This section describes the assets that are needed to sign an app and authorize it to run on a device, and then explains how people on the team acquire the assets they need to sign apps. Some of these assets should be created now as you organize your team; the rest are created each time you start a new project.

An Example: Signing an iOS App During Development

Figure 2-5 shows everything that is needed to build and sign an iOS app during development. Signing apps during OS X development or signing to distribute an app on either platform follows similar procedures. For now, focus on this example. While you are developing an iOS app, it can only be installed on iOS devices specifically marked for development. To run an app on such a development device, you install a signed version of the app and a development provisioning profile that authorizes the signed app to be launched. Without a profile that authorizes it to launch, iOS prevents the app from launching.

Creating development provisioning profiles is described in detail in Creating a Project; for now, understand that a development provisioning profile is a signed file whose contents define the scope of the profile:

• The development profile authorizes a specific set of apps to run.

• The development profile authorizes a specific list of devices to run those apps.

• The development profile authorizes a specific list of development certificates to sign those apps.

In addition to being installed on the development device, the profile must be installed on your development computer also. The profile authorizes the copy of Xcode to sign the app. Xcode only signs an app and installs it on the device if the profile authorizes the signing certificate and the app being signed. Logically, this makes sense; if a profile that authorizes the app to launch is not available, such an signed app would serve no purpose.

Next, take a close look at the left side of Figure 2-5. To sign code during development, you need the following items installed in the keychain on your development system:

• A private key.

• A development signing certificate (authorized by a team admin). This signing certificate includes the public key associated with the private key.

• An intermediate signing certificate (provided by Apple). This certificate acts as an intermediary between your development signing certificate and the signing authority.

The combination of a signing certificate and the corresponding private key is called a code signing identity. When you build an iOS app, Xcode compiles it, signs it using your code signing identify, and installs it on the device. If a provisioning profile compatible with the signed app is also installed on the device, you can launch and debug the app.

Setting Up a Developer for Code Signing

Figure 2-6 shows the process for setting up a new developer on the team. The full details of this process are spelled out in documents listed later in this chapter; see To Learn More. For now, you only need to understand this process at a high level. Team members make requests; team admins authorize or deny these requests. There are two separate pieces that need to be authorized: adding a development device to the team’s devices and creating the code signing identity used to sign apps during development.

To add a device to the team, you send the unique device ID (UDID) for the device to a team admin; this process happens outside of any tools provided by Apple. For example, you might send an email to the team admin with the device’s device ID. The team admin adds the device to the team’s devices. Typically, the team admin also adds this device to any development provisioning profiles associated with the team, although that is not strictly required. For example, if your team wants to limit an app to specific devices, then you might choose to add the device only to a subset of the team’s profiles.

To get a signing certificate, a team member uses Xcode to request a signing certificate. Xcode automatically creates a new public and private key and requests that a new development signing certificate be created for the team member. After a team admin receives and approves the certificate request, the team member can use Xcode to automatically install the required pieces into the keychain.

Although setup is described here as a single process, you do not need to perform both steps for every member of your team. For example, you might want internal testers to be associated with the development team on the Apple Developer website but not allow those testers to build and sign your app. In this case, the team admin might include a tester’s device in the team’s devices but not allow the tester to create a code signing identity. Similarly, an external tester’s device must be included in the team’s device list in order for it to be authorized to run an app.

While the above discussion was about development signing certificates, when you organize your team, the team should also request a distribution signing certificate. A distribution signing certificate is required if you intend to distribute apps to nondevelopment devices. Unlike development signing certificates, where each team member has a separate code signing identity, a team has a only one code signing identity used to sign apps for distribution. The procedure for creating a distribution certificate is similar to the workflow described above, but the request for a distribution signing certificate is made by a team admin using a new public/private key pair and Apple approves the request. After the certificate is approved by Apple, only a team admin can download the resulting certificate.

To Learn More

If you are on an iOS team, read the following documents to learn more about creating a team and setting up its signing certificates:

• If you are a team admin, read iOS Team Administration Guide.

• If you are a team member, read Tools Workflow Guide for iOS.

• Read iTunes Connect Development Guide for a comprehensive description of iTunes Connect and the tasks you perform there.

If you are on an OS X team, read the following documents to learn more about creating a team and setting up its signing certificates:

• Regardless of whether you are a team member or a team admin, read Tools Workflow Guide for Mac.

• Read iTunes Connect Development Guide for a comprehensive look at iTunes Connect and the tasks you perform there.