How Xcode crashed with Code Signing error “Signing for ‘App’ requires a development team” and the detailed fix that restored CI builds

When building iOS or macOS applications with Xcode and continuous integration (CI) pipelines, developers often run into issues with code signing. One particularly common and frustrating error is: “Signing for ‘App’ requires a development team.” This error can bring CI to a halt, especially when builds are working locally but mysteriously fail on CI servers. This article documents a real-world encounter with this code signing issue in Xcode, the root cause behind it, and a detailed resolution process that restored stability to automated CI workflows.

TL;DR

A CI pipeline using Xcode began failing due to the error “Signing for ‘App’ requires a development team”. The root cause was an invalid or missing team ID in the project or Xcode configuration. The fix involved explicitly setting the development team in the project file, ensuring proper provisioning profiles, and updating the CI build settings to include signing credentials. Once set up, automated builds began working again without manual intervention.

Identifying the Symptom

Everything was working fine until the CI build pipeline, which uses xcodebuild, started throwing this error:

error: Signing for 'App' requires a development team. Select a development team in the Signing & Capabilities editor.

This message was puzzling because local builds on developer machines were successful. The development team was indeed set under Signing & Capabilities in Xcode. However, when invoked via CI, the build system couldn’t see this configuration. This discrepancy sparked a deep investigation into the inner workings of Xcode’s project settings and signing identities.

Understanding the Context

Modern Xcode projects use automatic code signing by default, relying on the Apple Developer Portal to manage certificates and provisioning profiles. For this to work:

• The project must specify a valid Development Team ID.
• The system running the build must have access to relevant signing certificates and provisioning profiles.
• When building in CI, no GUI is available, so everything must be configured via command line tools and project files.

The CI server, however, had no GUI and no user session—meaning some of the user-scoped Xcode configurations like keychain access and local code signing preferences didn’t apply.

The Root Cause

After digging into the .xcodeproj/project.pbxproj file directly, it was discovered that under the build configuration’s PROVISIONING_TEAM key, the development team ID was not specified in all target configurations or build schemes, particularly for test targets or app extensions. This inconsistency meant that when CI attempted to build targets other than the main app (e.g., unit tests), the build failed due to missing signing information.

Additionally, the CI environment wasn’t explicitly providing a team ID via command line arguments, so xcodebuild couldn’t infer the correct signing identity.

The Fix

The resolution required a few key changes to ensure deterministic and portable code signing across both local and CI environments:

1. Explicitly Set the Development Team

In Xcode, navigate to Build Settings > Signing and add the proper Team ID under DEVELOPMENT_TEAM for ALL targets, including extensions and test bundles.

The value should look like:

DEVELOPMENT_TEAM = ABCD123456;

2. Ensure Consistent Signing Across Targets

All targets in the project must use the same signing approach—either automatic or manual. Mixing these can lead to unpredictable failures. Use one of the following build settings across all targets:

• CODE_SIGN_STYLE = Automatic
• CODE_SIGN_STYLE = Manual with explicit provisioning profile identifiers

3. Update the CI Build Command

In the CI pipeline, modify your xcodebuild command to explicitly provide the development team. For example:

xcodebuild -workspace App.xcworkspace \
            -scheme App \
            -sdk iphoneos \
            -configuration Release \
            DEVELOPMENT_TEAM=ABCD123456 \
            CODE_SIGN_IDENTITY="Apple Distribution" \
            PROVISIONING_PROFILE_SPECIFIER="MyProvisionProfileName"

Note that this entirely bypasses GUI-dependent configuration and ensures builds can run headless on the CI server.

4. Import the Keychain and Certificates to CI

Install the necessary signing certificates and provisioning profiles into the CI agent’s keychain. On macOS agents, this can be done using Fastlane’s match tool or via manual security import commands.

5. Validate Signing Configuration

After applying changes, do a dry run build locally using the same command line as the CI. This verifies the correct provisioning identifiers and certificates are being picked up:

xcodebuild -showBuildSettings | grep -i signing

You should see valid values for keys like DEVELOPMENT_TEAM, CODE_SIGN_IDENTITY, and PROVISIONING_PROFILE.

Restoring CI Pipeline

Once these steps were completed, the CI pipeline ran successfully without further crashes. The lesson learned was clear: avoid relying solely on Xcode’s GUI for configuration. Instead, use consistent and explicit settings in project files and CI scripts to create a reproducible environment.

This also served as a reminder of the importance of checking all targets, not just the main app target—an overlooked test bundle was the source of the crash.

Best Practices for CI Signing Stability

• Always define the DEVELOPMENT_TEAM in all build configurations.
• Use consistent signing style (manual vs automatic) across all targets.
• Validate signing manually on the command line outside Xcode to simulate CI.
• Use tools like Fastlane Match to manage provisioning profiles and certificates across teams and CI agents.
• Version control your project’s .pbxproj file responsibly—many signing issues arise from merge conflicts or misconfigured branches.

FAQ

Q: What does the error “Signing for ‘App’ requires a development team” mean?

This error indicates that Xcode or xcodebuild cannot determine which Apple Developer Team ID to use for signing the app.

Q: Why doesn’t this signing issue happen when building locally?

Local machines typically have access to personal code signing certificates and provisioning profiles, as well as GUI settings that guide Xcode in selecting defaults. CI agents lack these unless explicitly configured.

Q: How do I find my DEVELOPMENT_TEAM ID?

Log in to the Apple Developer portal and navigate to the membership section. The Team ID is listed there. You can also find it in Xcode under Signing & Capabilities.

Q: Should I use automatic or manual signing in CI?

Manual signing provides better control and consistency in CI environments. Tools like Fastlane can assist with automation while maintaining determinism.

Q: Can I skip signing entirely for CI?

No, unless you’re targeting the simulator only, signing is required to package and deploy apps to iOS devices or TestFlight.