Signing requires a development team

Xcode signs every bundle it produces, and every bundle needs to know which team it is being signed for. This error means one target in the dependency graph has an empty DEVELOPMENT_TEAM build setting and Xcode has nowhere to get one from. In the IDE it would show you a picker. Non-interactively there is no picker, so the build stops.

The parenthesised suffix is the important part of the message and the part everyone skips. It names the target and the project, and the target is frequently not the one you are building. A build that fails on a target called MyLibrary-Resources or a pod you have never opened is a different problem from one that fails on your app, even though the wording is identical.

Case one: it really is your app, and you are on CI

This is the classic. The team was selected in Xcode on a developer's Mac, which wrote it into the project file, and then a .gitignore or a project regeneration step dropped it. Locally it builds. On the runner it does not.

xcodebuild archive \
  -scheme MyApp \
  -archivePath build/MyApp.xcarchive \
  DEVELOPMENT_TEAM=ABCDE12345 \
  CODE_SIGN_STYLE=Manual \
  PROVISIONING_PROFILE_SPECIFIER="MyApp AppStore"

A command-line build setting applies to every target in the build, which is exactly what you want here. It also overrides whatever is in the project file, so a stale team ID committed by a contractor two years ago stops mattering. If you generate your project with XcodeGen or Tuist, set the team in the generator's config as well, otherwise the next regeneration undoes it.

Case two: a Swift package resource bundle

From Xcode 14 onwards, resource bundles produced by Swift packages are code signed, and a package has no signing settings of its own to inherit from. The result is a build that compiled happily for years and now stops on a target you did not write. The message names the bundle, typically something ending in -Resources or _Resources.

There are two reasonable answers. The lighter one is to tell the build that these bundles do not need signing, which is true for resource-only bundles that are then re-signed as part of the enclosing app:

xcodebuild build \
  -scheme MyApp \
  CODE_SIGN_IDENTITY="" \
  CODE_SIGNING_REQUIRED=NO \
  CODE_SIGNING_ALLOWED=NO

The heavier answer, and the right one for a release build, is to pass DEVELOPMENT_TEAM on the command line as in case one. Because it applies to every target, the package bundles pick it up along with your app. Apple engineers have also suggested CODE_SIGN_STYLE=Manual alongside it, which avoids the automatic-signing machinery trying to mint a profile for a resource bundle that will never need one.

Case three: tests, pods, and extensions

• Test targets. A unit-test bundle is signed too. Its team is often left blank because nobody ever archived it. Setting the team project-wide, or on the command line, covers it.
• CocoaPods targets. Pods live in a separate project that your workspace builds. A post_install hook in the Podfile that stamps DEVELOPMENT_TEAM onto every pod target is the durable fix; editing the Pods project by hand is undone on the next pod install.
• App extensions and watch apps. Each has its own bundle ID and its own signing settings, and each needs the team. This is the same target-by-target discipline that no profiles for the bundle ID demands.

# Podfile
post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings["DEVELOPMENT_TEAM"] = "ABCDE12345"
    end
  end
end

Checking your work

Ask xcodebuild what it resolved rather than reading the project file. The setting you care about is DEVELOPMENT_TEAM, and it needs a value for every target that produces a bundle.

xcodebuild -showBuildSettings -scheme MyApp \
  | grep -E "^\s+DEVELOPMENT_TEAM|^\s+CODE_SIGN_STYLE"

# Which targets exist at all?
xcodebuild -list -project MyApp.xcodeproj

An empty DEVELOPMENT_TEAM prints as the setting name with nothing after the equals sign, which is easy to skim past. If it prints a value and the build still fails, you are looking at a different target than the one the error named. Go back and read the parentheses.

Related messages

• Once the team is set, the next stop is often Code signing is required for product type 'Application', which means the identity is missing rather than the team.
• Automatic signing with a team but no session produces Xcode couldn't find any provisioning profiles matching.
• "No account for team 'ABCDE12345'. Add a new account in Accounts settings." The team ID is set but Xcode has no credentials for it. On CI, authenticate with an App Store Connect API key or switch to manual signing.